本页面介绍了 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) 和组织政策提供逻辑连接点。IAM 和组织政策均通过层次结构继承，层次结构中每个资源的有效政策是对该资源直接应用的政策与从其祖先实体继承而来的政策组合的结果。
下图显示了完整的 Google Cloud 资源层次结构示例：
组织资源
组织资源代表组织（例如公司），是 Google Cloud 资源层次结构中的根节点（如果存在）。组织资源是文件夹和项目资源的层次结构祖先实体。应用于组织资源的 IAM 访问权限控制政策适用于整个组织中所有层次结构。
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 Workspace 超级用户在 Google Cloud 方面的主要职责是向其网域内的相应用户分配组织管理员 IAM 角色。上述机制有助于实现用户通常寻求的 Google Workspace 和 Google Cloud 管理责任的分离。
组织资源的优势
通过组织资源，项目资源属于您的组织，而非创建项目的员工。这意味着，当员工离职时，项目资源不会再被删除，而是会遵循组织资源在 Google Cloud 上的生命周期。
此外，组织管理员可以集中控制所有资源。他们可以查看和管理您公司的所有项目资源。这种强制执行机制意味着，不能再有影子项目或流氓管理员了。
此外，您还可以在组织层级授予角色，组织资源下的所有项目和文件夹资源都会继承这些角色。例如，您可以在组织级别向网络团队授予 Network Admin 角色，使他们有权管理公司所有项目资源中的所有网络，而不是授予他们单个项目资源的角色。
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"
}
}
新创建的组织资源的初始 IAM 政策会向整个 Google Workspace 网域授予 Project Creator 和 Billing Account Creator 角色。这意味着用户将能够像在组织资源存在之前一样继续创建项目资源和结算帐号。创建组织资源时，不会创建其他资源。
文件夹资源
文件夹资源可以选择在项目之间提供额外的分组机制和隔离边界。组织资源可以视为组织资源中的子组织。文件夹资源可用于为公司内的不同法人实体、部门和团队建模。例如，第一级文件夹资源可用于表示您组织中的主要部门。由于文件夹资源可以包含项目资源和其他文件夹，因此每个文件夹资源可以包含其他子文件夹以表示不同的团队。每个团队文件夹可以包含其他子文件夹以表示不同应用。如需详细了解如何使用文件夹资源，请参阅创建和管理文件夹资源。
如果您的组织资源中存在文件夹资源，并且您具有相应的查看权限，则可以从 Google Cloud 控制台查看它们。如需了解详细说明，请参阅查看或列出文件夹和项目资源。
借助文件夹资源，您可以授予管理权限，例如，可以向每个部门的主管授予属于其部门的所有 Google Cloud 资源的完整所有权。同样，对资源的访问可能受到文件夹资源的限制，因此一个部门的用户只能在该文件夹资源中访问和创建 Google Cloud 资源。
以下代码段展示了文件夹资源的结构：
{
"createTime": "2030-01-07T21:59:43.314Z",
"displayName": "Engineering",
"lifecycleState": "ACTIVE",
"name": "folders/634792535758",
"parent": "organizations/34739118321"
}
与组织和项目资源一样，文件夹资源充当 IAM 和组织政策的政策继承点。针对文件夹资源授予的 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 政策会向项目创建者授予所有者角色。
IAM 政策继承
Google Cloud 提供了 IAM，可让您分配对特定 Google Cloud 资源的精细访问权限，并防止对其他资源进行不必要的访问。IAM 允许您通过在资源上设置 IAM 政策来控制谁（用户）对哪些资源具有什么访问权限（角色）。
您可以在组织级层、文件夹级层、项目级层或（在某些情况下）资源级层设置 IAM 政策。资源会沿用父级资源的政策。如果在组织级层设置政策，则组织的所有子文件夹和项目资源都会继承该政策，并且如果您在项目级别设置政策，则组织的所有子级资源都会继承该政策。
资源的有效政策是指为该资源设置的政策与从其祖先继承而来的政策的集合。这种继承具有传递性。换句话说，资源会继承项目的政策，项目会沿用组织资源的政策。因此，组织级政策也适用于资源级。
举例来说，在上面的资源层次结构图中，如果您对文件夹“Department Y”设置了向 bob@example.com 授予 Project Editor 角色的政策，那么 Bob 在“Development project”、“Test project”和“Production project”上具有 Editor 角色。反之，如果您在“Test Project”项目上向 alice@example.com 分配 Instance Admin 角色，那么她将只能管理该项目中的 Compute Engine 实例。
角色始终会被继承，无法显式地移除在资源层次结构的更高级层授予更低级层资源的权限。在上述示例中，即使您要在“Test Project”中移除 Bob 的 Project Editor 角色，他仍会从“Department Y”文件夹继承该角色，因此他在“Test Project”中仍然拥有该角色的相应权限。
IAM 政策层次结构遵循与 Google Cloud 资源层次结构相同的路径。如果更改资源层次结构，政策层次结构也会发生更改。例如，将项目移到组织资源中后，项目的 IAM 政策会更新为继承组织资源的 IAM 政策。同样，将项目资源从一个文件夹资源移动到另一个文件夹资源也会更改继承的权限。当项目资源移动到新的文件夹资源时，项目资源从原始父资源继承的权限将丢失。在目标文件夹资源移动时，项目资源会继承其设置的权限。