IAM：授权范围与 Service Account
授权公式：Principal + resource + role + condition；权限沿 Organization / Folder / Project 继承。
完整 Hands-on 教程#
Startup IAM Hands-on：从公司账号、组和组织结构开始，依次练习团队授权、Service Account、最小权限、条件授权、Deny、组织策略、审计与离职撤权。包含 8 个实验章节及应用源码。
推荐做法#
- 团队给 Google Group 授权；工作负载各用独立 SA，权限收敛到资源。
- 本地优先用户 ADC 或 impersonation；CI 用 federation，云上用绑定身份。
- actAs 允许附加 SA，Token Creator 允许签发 SA 凭据，资源 role 决定 SA 能做什么。
常用操作#
替换为实际资源；本段不依赖 lab.env。
PROJECT_ID='REPLACE_PROJECT_ID'
SERVICE_ACCOUNT='REPLACE_SA_EMAIL'
gcloud projects get-iam-policy "$PROJECT_ID"
gcloud iam service-accounts get-iam-policy "$SERVICE_ACCOUNT" --project="$PROJECT_ID"常用变更：只允许 SA 读取一个镜像仓库
沿用上方 PROJECT_ID、SERVICE_ACCOUNT，Project 是仓库所属项目。操作者需能修改该 Repository 的 policy。
REGION='REPLACE_REGION'
REPOSITORY='REPLACE_REPOSITORY'
gcloud artifacts repositories add-iam-policy-binding "$REPOSITORY" \
--project="$PROJECT_ID" --location="$REGION" \
--member="serviceAccount:$SERVICE_ACCOUNT" \
--role=roles/artifactregistry.reader只有确实需要读取项目全部仓库时才在 Project 授同一 role。收窄授权还需撤销多余的上层 binding。
容易踩的坑#
- SA 上的 policy 回答谁能使用该 SA，不列出它在所有资源上的访问权。
子资源的窄权限不会覆盖父级宽权限；删除本地 binding 也不会撤销继承授权。 查 Project / Folder / Organization 和 Group 的其他路径。使用 impersonation 时，请求按目标 SA 权限判断，不叠加操作者原权限。
Project / Repository 授权 · CLI / ADC · GKE Pod 身份 · 撤权排障 · 无长期 key
配置说明与完整示例（按需展开）
本页说明 IAM 的授权模型：身份、 role、资源，以及 Service Account impersonation。实验步骤和凭据参考按任务分到子页。
| 你想做什么 | 阅读位置 |
|---|---|
| 公司从零建立身份目录、管理员、员工及组织 | 公司身份与组织初始化 |
| 理解人员账号、团队管理及 Workload / Workforce 区别 | 人员账号与 Identity Federation |
| 实测 SA 读取、写入拒绝、撤权、限时授权和 403 排障 | Bucket 授权与撤权实验 |
| 配置用户登录、ADC、Terraform 认证 | CLI、ADC 与 Terraform |
| 像 AWS profile 一样管理多个账号 | 多账号与配置隔离 |
| 查 JSON 内容、生成方式、长期密钥限制与吊销 | 凭据 JSON 与密钥管理 |
| 实测 GitHub OIDC token 文件与凭据配置 | 外部凭据文件实验 |
首次学习：本页 → Bucket 实验 → 本地认证；使用 GitHub Actions 时再做外部凭据文件实验。已有问题可直接按表进入对应子页。
1. 先区分身份、权限和边界#
IAM 授权描述：哪个 Principal，在什么资源上，获得哪个 role，附带什么条件。
Principal 是接受授权的身份或集合，例如 Google 用户、Service Account、Google Group、federated identity。Google Group 成员可获得授予组的权限。Principal
例如“reader SA 可读取 Bucket”：Principal 是 reader，资源是 Bucket，role 是 Storage Object Viewer。
Organization（通常关联 Cloud Identity / Google Workspace）
└── Folder：团队、环境
└── Project：API、配额、资源与费用归属
└── Bucket / Cloud Run / Secret / ...个人账号可使用无 Organization 的项目。Billing Account 负责结算，不是 IAM 资源树中的项目父节点。Google Workspace 管理员也不等于自动拥有所有云资源权限。
| 概念 | 用途 | AWS 对照与区别 |
|---|---|---|
| Google Account / Cloud Identity 用户 | 人的登录身份 | 不在每个 Project 中创建一个 IAM User |
| Google Group | 团队批量授权 | 成员资格来自身份目录；优先给组授权 |
| Service Account（SA） | 应用、作业的身份 | 部分类似 Role 的用途，但自身也是可授权的资源 |
| Role | 一组 permissions | 类似权限策略的权限集合；不能“登录一个 Role” |
| Principal | 接受授权的身份或身份集合，回答“谁获得权限” | 例如用户账号、 Service Account、 Google Group 或外部 federated identity |
| Allow policy | 保存在资源上的授权规则集合，包含一个或多个 binding | 记录谁在该资源上获得什么 role |
| Role binding | 在一条规则中，将一个 role 授予一个或多个 Principal，可附加生效条件 | 例如在某个 Bucket 上把 Object Viewer 授予 reader Service Account |
| Service agent | Google 管理的服务身份 | 服务运行所需，不是自建应用 SA |
| Workforce federation | 外部员工身份进入云 | 面向人 |
| Workload federation | GitHub、外部云、Kubernetes 工作负载进入云 | 面向程序，使用短期凭据 |
基本 role Owner/Editor/Viewer 范围大；优先服务预定义 role，确有需求再定义 custom role。IAM 官方模型
2. 授权如何生效#
Allow 权限沿 Organization → Folder → Project → 具体资源 继承并累加。资源本地 policy 不列出全部 inherited permissions；撤权时须逐层检查。
以下假设 Bucket 与 SA 已存在；替换示例名称，操作者需有该 Bucket 的 IAM policy 修改权限。完整创建和验证见 Bucket 实验。
gcloud storage buckets add-iam-policy-binding "gs://example-project-iam-lab" \
--member="serviceAccount:lab-reader@example-project.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"add-iam-policy-binding 向目标资源的 Allow policy 添加一条 role binding：
| 命令中的部分 | 表达什么 | 本文实验示例 |
|---|---|---|
--member |
接受授权的 Principal；前缀说明身份类型 | serviceAccount:lab-reader@example-project.iam.gserviceaccount.com，表示 lab-reader Service Account |
--role |
授予哪组权限 | roles/storage.objectViewer，允许读取和列出对象 |
| 资源参数 | 将授权记录在哪里、限定哪个范围 | gs://example-project-iam-lab，表示目标 Bucket |
用户与 Google Group 的 member 前缀分别为 user:、group:。
同一 SA 可在不同资源获得不同 role。Allow policy 与 binding
- 子资源删除 binding 不会撤销上层授予的权限；Conditions 可限制授权时间或支持的资源属性。
- Deny 可阻止受支持的权限；Principal Access Boundary 可限制可访问资源范围。
- Organization Policy 约束资源配置，例如禁止创建 SA key，不授予访问权限。
- 网络、VPC Service Controls、API 状态、配额与数据库授权仍单独检查。策略类型
授权范围：Project 级与 Repository 级#
以 roles/artifactregistry.reader 为例。PROJECT_ID 是仓库项目，NODE_SA 是已存在的 SA 邮箱（可来自另一项目），REGION 是仓库位置；操作者需有相应资源的 IAM policy 修改权限。
| 授权位置 | 生效范围 | 什么时候选择 |
|---|---|---|
| Project | 项目下所有区域的仓库，包括以后创建的仓库，继承此 role 的适用权限 | 该身份确实需要读取整个项目的仓库 |
| Repository | 只针对指定区域中的 lab-images 仓库授予 role |
只需拉取这个仓库的镜像 |
按实际范围选择下面一种即可，无需两条都执行。
Project 级：修改项目的 Allow policy，向下继承到仓库。
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
--member="serviceAccount:$NODE_SA" \
--role=roles/artifactregistry.readerRepository 级：修改 lab-images 的 Allow policy，只在该仓库上添加授权。
gcloud artifacts repositories add-iam-policy-binding lab-images \
--project="$PROJECT_ID" \
--location="$REGION" \
--member="serviceAccount:$NODE_SA" \
--role=roles/artifactregistry.reader两条命令都编辑 IAM policy，区别是附着资源。也可 get-iam-policy 导出、编辑后 set-iam-policy 写回，须保留其他授权及 etag。
收窄到单仓库时，先保留 Repository binding，再撤销多余 Project binding，并检查 Folder / Organization 等其他授权来源；只删 Repository binding 无法消除 Project 继承权限。仓库访问控制
3. 最容易混淆的三种授权#
| 操作 | role 与授权位置 |
|---|---|
| 部署者将某个 SA 挂到 Cloud Run/VM | 在该 SA 上授予 roles/iam.serviceAccountUser，提供 actAs |
人使用 --impersonate-service-account 签发该 SA 的短期凭据 |
在该 SA 上授予 roles/iam.serviceAccountTokenCreator |
| 外部 federated identity 通过 SA 调用 API | 在该 SA 上授予限定 Principal 的 roles/iam.workloadIdentityUser |
这些都不会自动赋予 SA 读取 Bucket 的权限；必须另外在 Bucket 或所属的 Project / Folder / Organization 上给 SA 授予适用的读取权限。actAs 也不等于可以直接生成 token。Service Account 认证 role
人/CI --可部署服务 + actAs--> Cloud Run
Cloud Run --运行时 SA + Bucket 授权--> Cloud Storage部署权与高权限 SA 的 actAs 组合可能导致权限扩大，所以不能随意授予。
与 AWS AssumeRole 对照#
Service Account impersonation 类似 AWS AssumeRole：先取得目标身份的短期凭据，再以它访问资源。AWS IAM Role 是身份；GCP IAM role 是权限集合，与前者类比的是 Service Account。 官方说明
| 环节 | AWS | GCP |
|---|---|---|
| 谁可以切换到目标身份 | 目标 Role 的 Trust policy（信任策略）决定信任谁；调用者还需满足相应的 sts:AssumeRole 授权与条件 |
在目标 SA 上给调用者授予 roles/iam.serviceAccountTokenCreator |
| 切换后能做什么 | 目标 Role 的权限策略及适用的资源策略等决定 | 给目标 SA 授予的资源 role 及其他适用策略决定 |
| 获取短期凭据 | 调用 AWS STS（Security Token Service，安全令牌服务）的 AssumeRole |
gcloud 根据 impersonation 参数申请目标 SA 的短期凭据 |
AWS 的显式调用示例（替换账号 ID 和 Role 名）：
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/BucketReader \
--role-session-name bucket-read-lab该命令返回临时 key、session token 和过期时间，后续请求须使用这些凭据。也可在 AWS CLI profile 配置 role_arn / source_profile，通过 --profile 自动管理。AWS Role profile
GCP 则可以在访问命令上直接指定目标 SA（变量及授权步骤见 Bucket 实验）：
gcloud storage cat "gs://$IAM_BUCKET/example.txt" \
--impersonate-service-account="$READER"gcloud 自动申请 SA 短期凭据完成本次请求，仅按目标 SA 的资源权限检查，不叠加操作者权限。未指定或配置 impersonation 时使用当前 gcloud 身份。impersonation