1. 课程导入与治理全景

在企业上云的过程中，真正决定安全边界与运维效率的，往往不是某台虚拟机或某个数据库的配置，而是“谁是谁、谁能做什么、资源归谁管”这三件事。Google Cloud 把这三件事分别落在 Identity（身份）、IAM（权限） 与 Resource Hierarchy（资源层级） 三个相互咬合的机制上。本课程围绕它们展开，本章先建立整体地图，并准备好后续实验所需的环境。

三个核心概念：身份、权限、层级

身份回答“主体是谁”。Google Cloud 中的主体可以是 Google 账号（个人 Gmail 或 Workspace 用户）、Cloud Identity 管理的用户与群组、服务账号（Service Account），以及外部身份源通过 Workforce Identity Federation 或 Workload Identity Federation 映射进来的身份。身份是权限授予的接收方，没有身份就无从谈授权。

权限回答“能做什么”。Google Cloud 采用“权限—角色—绑定”的三段式模型：权限（如 storage.objects.get）是最小操作单元，角色（Role）是权限的集合，IAM 绑定（Binding）把角色授予某个主体，并作用在某个资源上。基本角色（Owner/Editor/Viewer）、预定义角色与自定义角色是三种常见形态。

资源层级回答“作用范围有多大”。Google Cloud 的资源层级自上而下为：组织（Organization）→ 文件夹（Folder）→ 项目（Project）→ 具体资源（如 GCE 实例、GCS 存储桶）。IAM 策略沿层级向下继承，在高层授予的角色会自动作用于其下所有资源，这是理解“为什么某人能访问某个项目”的关键。

治理全景：从组织到资源的授权链路

把上述概念串起来，就得到 Google Cloud 治理的主干链路。下图展示了从身份来源、策略决策到资源访问的完整关系，也标出了本课程后续会深入的关键节点。

图中实线表示授权与继承的主链路：身份被授予角色，角色绑定在层级中的某个节点上，策略沿层级向下继承，最终在资源访问时被评估。虚线表示治理的“反向约束”：组织策略限制资源可以怎么用，审计日志记录谁在什么时候做了什么，二者共同构成可管、可查、可追责的闭环。

为什么层级是理解 IAM 的钥匙

很多初学者会困惑：“我明明只在组织层给了一个人 Viewer，为什么他能看下面所有项目？”答案就是继承。反过来，如果只在某个项目授予角色，其影响范围就止于该项目及其子资源，不会向上或平级扩散。因此在实际治理中，一个常见原则是：能用低层级解决的，不要上升到高层级；组织层只放真正全局性的角色（如组织管理员、安全管理员），项目层放业务角色。

另一个关键点是“最小权限”。Google 建议优先使用预定义角色而非基本角色，因为基本角色（尤其是 Editor）权限过宽。例如给一个只需要读取 GCS 对象的服务账号授予 roles/storage.objectViewer，而不是 roles/editor，可以显著缩小攻击面。

实验环境准备

后续章节的动手实验需要一个可操作的 Google Cloud 环境。建议按以下清单准备，示例参数仅作演示，请替换为你自己的项目信息。

初始化命令示例：

gcloud auth login
gcloud config set project gcp-iam-lab-01
gcloud services enable iam.googleapis.com cloudresourcemanager.googleapis.com
gcloud iam service-accounts create sa-lab-reader \
  --display-name="Lab Reader SA"

执行后可用 gcloud iam service-accounts list 确认服务账号已创建。若返回列表中出现该邮箱，说明环境就绪；若报权限错误，通常是当前账号缺少 roles/iam.serviceAccountAdmin 或项目未启用 IAM API。

学习路径与本章定位