📚 课程目录第3章身份与访问管理（IAM）生产实践

3. 身份与访问管理（IAM）生产实践

在生产环境中，IAM 不是“建几个账号、发几个角色”这么简单。它要同时解决四件事：人从哪里来（企业目录联邦）、人能做什么（角色与权限最小化）、程序以什么身份运行（服务账号与密钥管理）、事后如何证明合规（审计日志与访问审批）。这四件事构成一条完整的身份治理链，任何一环缺失都会在生产中留下风险敞口。

一、企业目录联邦：让身份只有一个源头

生产环境最忌讳“每个系统一套账号”。推荐做法是把企业目录作为唯一身份源，通过 Cloud Identity 或 Google Workspace 与 Google Cloud 建立联邦关系。典型路径有两种：

Cloud Identity + 外部 IdP 联邦：企业已有 Azure AD、Okta 或 ADFS，通过 SAML 2.0 或 OIDC 将用户身份联邦到 Cloud Identity，用户用企业账号登录 Google Cloud。
Google Workspace 目录同步：企业使用 Google Workspace 作为主目录，通过 GCDS（Google Cloud Directory Sync）或 Directory Sync 将 AD 用户和群组同步到 Workspace，再映射到 Cloud Identity。

关键配置点在于群组映射。生产环境不应把权限直接授予个人，而应授予群组。例如 AD 中的 gcp-prod-network-admins 同步到 Cloud Identity 后，在 IAM 中把 roles/compute.networkAdmin 授予该群组。人员入职、转岗、离职只需在 AD 中调整群组成员，Google Cloud 侧权限自动跟随，避免“人走了权限还在”。

联邦配置完成后，务必验证：用户能否通过企业 SSO 登录、群组是否按预期同步、离职用户是否在下次登录时被拒绝。建议在预发环境先用 3～5 个测试账号走通全流程。

二、角色与权限最小化：从“能干活”到“只干该干的”

Google Cloud 的 IAM 角色分为三类：基本角色（Owner/Editor/Viewer）、预定义角色（如 roles/storage.objectViewer）、自定义角色。生产环境应严格限制基本角色，尤其是 Owner 和 Editor，它们权限过大且无法精细控制。

最小化的落地方法是“按职责建群组，按群组授角色，按资源设边界”。例如一个生产项目中有三类人：

职责	群组示例	授予角色	作用范围
网络运维	gcp-prod-network-admins	roles/compute.networkAdmin	项目级
应用部署	gcp-prod-app-deployers	roles/container.developer	GKE 集群级
审计查看	gcp-prod-auditors	roles/logging.viewer + roles/iam.securityReviewer	组织级

对于需要更细粒度的场景，可以创建自定义角色。例如只允许某团队重启特定实例，可定义包含 compute.instances.reset 和 compute.instances.get 的自定义角色，而不是给 roles/compute.instanceAdmin.v1。自定义角色应遵循“先最小、再按需加”的原则，每次加权限都要有工单记录。

三、服务账号与密钥管理：程序身份的生命周期

服务账号是给应用程序、CI/CD、批处理任务使用的非人类身份。生产环境的核心原则是：能不用密钥就不用密钥。

优先使用 Workload Identity Federation：让外部工作负载（如 GitHub Actions、AWS、Azure）通过 OIDC 令牌换取短期 Google Cloud 凭证，完全避免长期密钥。
GKE 使用 Workload Identity：Pod 通过 Kubernetes ServiceAccount 绑定 Google ServiceAccount，无需在集群内挂载 JSON 密钥。
必须用密钥时：为每个服务账号单独创建密钥，设置 90 天轮换策略，密钥文件存入 Secret Manager，禁止提交到代码仓库。

服务账号本身也要最小化：不要给默认计算服务账号 Editor 权限；为每个应用创建独立服务账号，只授予其运行所需的最小角色。例如一个只读取 Cloud Storage 的批处理任务，服务账号只需 roles/storage.objectViewer，并限定到特定桶。

# 示例：为服务账号绑定最小权限（仅示意）
gcloud projects add-iam-policy-binding my-prod-project \
  --member="serviceAccount:batch-reader@my-prod-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer" \
  --condition='resource.name.startsWith("projects/_/buckets/prod-batch-input")'

四、审计日志与访问审批：让每次访问都有据可查

生产环境必须开启 Cloud Audit Logs，其中 Admin Activity 日志默认开启且不可关闭，Data Access 日志默认关闭但生产环境建议对敏感服务（如 Cloud Storage、BigQuery、Secret Manager）开启。日志应集中导出到独立的日志桶或 BigQuery 数据集，保留至少 365 天，并设置基于日志的告警。

访问审批流程则解决“临时提权”问题。推荐使用 Privileged Access Manager（PAM） 或基于工单的审批机制：用户需要临时 Owner 权限时，提交申请并说明原因、时长（如 2 小时），由审批人批准后自动授予，到期自动回收。所有审批记录进入审计日志，形成“申请—审批—授予—使用—回收”的闭环。

把上述四块串起来看，生产 IAM 的落地顺序通常是：先打通目录联邦，确保身份源唯一；再按群组和职责设计角色绑定，落实最小权限；然后梳理所有服务账号，消除长期密钥；最后开启审计日志并建立临时提权审批。每一步都应有明确的验证方式：联邦看登录成功率与群组同步延迟，权限看 IAM 推荐器（IAM Recommender）的过度授权建议，密钥看是否有 90 天未轮换的密钥，审计看日志是否完整导出且告警是否触发。只有形成“可验证”的闭环，IAM 才真正具备生产可用性。