公司首次使用 GCP：身份与组织初始化

验证：未记录

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

适用：公司尚无 Google Workspace / Cloud Identity，希望由公司统一创建员工账号、管理 GCP 权限。已有 Workspace 或 Cloud Identity 时，复用现有目录，从员工与 Google Group 开始，不要重复注册。

公司控制的域名 → Cloud Identity → 管理员、员工账号和 Google Group
                                      ↓
                            GCP Organization → Project
                                      ↓
                              给组授权 → 员工登录验证

1. 准备身份域名#

Cloud Identity 的公司身份目录需要验证域名所有权。准备公司控制的域名及 DNS 管理权限；不需要先建网站，身份域名也不必与产品网站域名相同。没有域名也能用个人 Google 账号访问 GCP，但这不能替代公司统一管理的员工目录。域名规划

另外准备可收信的联系 / 恢复邮箱。Cloud Identity 不提供 Gmail 邮箱托管；admin@example.com 能登录，不代表已经有同名收件箱。管理员通知所需收信能力应通过已有邮件服务或邮件转发安排。准备条件

2. 注册 Cloud Identity 并验证域名#

从 Cloud Identity Free 注册入口开始，填写公司信息、联系邮箱和域名。
创建首个公司管理员，例如 admin@example.com。这是公司管理的 Google 账号，不是项目中的 SA；联系 / 恢复邮箱与这个新账号分开。
按向导取得域名验证记录，在域名 DNS 中添加指定 TXT 记录，再返回确认验证。
登录 Google Admin console，完成服务协议和初始设置。

公司保管域名注册、DNS、管理员恢复方式；安排至少两个独立的超级管理员账号并启用多因素认证，日常开发使用普通员工账号。注册流程、超级管理员实践

3. 创建员工账号与 Google Group#

在 Google Admin console 操作：

入口	操作	示例
Directory → Users → Add new user	创建员工账号，交付初始登录方式，要求首次登录修改密码	`alice@example.com`
Directory → Groups → Create group	创建组，限定成员和组管理权限，禁止员工自行加入管理组	`gcp-admins@example.com`、`developers@example.com`
目标组 → Members	把员工加入相应组	Alice 加入 developers

创建账号和加入组不会自动授予 GCP 资源权限。 员工也不需要各自注册免费试用、创建 Cloud Billing account 或 SA。已有同名个人 Google 账号时，先处理非受管账号冲突，再完成公司账号接管。用户管理、创建组

4. 初始化云组织与管理员授权#

完成身份体系设置后，用公司管理员登录 Google Cloud console，按组织初始化向导确认关联的 Organization（组织资源），并取得组织 ID。不要为每个员工创建一个 Organization。

管理身份 / role	管什么	在哪里配置
Cloud Identity Super Admin	员工、组、身份目录和恢复	Google Admin console
Organization Administrator：`roles/resourcemanager.organizationAdmin`	云组织 IAM 与相关管理	GCP 组织上的 IAM
Billing Account Administrator：`roles/billing.admin`	Cloud Billing account 管理	目标 Billing Account 的 IAM

Organization Admin 不等于所有项目业务数据管理员，也不自动获得 Billing 管理权。 超级管理员完成引导后，把组织管理委派给 gcp-admins@example.com，业务资源和账单分别授权。组织管理角色

5. 建项目、关联账单，再给组授权#

管理员在公司 Organization 下创建开发 Project，关联公司可用的 Billing Account，并设置预算通知；详细命令见环境、项目与账单。

动作	需要的典型授权
在组织 / Folder 下创建项目	在目标父级授予 `roles/resourcemanager.projectCreator`
把项目关联到 Cloud Billing account	账单侧 `roles/billing.user`；项目侧 `roles/billing.projectManager`，或包含相应权限的 role
修改项目 IAM	项目上的 `resourcemanager.projects.setIamPolicy` 权限

按职责给组授权，业务权限尽量放在项目或具体资源上。 下面由有项目 IAM 管理权限的管理员执行，只给开发者组浏览项目层级的权限，作为首次登录验证；之后再按工作需要授予具体服务 role：

export PROJECT_ID='替换为公司开发项目ID'
export DEVELOPERS_GROUP='developers@替换为公司域名'
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="group:$DEVELOPERS_GROUP" \
  --role=roles/browser --condition=None

roles/browser 不提供部署、写入或读取所有业务数据的权限。员工通过组成员资格获得授权，无需逐人重复绑定；开发项目的业务 role 也不应直接授予整个 Organization。项目权限、关联账单所需权限

6. 员工首次登录与验收#

员工使用自己的公司账号完成首次登录并设置多因素认证，然后执行（替换邮箱和项目 ID）：

gcloud auth login alice@example.com
gcloud config set project COMPANY_DEV_PROJECT_ID
gcloud auth list
gcloud projects describe COMPANY_DEV_PROJECT_ID --format='value(projectId)'

验收：当前身份是公司员工账号，能查看获授权项目；未经授权的生产项目或业务操作仍被拒绝。新授权或组成员变更需要等待传播，拒绝时先查权限与身份，不要直接追加 Owner。

仅运行 gcloud 时到这里即可；本地 Terraform / SDK 需要 ADC 时，再执行 gcloud auth application-default login，浏览器中选择同一个员工账号。CLI 与 ADC、多账号隔离

交付结果：公司控制域名和身份恢复，员工账号归公司管理，云资源在公司组织内，项目与账单分别授权，员工通过组获得权限。离职时停用员工账号、移除组成员并检查其他授权及已签发凭据；停用账号不会自动删除项目或云资源。