本页面介绍了 Google Cloud 资源层次结构以及可使用 Resource Manager 管理的资源。
Google Cloud 资源层次结构有两个用途：
- 提供所有权层次结构，该层次结构将资源的生命周期绑定到层次结构中该资源的直接父级。
- 为访问权限控制和组织政策提供连接点与继承机制。
打个比方， Google Cloud 资源层次结构与传统操作系统中的文件系统类似，能够以分层方式组织和管理实体。一般来说，每项资源有且仅有一个父项。通过这种分层化的资源组织方式，您可以对父资源设置访问权限控制政策与配置设置，并且子资源可以继承这些政策与 Identity and Access Management (IAM) 设置。
Google Cloud 资源层次结构详细介绍
Google Cloud 资源以分层方式进行整理。除层次结构中的最高资源外，所有资源有且仅有一个父项。在最低级层上，服务资源是构成所有 Google Cloud 服务的基本组成部分。服务资源的示例包括 Compute Engine 虚拟机 (VM)、Pub/Sub 主题、Cloud Storage 存储分区和 App Engine 实例。所有这些较低级层资源的父级都是项目资源，项目资源代表 Google Cloud 资源层次结构的第一个分组机制。
所有用户（包括免费试用用户、免费层级用户以及 Google Workspace 和 Cloud Identity 客户）都可以创建项目资源。Google Cloud 免费计划的用户只能在项目中创建项目资源和服务资源。项目资源可以位于其层次结构的顶部，但前提是该资源是由免费试用用户或免费层级用户创建的。Google Workspace 和 Cloud Identity 客户可以使用 Google Cloud 资源层次结构的其他功能，例如组织资源和文件夹资源。如需了解详情，请参阅 Cloud Identity 概览。 位于层次结构顶部的项目资源没有父资源，但一旦为网域创建了组织资源，就可以将这些项目资源迁移到组织资源中。如需详细了解如何迁移项目资源，请参阅迁移项目资源。
Google Workspace 和 Cloud Identity 客户可以创建组织资源。每个 Google Workspace 或 Cloud Identity 账号只能与一个组织资源关联。如果组织资源存在，则它是 Google Cloud 资源层次结构的顶���，属于某个组织的所有资源都在组织资源下划分成组。这使您可以集中查看和控制属于组织资源的所有资源。
文件夹资源是组织资源和项目资源之间的一种额外的可选分组机制。您必须拥有组织资源才能使用文件夹。文件夹资源及其子项目资源映射到组织资源下。
通过 Google Cloud 资源层次结构，尤其是包含组织资源和文件夹资源的最完整形式，公司可以将其组织资源映射到 Google Cloud 上，并为访问权限管理政策 (IAM) 和组织政策提供逻辑连接点。允许政策、拒绝政策和组织政策均通过层次结构继承，层次结构中每个资源的有效政策是对该资源直接应用的政策与从其祖先继承而来的政策组合的结果。
下图展示了完整形式的 Google Cloud 资源层次结构示例：
组织资源
组织资源代表一家组织（例如，公司），同时也是Google Cloud 资源层次结构中的根节点（如果存在）。组织资源是文件夹资源和项目资源的层级祖先。应用于组织资源的允许政策和拒绝政策适用于组织中所有资源的整个层次结构。
Google Cloud 用户无需拥有组织资源，但如果没有组织资源，Resource Manager 的一些功能将无法使用。组织资源与 Google Workspace 或 Cloud Identity 账号密切关联。当具有 Google Workspace 或 Cloud Identity 账号的用户创建 Google Cloud 项目资源时，系统会自动为该用户预配组织资源。
每个 Google Workspace 或 Cloud Identity 账号只能预配一个组织资源。为网域创建组织资源后，账号网域成员创建的所有新 Google Cloud 项目资源都将默认属于该组织资源。当受管理的用户创建项目资源时，该项目资源必须位于某个组织资源中。如果用户指定了一个组织资源，并且他们具有合适的权限，则项目将分配给该组织。否则，项目将默认分配给与用户关联的组织资源。与组织资源相关联的账号无法创建未与组织资源相关联的项目资源。
与 Google Workspace 或 Cloud Identity 账号关联
为简单起见，我们将使用 Google Workspace 指代 Google Workspace 和 Cloud Identity 用户。
Google Workspace 或 Cloud Identity 账号代表公司，也是访问组织资源的前提条件。在 Google Cloud 环境中，该账号提供身份管理、恢复机制、所有权和生命周期管理。下图显示了 Google Workspace 账号、Cloud Identity 和Google Cloud 资源层次结构之间的关联。
Google Workspace 超级用户负责网域所有权验证，并担任需要执行恢复时的联系人。因此，默认情况下，系统会向 Google Workspace 超级用户授予分配 IAM 角色的能力。对于 Google Cloud ，Google Workspace 超级用户的主要职责是��其网域内的相应用户分配组织管理员 IAM 角色。上述机制有助于实现用户通常寻求的 Google Workspace 和 Google Cloud管理责任的分离。
组织资源的优势
有了组织资源后，项目资源便会归属于您的组织，而非创建该项目的员工。这意味着，当员工离职时，项目资源不再会被系统删除，而是将追随组织资源在 Google Cloud上的生命周期。
此外，组织管理员可以集中控制所有资源。 他们可以查看和管理您公司的所有项目资源。这种实施机制意味着，不会再有影子项目或未获授权的管理员了。
此外，您可以在组织级层授予角色，组织资源下的所有项目和文件夹资源都将继承这些角色。例如，您可以在组织级层向网络团队授予网络管理员角色，允许他们管理您公司里所有项目资源中的所有网络，而不是向他们授予所有单独项目资源的相应角色。
Cloud Resource Manager API 提供的组织资源包括：
- 组织资源 ID，这是组织的唯一标识符。
- 显示名，根据 Google Workspace 或 Cloud Identity 中的主域名生成。
- 组织资源的创建时间。
- 组织资源的最后修改时间。
- 组织资源的所有者。所有者是在创建组织资源时指定的，一经设置便无法更改。是在 Directory API 中指定的 Google Workspace 客户 ID。
以下代码段展示了组织资源的结构：
{
"creationTime": "2020-01-07T21:59:43.314Z",
"displayName": "my-organization",
"lifecycleState": "ACTIVE",
"name": "organizations/34739118321",
"owner": {
"directoryCustomerId": "C012ba234"
}
}
新创建的组织资源的初始允许政策向整个 Google Workspace 网域授予 Project Creator 和 Billing Account Creator 角色。这意味着，用户将能够继续创建项目资源和结算账号（和组织资源存在之前一样）。创建组织资源时，不会创建其他资源。
文件夹资源
文件夹资源可选择性地在项目之间提供额外的分组机制和隔离边界。文件夹资源可以视为组织资源内的子组织。文件夹资源可用于为公司内的不同法律实体、部门和团队建模。例如，第一级文件夹资源可用于表示组织资源中的主要部门。由于文件夹资源可以包含项目资源和其他文件夹，因此每个文件夹资源可以包含其他子文件夹以表示不同团队。每个团队文件夹可以包含其他子文件夹以表示不同应用。如需详细了解如何使用文件夹资源，请参阅创建和管理文件夹资源。
如果您的组织资源中存在文件夹资源，并且您具有相应的查看权限，则可以从 Google Cloud 控制台中查看这些资源。如需了解详情，请参阅查看或列出文件夹和项目资源。
文件夹资源允许委派管理权，例如，可以向每位部门主管授予属于其部门的所有 Google Cloud资源的完整所有权。同样，您也可以使用文件夹资源来限制资源访问权限，使某一部门的用户只能访问特定文件夹资源中的 Google Cloud 资源以及在其中创建 Google Cloud 资源。
以下代码段展示了文件夹资源的结构：
{
"createTime": "2030-01-07T21:59:43.314Z",
"displayName": "Engineering",
"lifecycleState": "ACTIVE",
"name": "folders/634792535758",
"parent": "organizations/34739118321"
}
与组织资源和项目资源一样，文件夹资源充当允许政策、拒绝政策和组织政策的政策继承点。在文件夹资源上授予的 IAM 角色由该文件夹中包含的所有项目和文件夹资源自动继承。
项目资源
项目资源是基础级层的组织实体。组织和文件夹资源可以包含多个项目。项目资源是使用 Google Cloud的必要条件，也是执行以下操作的基础：创建、启用和使用所有Google Cloud 服务；管理 API；启用结算功能；添加和移除协作者；以及管理权限。
所有项目资源都包含以下内容：
- 两个标识符：
- 项目资源 ID，这是项目资源的唯一标识符。
- 项目资源编号，在您创建项目时自动分配。项目编号只读。
- 一个可变的显示名。
- 项目资源的生命周期状态；例如 ACTIVE 或 DELETE_REQUESTED。
- 可用于过滤项目的标签集合。
- 项目资源的创建时间。
以下代码段展示了项目资源的结构：
{
"createTime": "2020-01-07T21:59:43.314Z",
"lifecycleState": "ACTIVE",
"name": "my-project",
"parent": {
"id": "634792535758",
"type": "folder"
},
"projectId": "my-project",
"labels": {
"my-label": "prod"
},
"projectNumber": "464036093014"
}
如要与大多数 Google Cloud 资源交互，您必须为每个请求提供标识性的项目资源信息。您可以通过下述两种方式之一标识项目资源：项目资源 ID 或项目资源编号（代码段中的 projectId 和 projectNumber）。
项目资源 ID 是您在创建项目资源时选择的自定义名称。如果您激活了需要项目资源的 API，则系统会引导您创建项目资源或通过项目资源 ID 来选择项目资源。（请注意，界面中显示的 name 字符串与项目资源 ID 不同。）
项目资源编号由 Google Cloud自动生成。您可以在 Google Cloud 控制台的项目资源信息中心内找到项目资源 ID 和项目资源编号。如需了解如��获取项目标识符及其他项目资源管理任务，请参阅创建和管理项目资源。
新创建的项目资源的初始 IAM 政策会向项目创建者授予所有者角色。
允许和拒绝政策继承
Google Cloud 提供 IAM，可让您分配对特定 Google Cloud 资源的精细访问权限，并防止对其他资源进行不必要的访问。IAM 允许您通过在资源上设置允许政策和拒绝政策来控制谁（用户）对哪些资源具有什么访问权限（角色）。
您可以对组织资源、文件夹资源和项目资源设置允许政策和拒绝政策。您还可以针对某些服务资源设置允许政策。
资源会沿用父级资源的政策。如果您在组织级层设置允许或拒绝政策，则所有子资源都会沿用该政策。如果在项目级层设置允许政策，则项目的所有子资源都会继承该政策。
资源的有效允许或拒绝政策是指为该资源设置的允许或拒绝政策与从其祖先继承而来的允许或拒绝政策的集合。这种继承具有传递性。如需了解详情，请参阅政策评估。
例如，在上面的资源层次结构图中，如果您对“Department Y”文件夹设置了向 bob@example.com 授予 Compute Engine Instance Admin (roles/compute.instanceAdmin) 角色的允许政策，那么 Bob 将在“Development project”“Test project”和“生产环境 project”中拥有该角色。如果您在“Test Project”项目上向 alice@example.com 分配 Compute Engine Instance Admin 角色，那么她将只能管理该项目中的 Compute Engine 实例。
角色始终具有继承性。如果您从“Test Project”中移除了 Bob 的 Compute Engine Instance Admin (roles/compute.instanceAdmin) 角色，他仍会从“Department Y”文件夹继承该角色。您可以使用拒绝政策来防止主账号使用继承的权限。
允许政策和拒绝政策通过 Google Cloud 资源层次结构继承。如果更改资源层次结构，允许政策和拒绝政策层次结构也会发生更改。例如，将项目移到组织资源中会更新该项目的允许政策和拒绝政策，以沿用组织资源的允许政策和拒绝政策。同样，将项目资源从一个文件夹资源移动到另一个文件夹资源将更改继承的权限。将项目资源移动到新的文件夹资源后，该项目资源从原始父资源继承的权限将丢失。项目资源在迁移时会继承在目标文件夹资源设置的权限。