GCP 人员账号与 Workload / Workforce Identity Federation

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

先读 IAM 授权模型。本篇说明人员账号从哪里来，以及程序身份和人员身份如何联合。

公司从零配置的操作顺序见公司身份与组织初始化：域名、Cloud Identity、管理员、员工与组、组织和项目授权。

人员账号在哪里创建#

GCP IAM 管授权，不在 Project 中创建人员 IAM User。 人员来自 Google Account、Cloud Identity、Google Workspace 或外部身份系统；不要照搬 AWS IAM User 的创建流程。

没有外部身份系统、也未配置 Identity Federation 时，人员通常使用 Google Account 登录；Google Account 不等于 Gmail 邮箱账号，Cloud Identity 管理的 alice@company.com 也属于 Google 账号。人员身份

现有条件	人员身份方案
个人学习或少量协作人员	使用各自的 Google Account，并按 Organization Policy 允许的范围授权
公司没有身份系统，希望统一管理员工	注册 Cloud Identity、验证公司域名，在 Google Admin console 创建员工账号和 Google Group
已有 Google Workspace	复用已有员工账号和 Google Group
已有 Entra ID、Okta 等外部身份系统	可配置 Workforce Identity Federation，让员工使用已有外部身份

Cloud Identity 是 Google 提供的身份管理服务，提供 Free 版本，不要求先部署 AD/Okta，也不要求购买 Gmail 邮箱服务。版本说明、注册与域名设置

例如 30 人开发团队：每人一个独立的公司管理账号 → 加入 developers@company.com 组 → 给组授予开发项目权限。成员使用自己的账号执行 gcloud auth login，本地应用可使用自己的用户 ADC；需要以开发 SA 身份测试时，再给组授予该 SA 的 Token Creator，让成员分别 impersonate 该 SA。不需要每人创建一个 SA，也不需要给每个人分发 SA 长期密钥。 离职时停用员工账号并移除组成员资格，授权变更仍需考虑传播及已签发凭据。

与 AWS IAM Identity Center 的使用体验相比，GCP 通常以同一人员身份访问多个 Project，各项目分别授权，切换项目不会切换身份；通常无需先选择一个 GCP IAM role 登录。GCP IAM role 是权限集合；需要以另一种工作负载身份访问时，才使用 Service Account impersonation 等机制。身份认证与本地 ADC 见 CLI、ADC 与 Terraform。Workforce 登录

Workload 与 Workforce：程序身份和人员身份#

两者都是让 GCP 信任外部身份证明的 federated identity 机制，Workload 面向程序，Workforce 面向人；不是两种 SA，也不是两种权限 role。

对比	Workload Identity Federation	Workforce Identity Federation
谁访问 GCP	应用、自动化任务、外部工作负载	员工、合作伙伴等人员
典型身份来源	GitHub Actions、AWS/Azure 上的程序、外部 Kubernetes	Microsoft Entra ID、Okta 等企业身份系统
外部证明的内容	例如任务所属仓库、分支和工作流	例如用户身份、所属人员组
identity pool 归属	Project	Organization
使用方式	federated identity 直接访问资源，或继续 impersonate 获授权的 SA	使用外部人员身份访问控制台、CLI 或支持的应用

外部凭据文件实验是“GitHub 任务 → OIDC token → GCP”，所以使用 Workload。员工“登录企业 Okta/Entra ID → GCP”则使用 Workforce；员工直接用 Cloud Identity / Google Workspace 的 Google 账号登录，通常不需要 Workforce federated identity。两者认证成功后仍需 IAM 授权，不会因为身份受信任就自动获得资源访问权限。Workload 概述、Workforce 概述