Google Cloud 的结构与 Microsoft 的三棵边界树（身份租户、资源订阅、计费账户）可以对应，但每一层的名称、归属与授权方向都不同。评估谷歌体系的第一步不是打开控制台，而是承认其多业务单元的事实：消费者侧的 Google 账号、Workspace（含 Cloud Identity）的域账号、Google Cloud 的项目与组织，是三条商务线；它们共享同一套账号协议，而边界由三件事决定——谁认证你、你的令牌能进哪个产品域、你的消费记在谁的账上。

多 BU 的边界在结算侧最直白：Cloud Billing account 统计 Google Cloud、Google Maps Platform、Firebase 和 Google AI Studio 的用量，按产品线记账而非按客户记账；而 Google payments profile 连接整个 Google 家族——Ads、Cloud、Workspace、Fi 共用同一份付款资料，云管理员在 IAM 里看不见它。工程侧同样是这个投影：谷歌按产品域分别暴露 MCP 端点（BigQuery、Cloud Storage、Compute Engine、Cloud Billing、Resource Manager、IAM），端点独立、工具集独立，认证共用同一个 OAuth 2.0 Bearer token。token 统一、授权面分立，这就是“部门”在技术上的形态。

一、资源树：organization、folder、project

资源层级的定义：除最高层外，每个资源恰好有一个父节点；层级由 organization（根）、folder（可选，分组用）、project（实际资源的容器）三层组成，Compute Engine 虚拟机、存储桶、数据集等服务资源挂在项目之下。

organization（根，锚定 Workspace/Cloud Identity 域）
└── folder（可选，分组用）
    └── project（实际资源的容器）
        └── 服务资源：VM、bucket、数据集、密钥……

三个要点。

第一，单亲规则。除根之外每个资源恰好一个父节点，没有“一个项目挂多个组织”或“一个 folder 跨组织”的设计；任何跨边界的访问都是 IAM 授权的叠加，不是层级结构的合并。树内是继承，树外是显式授权——显式授权可审计，也应是侦察重点。

第二，组织节点不是云侧创建的。它跟随 Google Workspace 或 Cloud Identity 账户存在，且一个账户只能关联一个 organization。组织节点有四个属性：组织 ID、由 Workspace 主域名生成的显示名、创建时间、作为 owner 的 Directory API customer ID（不可变更）。域名层面的归属决定云层面的归属上限。

第三，初始授权需要复核。organization 创建时，默认 allow policy 可将 Project Creator 与 Billing Account Creator 角色授予 Workspace 域；组织管理员应核对是否符合本组织的最小权限要求。受管用户创建的项目通常归入 organization，既有项目的父资源与所有权则应单独确认。无父节点的项目可能来自个人、未受管账号或历史配置，也可能迁入 organization。项目通常由组织而非创建它的员工持有；组织删除会影响其下资源，因此需为项目生命周期安排明确的转移和归档流程。

层级之上有三条独立的继承链：allow、deny、organization policy。每个资源的最终策略是“直接作用于该资源的策略”与“从祖先继承的策略”的合成，deny 可以凌驾 allow 之上。评估某资源最终允许什么时，三条链都要算完；只看 IAM 面板会漏掉 deny 与组织策略的约束。

我会将没有组织父节点的项目列入资产核对：确认其所有者、计费方式、数据位置和迁移状态。它们可能来自个人或未受管账号，也可能是历史遗留项目；应逐项确认，而不要仅凭是否挂在组织下推断其来源或风险。

二、身份树：谷歌没有“租户”对象

微软体系最清晰的锚是 Entra 租户；谷歌没有对应物。最接近的结构是“Workspace/Cloud Identity 账户 + organization 节点”的组合，而这两者分别住在邮箱侧和云侧。谷歌的“身份树”要按账号类型读，而不是按容器读。

三类账号。第一类是消费者账号：@gmail.com 结尾，没有任何管理方，只能进入免费层资源，或作为 IAM principal 被显式授权。第二类是受管账号：Workspace 或 Cloud Identity 域下的用户，有 Admin console、有组织节点、有目录。第三类是未受管账号（unmanaged account）：用户先用工作邮箱地址注册了个人账号或未受管的工作账号，之后公司再建立同名受管账号——同一个邮箱地址背后站着两个账号体系。

冲突规则直接由此而来：两个账号不能共享同一个用户名；向 Cloud Identity 添加用户之前，应先审查并解决潜在的冲突账户。登录框完全相同，账户体系截然不同。这既是社工钓鱼的天然土壤，也解释了“一个邮箱的项目权限与邮箱权限对不上”这类现场怪象。

放进 IAM 视角，principal 的类型包括 user、serviceAccount、group、domain，以及联邦体系下的 principalSet。值得注意的是 domain 这种 principal——组织初始授权正是把 Project Creator 和 Billing Account Creator 授予了整个域。“这个域”本身就是一个可以被授予权限的主体；任何 domain principal 的绑定都值得单独立账，因为它的影响面是全目录。

三、服务凭证：三种形态与一条链

