资源层次结构

本页面介绍了 Google Cloud Platform (GCP) 资源层次结构以及可使用 Resource Manager 管理的资源。

GCP 资源层次结构有两个用途:

  • 提供所有权层次结构,该层次结构将资源的生命周期绑定到层次结构中的直接父项。
  • 为访问权限控制和组织政策提供连接点与继承关系。

打个比方,GCP 资源层次结构与传统操作系统中的文件系统类似,能够以分层方式组织和管理实体。每项资源有且仅有一个父项。这种对资源的分层管理方式让您可以对父项资源设置访问权限控制政策与配置设置,并且子项资源会继承这些政策与 Cloud Identity and Access Management (Cloud IAM) 设置。

详细介绍 GCP 资源层次结构

在最低级层上,资源是构成所有 GCP 服务的基本组成部分。Compute Engine 虚拟机 (VM)、Cloud Pub/Sub 主题、Cloud Storage 存储分区、App Engine 实例都属于资源。所有这些较低级层资源的父级只能是项目,项目代表 GCP 资源层次结构的第一个分组机制。

G Suite 和 Cloud Identity 客户有权访问 GCP 资源层次结构的其他功能,享受集中查看和控制等好处,并且可以使用进一步分组机制,如文件夹。我们已经推出了 Cloud Identity 管理工具。如需详细了解如何使用 Cloud Identity,请参阅迁移到 Cloud Identity

GCP 资源以分层方式进行整理。从层次结构的底层开始算起,项目位于第一层,并包含其他资源。除组织以外的所有资源有且仅有一个父项。组织是层次结构的最高级层,没有父项。

组织资源是 GCP 资源层次结构的根节点,属于某个组织的所有资源都在组织节点下划分成组。这样便于集中查看和控制属于组织的每项资源。

文件夹是基于项目的额外分组机制。您需要拥有组织资源才能使用文件夹。文件夹和项目均映射到组织资源下。

通过 GCP 资源层次结构,尤其是包含组织资源和文件夹的最完整的形式,公司可以将其组织映射到 GCP 上,并为访问权限管理政策 (Cloud IAM) 和组织政策提供逻辑连接点。Cloud IAM 和组织政策均通过层次结构继承,层次结构中每个节点的有效政策是指对该节点直接应用的政策与从其祖先继承而来的政策的结果。

下图显示了完整的 GCP 资源层次结构示例:

资源层次结构

组织资源

组织资源代表一家组织(例如,公司),同时也是 GCP 资源层次结构中的根节点。组织资源是项目资源和文件夹的级层祖先。应用于组织资源的 Cloud IAM 访问控制政策适用于组织中所有资源的整个层次结构。

GCP 用户无需拥有组织资源,但如果没有组织资源,Resource Manager 的一些功能将无法使用。组织资源与 G SuiteCloud Identity 帐号密切关联。当具有 G Suite 或 Cloud Identity 帐号的用户创建 GCP 项目时,系统会自动为其预配组织资源。

每个 G Suite 或 Cloud Identity 帐号可能只有一个预配的组织。为网域创建组织资源后,帐号网域成员创建的所有 GCP 项目都将默认属于组织资源。

为简单起见,我们将使用 G Suite 指代 G Suite 和 Cloud Identity 用户。

G Suite 或 Cloud Identity 帐号代表公司,是访问组织资源的前提条件。在 GCP 环境中,该帐号提供身份管理、恢复机制、所有权和生命周期管理。下图显示了 G Suite 帐号、Cloud Identity 和 GCP 资源层次结构之间的关联。

G Suite 组织


G Suite 超级用户是负责网域所有权验证的个人,如果需要执行恢复,应联系该超级用户。因此,默认情况下,系统会向 G Suite 超级用户授予分配 Cloud IAM 角色的能力。对于 GCP,G Suite 超级用户的主要职责是向其网域内的相应用户分配组织管理员 Cloud IAM 角色。这将带来用户通常寻求的 G Suite 和 GCP 管理责任的分离。

组织资源的优势

通过组织资源,项目属于您的组织,而不属于创建该项目的员工。这意味着当员工离职时,项目不再会被系统删除,而是将追随组织在 Google Cloud Platform 上的生命周期。

此外,组织管理员能够集中控制所有资源。他们可以查看和管理您公司的所有项目。该强制执行意味着,不会再有影子项目或流氓管理员了。

此外,您可以在组织级层授予角色,组织资源下的所有项目和文件夹都将继承这些角色。例如,您可以在组织级层向网络团队授予网络管理员角色,允许他们管理您公司里所有项目中的所有网络,而不是向他们授予所有单独项目的角色。

使用 Resource Manager API 创建的组织资源包括:

  • 组织 ID,这是组织的唯一标识符。
  • 显示名,根据 G Suite 或 Cloud Identity 中的主域名生成。
  • 组织的创建时间。
  • 组织的最后修改时间。
  • 组织的所有者。所有者是在创建组织资源时指定的,一经设置便无法更改。这是在 Directory API 中指定的 G Suite 客户 ID。

以下代码段展示了组织资源的结构:

{
  "displayName": "myorganization",
  "organizationId":"34739118321",
  "createTime": "2016-01-07T21:59:43.314Z"
  "owner": {
    "directoryCustomerId": "C012BA234"
   }
}

