📚 课程目录第3章 Cloud Identity与Workspace集成

3. Cloud Identity与Workspace集成

在 Google Cloud 的组织治理体系中，身份源决定了“谁是谁、谁属于哪个组、谁可以访问什么”。Cloud Identity 与 Google Workspace 是 Google 官方提供的两种身份源形态：前者是纯身份与访问管理服务，后者在身份管理之外还包含 Gmail、Drive、Meet 等协作套件。二者共享同一套底层目录（Directory）与 Google Cloud 身份体系，因此都可以作为 Google Cloud 组织的主身份源。理解它们的差异、集成路径以及用户与群组同步机制，是后续 IAM 策略、组织策略和最小权限落地的前提。

一、Cloud Identity 与 Workspace 的定位差异

Cloud Identity 可以理解为“只有身份、没有办公套件”的版本。它提供用户账号、群组、安全设置、单点登录（SSO）、多因素认证（MFA）以及设备管理等能力，适合那些已经拥有其他办公协作工具、但希望用 Google 身份体系统一管理云资源访问的企业。Google Workspace 则在 Cloud Identity 的基础上叠加了 Gmail、Calendar、Drive、Docs 等生产力应用，适合直接使用 Google 办公套件的组织。

对 Google Cloud 而言，两者最关键的区别不在身份能力，而在“身份源与云资源的绑定方式”。无论选择哪一种，最终都会在 Google Cloud 中形成一个与组织节点绑定的身份域，例如 example.com。该域下的用户和群组通过 IAM 被授予角色，从而访问项目、文件夹和组织级资源。

如果企业只需要 Google Cloud 的身份治理，不需要 Gmail 等办公应用，优先选择 Cloud Identity，可以降低许可成本并简化管理面。如果企业已经或计划使用 Google Workspace，则直接以 Workspace 作为身份源，避免维护两套目录。

二、集成路径：从域名验证到组织绑定

将 Cloud Identity 或 Workspace 配置为身份源，通常遵循一条清晰的路径：准备域名、注册服务、验证域名所有权、创建组织节点、建立身份域与组织的绑定，最后配置用户与群组同步。下面这张图展示了从域名到云资源访问的完整身份链路，以及用户、群组、IAM 策略之间的数据流关系。

图中左侧是身份源，中间是 Google 目录，右侧是 Google Cloud 组织节点。身份源通过域名验证与目录建立信任，目录再与组织节点绑定，形成“身份域—组织”的对应关系。下方展示了四种常见的同步机制：GCDS 适合从本地 Active Directory 或 LDAP 批量同步；SCIM API 适合与外部 IdP 做自动预配；LDAP 安全同步用于密码校验；群组同步则负责把嵌套组结构完整映射到 Google 目录。

三、用户同步：从本地目录到 Google 目录

用户同步的核心目标是让 Google 目录中的用户列表与源目录保持一致。以最常见的“本地 Active Directory → Google Workspace”场景为例，通常使用 Google Cloud Directory Sync（GCDS）完成。GCDS 的配置包含几个关键对象：LDAP 连接、搜索规则、用户属性映射、群组规则和排除规则。

假设本地 AD 域为 corp.example.com，需要同步到 Google 域 example.com。在 GCDS 中配置 LDAP 连接时，需要填写服务器地址、端口、Base DN 和绑定账号。例如：

LDAP 服务器：ldaps://dc01.corp.example.com:636
Base DN：DC=corp,DC=example,DC=com
绑定 DN：CN=gcds-sync,OU=ServiceAccounts,DC=corp,DC=example,DC=com
搜索规则：(&(objectClass=user)(mail=*@corp.example.com))
用户属性映射：
  mail        → primaryEmail
  givenName   → givenName
  sn          → familyName
  sAMAccountName → userName
排除规则：OU=Disabled,DC=corp,DC=example,DC=com

这段配置的含义是：只同步拥有邮箱属性且位于 corp.example.com 域下的用户，排除已禁用组织单位中的账号。同步完成后，可以在 Google 管理控制台的“目录 → 用户”中看到用户列表，并核对用户数、邮箱格式和账号状态。如果源目录中新增了用户，再次运行 GCDS 即可增量同步；如果用户被禁用或删除，GCDS 会根据规则将其在 Google 目录中标记为暂停或删除。

GCDS 默认不会删除 Google 目录中“源目录不存在”的用户，除非显式启用删除策略。生产环境中建议先启用“仅暂停”而非直接删除，避免误删导致权限丢失。

四、群组同步：让权限继承结构化

群组同步比用户同步更关键，因为 IAM 策略通常绑定到群组而不是单个用户。Google 目录支持两种群组来源：一种是直接在 Google 管理控制台创建的群组，另一种是从源目录同步过来的群组。GCDS 可以把 AD 中的安全组和通讯组同步为 Google 群组，并保留成员关系。

假设 AD 中有如下群组结构：

CN=cloud-admins,OU=Groups,DC=corp,DC=example,DC=com
  成员：alice@corp.example.com, bob@corp.example.com
CN=cloud-developers,OU=Groups,DC=corp,DC=example,DC=com
  成员：carol@corp.example.com, david@corp.example.com
CN=cloud-auditors,OU=Groups,DC=corp,DC=example,DC=com
  成员：eve@corp.example.com

在 GCDS 中配置群组规则时，需要指定群组搜索 Base DN、群组对象类（通常为 group）以及成员属性（通常为 member）。同步后，Google 目录中会出现 cloud-admins@example.com、cloud-developers@example.com 和 cloud-auditors@example.com 三个群组，成员与 AD 保持一致。此时在 Google Cloud IAM 中，就可以直接把这些群组绑定到角色上，例如：

gcloud projects add-iam-policy-binding my-project \
  --member="group:cloud-admins@example.com" \
  --role="roles/owner"

gcloud projects add-iam-policy-binding my-project \
  --member="group:cloud-developers@example.com" \
  --role="roles/editor"

gcloud projects add-iam-policy-binding my-project \
  --member="group:cloud-auditors@example.com" \
  --role="roles/viewer"

这样做的价值在于：当人员变动时，只需要在 AD 中调整群组成员，GCDS 同步后 Google Cloud 的权限会自动跟随变化，无需逐个修改 IAM 策略。这就是“群组驱动权限”的核心逻辑。

五、验证同步结果与常见排障点

同步完成后，建议从三个层面验证：第一，在 Google 管理控制台检查用户和群组数量是否与源目录一致；第二，在 Google Cloud IAM 中确认群组可以被正确识别并绑定角色；第三，用测试用户登录并尝试访问目标资源，观察是否获得预期权限。

常见问题包括：域名未验证导致无法创建用户；GCDS 绑定账号权限不足导致读取不到完整目录；群组嵌套层级过深导致部分成员未同步；用户主邮箱与源目录邮箱不一致导致匹配失败。排查时优先查看 GCDS 的同步日志，日志中会明确列出“已创建、已更新、已跳过、已删除”的对象数量，以及每条规则命中的用户或群组。根据日志定位到具体对象后，再回到源目录或 GCDS 规则中修正，重新运行同步即可。

身份源集成的最终判断标准不是“同步任务是否成功”，而是“用户和群组能否在 Google Cloud IAM 中被正确识别，并据此获得符合预期的访问权限”。只有完成这一步，Cloud Identity 或 Workspace 才真正成为 Google Cloud 的可信身份源。