服务账号和用户一样可以获取 OAuth 2.0 访问令牌调用 Google API，但路径不同。凭证分两大类：短时凭据与密钥。

短时凭据是推荐路径，默认访问令牌一小时过期。获取方式大多自动完成：gcloud --impersonate-service-account 生成短时凭据并以该身份执行命令；挂在 Compute Engine 实例上的服务账号由客户端库通过应用默认凭据（ADC）取得短时凭据；工作负载身份联邦让客户端库用外部 IdP 的凭据换取短时凭据。Service Account Credentials API 也可手动签发三类凭证：OAuth 2.0 访问令牌、OIDC ID 令牌、自签 JWT。

密钥是另一极。服务账号密钥是长期凭证；持有密钥的任何一方都能以该服务账号身份签发 JWT 并换取访问令牌。密钥文件本身不绑定任何主机、进程或人——这正是它与短时凭据的本质差别：短时凭据有签发链路可审计（多数服务会记录“谁模拟了谁”），密钥文件的使用在日志里只表现为服务账号自己。

工作负载身份联邦是密钥的替代路径，适用面包括：X.509 客户端证书、AWS 或 Azure 上的工作负载、本地 Active Directory、GitHub/GitLab 部署流水线，以及任何支持 OIDC 或 SAML 2.0 的 IdP。机制遵循 OAuth 2.0 token exchange 规范（RFC 8693）：外部凭据交给 Security Token Service，验证后换回联邦令牌。授权有两条路：direct access（角色直接授予联邦身份主体）和 service account impersonation（授予模拟某个服务账号的能力）。工程结构是 workload identity pool 与 pool provider；还支持把 JWKS 直接上传到 pool，服务不能暴露公网 OIDC 端点的环境（自托管 CI、企业内网平台）。

把这些串起来的是应用默认凭据（ADC）的查找链：环境变量指定的凭据文件 → gcloud 安装的用户凭据 → 附加在计算资源上的服务账号，客户端库按此顺序查找。计算资源上的服务账号还有第四条取凭路径：元数据服务，工作负载通过内部端点取得 attached 服务账号的令牌。

评估服务凭证面时按三条链计数：文件链（SA key、ADC 顺序、gcloud 配置——谁拿到文件谁就是它）、协议链（WIF pool/provider——外部身份换云身份，信任关系是可枚举的配置）、运行时链（attached SA 与元数据服务——位置即身份）。三条链的检测信号完全不同：文件链看文件落地，协议链看 token exchange 的配置变化，运行时链看元数据端点的非常规访问。SSRF 在云上之所以是高危，正是因为它把第三条链暴露给了第一条链的攻击者——从“让服务器替我发请求”升级为“拿到当前虚拟机身份的令牌”。只盯一条，另外两条就是盲区。

四、结算树：三层账户

谷歌的结算体系分三层，且三层分属不同世界：Cloud Billing account 是云侧资源，Google payments profile 与 payments account 是谷歌级账户体系。

第一层，Cloud Billing account：云控制台管理的云级资源，记账对象是所有链接到该结算账户的项目，覆盖 Google Cloud、Google Maps Platform、Firebase、Google AI Studio 的用量；单一币种结算；自助式（self-serve，在线开通、信用卡付款）账户按账户出具月度对账单，账期类（invoiced）账户按账户出具单张发票；另有子账户（subaccounts）形态，面向经销商场景。

第二层，Google payments account：与 Cloud Billing account 链接并为其产生的费用付款，被分配 charging cycle（预付或后付），同时是票据中心——发票、对账单、付款历史归其管理，并控制谁可以查看与接收发票。

第三层，Google payments profile：谷歌级资源，由 Google payments center 管理，连接全部 Google 服务，存储支付工具、国家地区、税号与责任人信息，并拥有独立于 Cloud IAM 的 payments 用户与权限体系。

Google payments profile（谷歌级，全家桶共享）
└── Google payments account（充电周期/票据中心）
        │  被链接、代付款
        ▼
Cloud Billing account（云级资源，单一币种）
        │  记账
        ▼
project（实际产生用量的地方）

结算面的授权是独立的 IAM 体系，角色分工如下：

  • Billing Account Creator（roles/billing.creator）：组织级，只能创建自助式结算账户。控制该角色的人数，否则组织外会长出不受追踪的云开销。
  • Billing Account Administrator（roles/billing.admin）：结算账户的 owner 角色，管理付款方式、付款资料、导出配置、成本查看、手工付款、项目链接/解链、以及结算账户上的其他角色。
  • Billing Account Costs Manager（roles/billing.costsManager）：预算与成本导出，碰不到定价与付款方式。
  • Billing Account Viewer（roles/billing.viewer）：只读成本与交易，通常面向财务团队。
  • Billing Account User（roles/billing.user）：将项目链接到结算账户，权限极窄，可广授。
  • Project Billing Manager（roles/billing.projectManager）：配合 Billing Account User 完成项目挂载/解绑，不授予任何资源权限。

