Google Cloud 资源分层整理，其中组织节点是层次结构中的根节点，项目是组织的子级，其他资源是项目的后代。您可以在资源层次结构的不同层级上设置允许政策。资源会继承父级资源的允许政策。资源的有效允许政策是为该资源设置的允许政策以及从其父级继承的允许政策的并集。
本页面通过一些示例介绍了允许政策的继承机制，并说明了您在 Identity and Access Management (IAM) 部署期间创建资源时必须考虑的最佳做法。
前提条件
- 了解 IAM 的基本概念，尤其是 Google Cloud 资源层次结构。
背景
下图演示了 Google Cloud 资源层次结构的一个示例。
通过 IAM，您可在资源层次结构的以下级层设置允许政策：
组织级层。组织资源代表您的公司。在该级层授予的 IAM 角色由该组织下的所有资源沿用。如需了解详情，请参阅使用 IAM 对组织进行访问权限控制。
文件夹级层。文件夹可包含项目、其他文件夹，也可同时包含这两者。在最高文件夹级层授予的角色将由该父级文件夹下包含的项目或其他文件夹沿用。如需了解详情，请参阅使用 IAM 对文件夹进行访问权限控制。
项目级层。项目代表您公司内部的信任边界。同一项目中的服务具有默认信任级别。在项目级层授予的 IAM 角色由该项目内的资源沿用。如需了解详情，请参阅使用 IAM 对项目进行访问权限控制。
资源级层。除了现有的 Cloud Storage 和 BigQuery ACL 系统外，Pub/Sub 主题和 Compute Engine 实例等其他资源也支持较低级层的角色，以便您可以向项目内的单个资源授予特定用户权限。
允许政策是分层的，并在结构中向下传递。资源的有效允许政策是为该资源设置的允许政策以及从其父级继承的允许政策的并集。
以下示例说明了允许政策实际的继承机制。
示例：Pub/Sub
在 Pub/Sub 中，主题和订阅是项目下的资源。假设 project_1 下面有一个主题 topic_a。如果您在 project_1 上设置一项允许政策，将 Editor 角色授予 bob@example.com，并在 topic_a 上设置一项允许政策，将 Publisher 角色授予 alice@example.com，则对于 topic_a 就是为 bob@example.com 有效地授予了 Editor 角色，并为 alice@example.com 有效地授予了 Publisher 角色。
下图演示了上面的示例。
Owner、Editor 和 Viewer 角色是嵌套的；也就是说，Owner 角色包含 Editor 角色的权限，而 Editor 角色又包含 Viewer 角色的权限。如果您向同一人同时授予范围更广和受限的角色（例如 Editor 和 Viewer），则系统将仅向其授予范围更广的角色。例如，如果您在项目级层向 bob@example.com 授予了 Editor 角色，并向 bob@example.com 授予了 topic_a 的 Viewer 角色，则 Bob 将获得 topic_a 的 Editor 角色。这是因为您已为 Bob 授予了 topic_a 的 Editor 角色，而此角色沿用的是 project_a 上设置的允许政策。
下图演示了上面的示例。
示例：Cloud Storage
在 Cloud Storage 中，存储分区和对象是资源，而对象位于存储分区中。例如，如果将 IAM 与 Cloud Storage 结合使用，则可读取访问已上传的文件。
请想象这样一个场景：许多用户将文件上传到存储分区，但他们应该无法读取或删除其他用户上传的任何文件。您的数据处理专家应该能够读取和删除所上传的文件，但应该没法删除存储分区，因为其他人正在使用存储分区位置来上传文件。在此场景中，您可以按如下方式在项目上设置允许政策：
- 向您的数据处理专家 Alice (alice@example.com) 授予 Storage Object Admin 角色
- Alice 在项目级层拥有对象管理权限，并且可以读取、添加和删除项目中任何存储分区内的任何对象。
- 向用户群组 (data_uploaders@example.com) 授予 Storage Object Creator 角色。
- 此允许政策意味着 data_uploaders@example.com 群组的所有成员都可以将文件上传到存储桶。
- 群组成员拥有他们上传的文件，但他们无法读取或删除其他用户上传的任何文件。
下图演示了上面的示例。
示例：Compute Engine
在大型公司中，网络和安全资源（如防火墙）的管理通常由专门的团队负责管理，这与开发团队不同。开发团队可能希望能够灵活地启动实例并执行与其项目中的实例相关的其他操作。通过在组织级层为 bob@example.com 授予 Compute Network Admin 角色，并为 alice@example.com 授予项目 project_2 的 Compute Instance Admin 角色，让 Alice 能够对实例执行任何操作，同时阻止她对与其项目关联的网络资源进行任何更改。只有 Bob 可以更改组织中的网络资源以及该组织下的所有项目。
用于查看继承的政策的权限
如需查看从父级资源继承的 IAM 政策，您需要拥有查看父级资源的 IAM 政策的权限。例如，如需查看项目所有继承的 IAM 政策，您需要拥有查看项目的父级组织的 IAM 政策的权限以及查看任何父级文件夹的 IAM 政策的权限。
如需获得查看从父级资源继承的 IAM 政策所需的权限，请让您的管理员为您授予以下 IAM 角色：
- 查看从组织继承的 IAM 政策：组织的 Organization Administrator (
roles/resourcemanager.organizationAdmin) - 查看从文件夹继承的 IAM 政策：文件夹的 Folder Admin (
roles/resourcemanager.folderAdmin) - 查看从项目继承的 IAM 政策：项目的 Project IAM Admin (
roles/resourcemanager.projectIamAdmin)
如需详细了解如何授予角色，请参阅管理对项目、文件夹和组织的访问权限。
这些预定义角色可提供查看从父级资源继承的 IAM 政策所需的权限。如需查看所需的确切权限，请展开所需权限部分：
所需权限
如需查看从父级资源继承的 IAM 政策，您需要拥有以下权限：
-
查看从组织继承的 IAM 政策：针对组织的
resourcemanager.organizations.getIamPolicy权限 -
查看从文件夹继承的 IAM 政策：针对文件夹的
resourcemanager.folders.getIamPolicy权限 -
查看从项目继承的 IAM 政策：针对项目的
resourcemanager.projects.getIamPolicy权限
最佳做法
将您的 Google Cloud 资源层次结构与您的组织结构相互镜像。Google Cloud 资源层次结构应能反映您公司的组织结构，无论其是初创公司、中小型公司还是大型公司。一家初创公司最初可能采用没有组织资源的扁平式资源层次结构。当项目的协作人员及项目数量不断增加时，才需要引入组织资源。对于拥有多个部门和团队（每个团队负责各自的一组应用和服务）的大型公司，建议使用组织资源。
使用项目对共享相同信任边界的资源进行分组。例如，同一产品或微服务的资源可以属于同一个项目。
尽可能向群组（而不是单个用户）授予角色。管理群组中的成员比更新允许政策更容易。务必控制在允许政策中使用的群组的所有权。
如需详细了解如何管理 Google 群组，请参阅 Google 群组帮助。
根据最低权限安全原则授予 IAM 角色，即只授予访问您资源所需的最低访问权限。
在所需的最小范围内授予角色。例如，如果用户只需获权向 Pub/Sub 主题发布消息，则可为该用户授予该主题的 Publisher 角色。
切记，子资源的允许政策继承自其父资源的允许政策。举例来说，如果项目的允许政策授予用户管理 Compute Engine 虚拟机 (VM) 实例的权限，则用户可以管理该项目中的任何 Compute Engine 虚拟机，无论您在各虚拟机上设置怎样的允许政策都是如此。
在每个项目中，请确保至少两个主账号具有 Owner 角色 (
roles/owner)。或者，将 Owner 角色授予至少包含两个主账号的群组。这种做法有助于确保如果其中一个主账号离开您的公司，您仍然可以管理项目。
如果您需要为用户或群组授予涵盖多个项目的角色，请在文件夹层级设置该角色，而不是在项目级层设置该角色。
使用标签对资源进行注释、分组和过滤。
审核您的允许政策以确保合规性。审核日志包含所有
setIamPolicy()调用，因此您能够跟踪允许政策的创建或修改时间。审核允许政策中使用的群组的所有权和成员资格。
如果要限制组织中的项目创建，请更改组织访问权限政策，将 Project Creator 角色授予您管理的群组。