使用资源层次结构实现访问权限控制

Google Cloud 资源分层整理,其中组织节点是层次结构中的根节点,项目是组织的子级,其他资源是项目的后代。您可以在资源层次结构的不同级层上设置 Identity and Access Management (IAM) 政策。资源会沿用父级资源的政策。资源的有效政策是为该资源设置的政策以及从其父级沿用而来的政策的集合。

本页通过一些示例介绍了 IAM 政策的沿用方式,并说明了您在 IAM 部署期间创建资源时必须考虑的最佳做法。

前提条件

背景

下图演示了 Google Cloud 资源层次结构的一个示例。

按从上到下的顺序,层次结构包括组织、文件夹、项目和服务专属资源。

通过 IAM,您可在资源层次结构的以下级层设置政策:

  • 组织级层。组织资源代表您的公司。在该级层授予的 IAM 角色由该组织下的所有资源沿用。如需了解详情,请参阅使用 IAM 对组织进行访问权限控制

  • 文件夹级层。文件夹可包含项目、其他文件夹,也可同时包含这两者。在最高文件夹级层授予的角色将由该父级文件夹下包含的项目或其他文件夹沿用。如需了解详情,请参阅使用 IAM 对文件夹进行访问权限控制

  • 项目级层。项目代表您公司内部的信任边界。同一项目中的服务具有默认信任级别。例如,App Engine 实例可以访问同一项目中的 Cloud Storage 存储分区。在项目级层授予的 IAM 角色由该项目内的资源沿用。如需了解详情,请参阅使用 IAM 对项目进行访问权限控制

  • 资源级层。除了现有的 Cloud Storage 和 BigQuery ACL 系统外,Genomics 数据集、Pub/Sub 主题和 Compute Engine 实例等其他资源也支持较低级层的角色,以便您可以向项目内的单个资源授予特定用户权限。

IAM 政策是分层的,并在结构中向下传递。资源的有效政策是为该资源设置的政策以及从其父级沿用而来的政策的集合。

以下示例说明了政策实际的沿用方式。

示例:Pub/Sub

在 Pub/Sub 中,主题和订阅是项目下的资源。假设 project_a 下面有一个主题 topic_a。如果您在 project_a 上设置一项政策,将 Editor 角色授予 bob@example.com,并在 topic_a 上设置一项政策,将 Publisher 角色授予 alice@example.com,则对于 topic_a 就是为 bob@example.com 有效地授予了 Editor 角色,并为 alice@example.com 有效地授予了 Publisher 角色。

下图演示了上面的示例。

Pub/Sub 示例。

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 上设置的政策。

下图演示了上面的示例。

Pub/Sub 示例。

示例: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 的所有成员都可以将文件上传到存储分区。
    • 群组成员上传的文件归其自身所有,但他们无法读取或删除其他用户上传的任何文件。

下图演示了上面的示例。

Cloud Storage 示例。

示例:Compute Engine

在大型公司中,网络和安全资源(如防火墙)的管理通常由开发团队以外的专门团队负责。开发团队可能希望能够灵活地启动实例并执行与其项目中的实例相关的其他操作。通过在组织级层为 bob@example.com 授予 Compute Network Admin 角色,并为 alice@example.com 授予项目 project_2 的 Compute Instance Admin 角色,让 Alice 能够对实例执行任何操作,同时阻止她对与其项目关联的网络资源进行任何更改。只有 Bob 可以更改组织中的网络资源以及该组织下的所有项目。

Cloud Storage 示例。

最佳做法

  • 将您的 Google Cloud 资源层次结构与您的组织结构相互镜像。Google Cloud 资源层次结构应能反映您公司的组织结构,无论其是初创公司、中小型公司还是大型公司。一家初创公司最初可能采用没有组织资源的扁平式资源层次结构。当项目的协作人员及项目数量不断增加时,才需要引入组织资源。对于拥有多个部门和团队(每个团队负责各自的一组应用和服务)的大型公司,建议使用组织资源。

  • 使用项目对共享相同信任边界的资源进行分组。例如,同一产品或微服务的资源可以属于同一个项目。

  • 在组织级层和项目级层(而非资源层级)设置政策。添加新资源后,您可能希望它们自动沿用其父级资源的政策。例如,在通过自动扩缩向项目中添加新的虚拟机后,这些虚拟机自动沿用项目上的政策。

    如需详细了解如何设置政策,请参阅授予、更改和撤消访问权限

  • 如果可能,向 Google 群组(而不是单个用户)授予角色。管理 Google 群组中的成员比更新 IAM 政策更容易。务必控制在 IAM 政策中使用的 Google 群组的所有权。

    如需详细了解如何管理 Google 群组,请参阅 Google 网上论坛帮助

  • 根据最低权限安全原则授予 IAM 角色,即只授予访问您资源所需的最低访问权限。

    如需查找适当的预定义角色,请参阅预定义角色参考文档。如果没有合适的预定义角色,您还可以创建自己的自定义角色

  • 在所需的最小范围内授予角色。例如,如果用户只需要向 Pub/Sub 主题发布消息的访问权限,则为该用户授予该主题的 Publisher 角色。

  • 切记,子资源会沿用其父资源的政策。举例来说,如果项目的政策授予用户管理 Compute Engine 虚拟机 (VM) 实例的权限,则该用户便可以管理该项目中的所有 Compute Engine 虚拟机,而无论您在每个虚拟机上设置的政策如何。

  • 如果您需要为用户或群组授予涵盖多个项目的角色,请在文件夹层级设置该角色,而不是在项目级层设置该角色。

  • 使用标签对资源进行注释、分组和过滤。

  • 审核您的政策以确保合规性。审核日志包含所有 setIamPolicy() 调用,因此您能够跟踪政策的创建或修改时间。

  • 审核政策中使用的 Google 群组的所有权和成员资格。

  • 如果要限制组织中的项目创建,请更改组织访问权限政策,将 Project Creator 角色授予您管理的群组。