项目的挂载与解绑由两个角色协作完成，资源权限与付款权限在角色设计上被切开：Project Owner 可以让渡项目的结算管理权而不让渡资源访问权。

billing.admin 可以关闭、重新启用或移动结算账户，并管理项目关联与其他结算角色。这些是会影响付款、账单归属和服务连续性的高影响操作，应通过职责分离、审批与变更审计进行控制。评估项目结算关系时，我会同时核对结算账户的 IAM 绑定和项目的 billing 关联状态。

五、树与树之间的信任桥

三棵树之间有四座桥。

第一座，域名 → organization 节点：organization 的 owner 是 Directory API customer ID，一个 Workspace/Cloud Identity 账户只能关联一个组织，邮箱侧的域是云侧树根的锚。

第二座，超级管理员 → Organization Administrator：Workspace 超级管理员是域名所有权的验证人与找回联系人，因此默认被授予分配 IAM 角色的能力，其在 Google Cloud 侧的主要职责是把 Organization Administrator 角色授予域内合适的人。这是 Workspace 与 Cloud 管理职责的分离设计，同时是一条身份树通向资源树的固定通道。

第三座，域 → 项目与结算账户的出生权：初始 allow policy 把 Project Creator 与 Billing Account Creator 授予整个域，全目录的普通用户默认就是资源树的创世用户。

第四座，project ↔ Cloud Billing account 的动态链接：挂载与解绑随时可发生，资源树与结算树之间不是静态父子关系，而是一组可随时改写的边。

 Workspace 域（邮箱侧）                Cloud 侧
 ┌────────────────────┐    锚定    ┌──────────────────────┐
 │ 域名 + Directory    │ ────────→ │ organization 节点      │
 │ customer ID        │           │ （owner 不可改）        │
 │                    │           └──────────────────────┘
 │ 超级管理员          │  默认可授  ┌──────────────────────┐
 │                    │ ────────→ │ Organization          │
 │                    │  OrgAdmin │ Administrator 等 IAM  │
 │ 全域普通用户        │ ────────→ │ Project Creator       │
 │                    │  初始授权  │ Billing Acct Creator  │
 └────────────────────┘           └──────────┬───────────┘
                                             │ 动态链接
                                  ┌──────────▼───────────┐
                                  │ Cloud Billing        │
                                  │ account ⇄ payments   │
                                  └──────────────────────┘

速记

  1. 谷歌没有统一根：多条商务线各有一套授权面与计费面，靠域名、customer ID、payments profile 缝合。
  2. 资源树单亲规则：树内是继承，树外是显式授权；裸项目只属于免费层或未受管账号。
  3. 一个 Workspace/Cloud Identity 账户只关联一个组织；组织 owner 是 Directory customer ID，创建后不可改。
  4. 组织初始授权把 Project Creator 和 Billing Account Creator 授予整个域——域本身就是 IAM principal。
  5. allow、deny、organization policy 三条独立继承链，最终策略是三条链的合成。
  6. 服务凭证三条链：文件链（SA key/ADC）、协议链（WIF pool/provider）、运行时链（attached SA/元数据服务），检测信号各异。
  7. 短时凭据默认一小时；impersonation 在日志里成对出现主体与被模拟者，密钥文件的使用在日志里只是“它自己”。
  8. 结算是三层：Cloud Billing account（云级）→ payments account（付款）→ payments profile（谷歌级、全家桶共享、独立权限体系）。
  9. billing.admin 可 close/reopen/move/removeFromOrganization：支付路径是可搬动的控制面，不是元数据。
  10. 四座信任桥：域名锚定组织、超管默认可授 IAM、全域初始出生权、项目与结算账户的动态链接——Work 高于 Cloud 的结构基础。

参考

Google Cloud 文档：Cloud Platform resource hierarchy — https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

Google Cloud 文档：Cloud Billing concepts — https://cloud.google.com/billing/docs/concepts

Google Cloud 文档：Cloud Billing access control — https://cloud.google.com/billing/docs/how-to/billing-access

Google Cloud 文档：Service account credentials — https://cloud.google.com/iam/docs/service-account-creds

Google Cloud 文档：Workload Identity Federation — https://cloud.google.com/iam/docs/workload-identity-federation

Google Cloud 文档：How Application Default Credentials works — https://cloud.google.com/docs/authentication/application-default-credentials

Google Cloud 文档：gcloud auth login — https://cloud.google.com/sdk/gcloud/reference/auth/login

Google Cloud 文档：Metadata server — https://cloud.google.com/compute/docs/metadata/overview

Google Cloud 文档：IAM roles overview — https://cloud.google.com/iam/docs/understanding-roles

Google Cloud 文档：MCP servers for Google Cloud — https://cloud.google.com/mcp

Google Cloud 文档：Supported MCP server products — https://docs.cloud.google.com/mcp/supported-products

Google Cloud 文档：Create Cloud Identity user accounts（冲突账户） — https://docs.cloud.google.com/identity/docs/how-to/create-cloud-identity-user-accounts