新创建的组织资源的初始 Cloud IAM 政策向整个 G Suite 网域授予 Project Creator 和 Billing Account Creator 角色。这意味着,用户将能够继续创建项目和结算帐号(和组织存在之前一样)。创建组织资源时,不会创建其他资源。

文件夹资源

文件夹资源在项目之间提供了额外的分组机制和隔离边界。文件夹资源可以视为组织内的子组织。文件夹可用于给公司内的不同法人实体、部门和团队建模。例如,第一级文件夹可用于表示您组织中的主要部门。由于文件夹可以包含项目及其他文件夹,因此每个文件夹可以包含其他子文件夹以表示不同团队。每个团队文件夹可以包含其他子文件夹以表示不同应用。如需详细了解如何使用文件夹,请参阅创建和管理文件夹

如果您的组织中存在文件夹资源,并且您具有相应的查看权限,则您可以从 Google Cloud Platform Console 查看它们。如需了解详情,请参阅查看或列出文件夹和项目

文件夹允许委派管理权,例如,系统可以向每个部门的主管授予属于其部门的所有 GCP 资源的完整所有权。同样,可通过文件夹来限制对资源的访问权限,因此一个部门中的用户只能在该文件夹中访问和创建云端资源。

以下代码段展示了文件夹的结构:

{
 "name" : "folders/my-folder",
 "parent" : "organizations/my-organization",
 "displayName" : "Engineering",
 "lifecycleState" : "ACTIVE",
 "createTime": "2016-01-07T21:59:43.314Z"
}

与组织和项目一样,文件夹充当 Cloud IAM 和组织政策的政策继承点。在文件夹上授予的 Cloud IAM 角色由该文件夹中包含的所有项目和文件夹自动继承。

项目资源

项目资源是基本级层组织实体。组织和文件夹可以包含多个项目。需要有项目才能使用 Google Cloud Platform,并且项目是执行下列操作的基础:创建、启用和使用所有 GCP 服务;管理 API;启用结算功能;添加和移除协作者以及管理权限。

所有项目由以下内容组成:

  • 两个标识符:
    1. 项目 ID,这是项目的唯一标识符。
    2. 项目编号,在您创建项目时自动分配。项目编号只读。
  • 一个可变的显示名。
  • 项目的生命周期状态;例如 ACTIVE 或 DELETE_REQUESTED。
  • 可用于过滤项目的标签集合。
  • 项目创建的时间。

以下代码段展示了项目的结构:

{
  "name": "myproject",
  "projectId": "my-project-123",
  "labels":
   {
     "my-label": "prod"
   },
   "projectNumber": "464036093014",
   "lifecycleState": "ACTIVE",
   "createTime": "2016-01-07T21:59:43.314Z"
}

要与大多数 GCP 资源交互,您必须为每个请求提供具有识别性的项目信息。您可以通过下述两种方式之一识别项目:项目 ID 或项目编号(代码段中的 projectIdprojectNumber)。

项目 ID 是您在创建项目时选择的自定义名称。如果您激活一个需要项目的 API,系统将引导您使用其项目 ID 创建项目或选择项目。(请注意,界面中显示的 name 字符串与项目 ID 不同)。

项目编号由 GCP 自动生成。项目 ID 和项目编号均可在 Google Cloud Platform Console 的项目信息中心找到。如需了解如何获取项目标识符及项目的其他管理任务,请参阅创建和管理项目

新创建的项目资源的初始 Cloud IAM 政策会向项目创建者授予所有者角色。

Cloud IAM 政策继承

Google Cloud Platform 提供了 Cloud IAM,借助此服务,您可以分配对特定 Google Cloud Platform 资源的更精细的访问权限,并防止对其他资源进行不必要的访问。通过 Cloud IAM,您可以设置针对资源的 Cloud IAM 政策,以控制谁(用户)对哪些资源具有什么访问权限(角色)。

您可以在组织级别文件夹级别项目级别或(在某些情况下)资源级别设置 Cloud IAM 政策。资源会继承父节点的政策。如果您在组织级层设置政策,则其所有子文件夹和项目都会继承该政策,并且如果您在项目级层设置政策,则其所有子项资源都会继承该政策。

资源的有效政策是指为该资源设置的政策与从其祖先继承而来的政策的集合。这种继承具有传递性。换句话说,资源继承项目的政策,项目会继承组织的政策。因此,组织级层的政策也适用于资源级层。

资源层次结构


例如,在上面的资源层次结构图中,如果您对文件夹“Dept Y”设置政策,向 bob@example.com 授予 Project Editor 角色,则 Bob 将对“Dev GCP”、“Test GCP”和“Production”项目具有编辑者角色。相反,如果您在“Test GCP”项目上向 alice@example.com 分配 Instance Admin 角色,则她只能管理该项目中的 Compute Engine 实例。

Cloud IAM 政策层次结构与 GCP 资源层次结构遵循相同的路径。如果更改资源层次结构,政策层次结构也会发生更改。例如,将项目移到组织中会将会更新该项目的 Cloud IAM 政策以沿用组织的 Cloud IAM 政策。同样,将项目从一个文件夹移动到另一个文件夹将更改继承的权限。将某个项目移动到新文件夹后,该项目从原始父项继承的权限将丢失。移动项目时,在目标文件夹设置的权限将由项目继承。

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Resource Manager 文档