Cloud Identity and Access Management

本页面概述了 Identity and Access Management (IAM) 以及如何使用此功能在 Cloud Storage 中控制存储分区和对象的访问权限。如需了解如何为 Cloud Storage 存储分区和项目设置及管理 Cloud IAM 权限,请参阅使用 Cloud IAM 权限。要了解如何以其他方式控制存储分区和对象的访问权限,请参阅访问权限控制概览

本页面重点介绍了与 Cloud Storage 相关的 Cloud IAM 功能。有关 Cloud IAM 及其一般功能的详细说明,请参阅 Google Cloud Identity and Access Management 开发者指南。尤其应参阅管理 Cloud IAM 政策一节。

概览

通过 Cloud Identity and Access Management (Cloud IAM),您可以控制谁有权访问您的 Google Cloud Platform 项目中的资源。资源包括 Cloud Storage 存储分区和存储在存储分区中的对象,以及其他 GCP 实体(比如 Compute Engine 实例)。

您应用于资源的一组访问规则称为 Cloud IAM 政策。应用到项目上的 Cloud IAM 政策定义了用户可以对项目中的所有对象或存储分区执行的操作。应用到单个存储分区上的 Cloud IAM 政策定义了用户可以对该存储分区及存储分区中的对象执行的操作。

例如,您可以为一个存储分区创建 Cloud IAM 政策,以便为一位用户提供该存储分区的管理控制权。同时,您可以将另一个用户添加到适用于整个项目的 Cloud IAM 政策中,使该用户能够查看项目任何存储分区中的对象。

成员指的是 Cloud IAM 适用的对象。成员可以是个人用户、群组、网域或全体公众。您将为成员分配角色,这些角色使成员能够在 Cloud Storage 以及整个 GCP 中执行操作。每个角色都是一个或多个权限的集合。权限是 Cloud IAM 的基本单位:每个权限允许您执行一种特定的操作。

例如,storage.objects.create 权限允许您创建对象。此权限包含在 roles/storage.objectCreator(此权限是唯一权限)和 roles/storage.objectAdmin(许多权限捆绑在一起)等角色中。如果将 roles/storage.objectCreator 角色提供给特定存储分区的成员,则他们只能在该存储分区中创建对象。如果您为另一个成员提供该存储分区的 roles/storage.objectAdmin 角色,他们可以执行其他任务(例如删除对象),但他们仍然只能在该存储分区中执行这些任务。如果您为这两个用户分配了这些角色(没有分配其他角色),则他们不会了解项目中的任何其他存储分区。如果您为第三个成员提供 roles/storage.objectAdmin 角色,但角色授权范围是您的整个项目(而不仅仅是一个存储分区),则他们可以访问项目内的任何存储分区中的任何对象。

通过将 Cloud IAM 与 Cloud Storage 搭配使用,您可以轻松限制成员的权限,而无需单独修改每个存储分区或对象权限。

权限

权限允许成员对 Cloud Storage 中的存储分区或对象执行特定操作。例如,storage.buckets.list 权限允许成员列出项目中的存储分区。您不能直接授予成员权限,但可以为他们分配角色(角色本身会具有一项或多项权限)。

如需查看适用于 Cloud Storage 的 Cloud IAM 权限的参考列表,请参阅 Cloud Storage Cloud IAM 权限

角色

角色包含一个或多个权限。例如,roles/storage.objectViewer 包含权限 storage.objects.getstorage.objects.list。您可以将角色分配给成员,从而允许他们对项目中的存储分区和对象执行操作。

如需查看适用于 Cloud Storage 的 Cloud IAM 角色的参考列表,请参阅 Cloud Storage Cloud IAM 角色

项目级层角色与存储分区级层角色

在存储分区级层授予角色时,不会影响您当前在项目级层授予的任何角色,反之亦然。因此,您可以使用这两个粒度级别来自定义权限。例如,假设您希望向用户授予任何存储分区中的对象的读取权限,但只允许该用户在特定的存储分区中创建对象。要实现此目的,请在项目级层为用户提供 roles/storage.objectViewer 角色(允许用户读取项目中的任意存储分区中存储的任意对象),然后在存储分区层级为用户提供特定存储分区的 roles/storage.objectCreator 角色(仅允许用户在该存储分区中创建对象)。

您可以同时在项目级层和存储分区级层使用某些角色。在项目级层使用时,这些角色包含的权限适用于项目中的所有存储分区和对象。在存储分区级层使用时,这些权限仅适用于特定存储分区以及其中的对象。此类角色的示例包括 roles/storage.adminroles/storage.objectViewerroles/storage.objectCreator

某些角色只能在一个级层应用。例如,您只能在项目级层应用 Viewer 角色,以及只能在存储分区级层应用 roles/storage.legacyObjectOwner 角色。

与 ACL 的关系

旧版存储分区 Cloud IAM 角色与存储分区 ACL 协同工作:当您添加或移除旧版存储分区角色时,与存储分区关联的 ACL 会反映您的更改。同样地,更改特定于存储分区的 ACL 时,也会更新该存储分区相应的旧版存储分区角色。

旧版存储分区角色 等效 ACL
roles/storage.legacyBucketReader 存储分区读取者
roles/storage.legacyBucketWriter 存储分区写入者
roles/storage.legacyBucketOwner 存储分区所有者

所有其他存储分区级层 Cloud IAM 角色和所有项目级层 Cloud IAM 角色独立于 ACL 运行。例如,如果您为用户提供存储对象查看者角色,则 ACL 保持不变。这意味着您可以使用存储分区级层的 Cloud IAM 角色为存储分区中的所有对象授予广泛访问权限,并使用精细对象 ACL 自定义对存储分区中特定对象的访问权限。

更改 ACL 的 Cloud IAM 权限

您可以使用 Cloud IAM 向成员授予更改对象上的 ACL 所需的权限。以下 storage.buckets 权限组合在一起,允许用户处理存储分区 ACL 和默认对象 ACL:.get.getIamPolicy.setIamPolicy.update

同样地,以下 storage.objects 权限组合到一起,允许用户处理对象 ACL:.get.getIamPolicy.setIamPolicy.update

自定义角色

虽然 Cloud IAM 包含许多涵盖了常见用例的预定义角色,您可能还是想要定义自己的角色(包含您指定的一组权限)。为此,Cloud IAM 提供了自定义角色

成员类型

成员分为许多不同的类型。例如,Google 帐号和 Google 群组代表两种常规类型,而 allAuthenticatedUsersallUsers 是两种特殊类型。如需查看 Cloud IAM 中的典型成员类型的列表,请参阅与身份相关的概念。除了该处列出的类型之外,Cloud IAM 还支持下列成员类型(可专门应用于 Cloud Storage 存储分区 Cloud IAM 政策):

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

其中,[PROJECT_ID] 是特定项目的 ID。

当您为上述其中一个成员类型授予角色时,具有指定项目的指定权限的所有成员都将获得您选择的角色。例如,假设您希望为拥有项目 my-example-projectViewer 角色的所有成员提供其中一个存储分区的 roles/storage.objectCreator 角色。要执行此操作,请为成员 projectViewer:my-example-project 提供该存储分区的 roles/storage.objectCreator 角色。

与 Cloud Storage 工具结合使用

虽然无法通过 XML API 设置 Cloud IAM 权限,但获得 Cloud IAM 权限的用户仍可以使用 XML API 以及其他工具来访问 Cloud Storage。

如需了解用户使用不同的 Cloud Storage 工具执行操作时需要哪些 Cloud IAM 权限,请参阅搭配 Cloud Console 使用 Cloud IAM搭配 gsutil 使用 Cloud IAM搭配 JSON 使用 Cloud IAM 以及搭配 XML 使用 Cloud IAM

最佳做法

与任何其他管理设置一样,您必须对 Cloud IAM 进行主动管理以使之生效。在允许其他用户访问某一存储分区或对象之前,请务必明确您想要与谁共享该存储分区或对象以及您希望他们分别扮演什么角色。一段时间后,如果项目管理、使用模式和组织所有权发生变化,您可能需要修改存储分区和对象的 Cloud IAM 设置(特别是当您在大型组织中或面对大规模用户的情况下管理 Cloud Storage 时)。在评估和规划访问权限控制设置时,请谨记以下最佳做法:

  • 授予访问权限时,请遵循最小权限原则。

    最小权限原则是关于授予特权或权限的一项安全准则。根据最小权限原则授予访问权限时,您将为用户授予完成分配到的任务所需的最小权限。例如,如果您想要与他人共享一个文件,应为其授予 storage.objectReader 角色,而不是 storage.admin 角色。

  • 避免向陌生人授予具有 setIamPolicy 权限的角色。

    授予 setIamPolicy 权限后,获得授权的用户可以更改权限和控制数据。只有在您希望将对象和存储分区的管理控制权委托给他人时,您才应使用具有 setIamPolicy 权限的角色。

  • 向匿名用户授予权限时请务必注意方式方法。

    只有允许互联网上的任何人读取和分析您的数据时,才应使用 allUsersallAuthenticatedUsers 成员类型。虽然在某些应用和情景中使用这些权限范围会非常有用,但我们建议您一般情况下最好不要向所有用户授予某些权限,比如 setIamPolicyupdatecreatedelete

  • 了解 Cloud Storage 中的 Viewer/Editor/Owner 项目角色

    Viewer/Editor/Owner 项目级层角色可在 Cloud Storage 中向用户有效授予其名称所隐含的访问权限;但是,具体的授权过程是通过存储分区级层和对象级层提供的其他访问权限来间接实现(在此过程中,使用了 Cloud Storage 独有的成员类型)。默认情况下会添加此访问权限,但您可以将其撤消。

    例如,Viewer 角色本身仅为成员提供 storage.buckets.list 权限,但默认情况下,新存储分区会向具有项目的 Viewer 角色的所有成员授予 roles/storage.legacyBucketReader 角色。此存储分区角色允许 Viewer 查看存储分区。此外,存储分区具有一个默认对象 ACL (projectPrivate),这意味着,添加到存储分区的对象将默认获得 projectPrivate ACL。Viewer 可以借助此 ACL 查看对象。

    同样地,EditorOwner 项目角色本身包含受限的 Cloud Storage 访问权限,但具有这些角色的成员会通过 projectPrivate ACL 获得新存储分区的 roles/storage.legacyBucketOwner 角色和对象的所有权。

    请注意,由于某些存储分区和对象访问权限不是 Viewer/Editor/Owner 项目角色所固有的,因此,您可以撤消成员在其他情况下可能具备的访问权限。

  • 您需要避免设置导致存储分区和对象无法被用户访问的权限。

    当没有用户具备相应的读取权限时,存储分区或对象将变为无法访问。当存储分区上的所有 Cloud IAM 权限都被移除时,存储分区可能会出现这种问题。当对象的所有者离开项目,并且不存在可以向用户授予对象访问权限的存储分区级层或项目级层 Cloud IAM 政策时,对象可能会出现这种问题。在这两种情况下,为了重新获得访问权限,您可以在项目级层为自己或其他成员分配适当的角色(例如 roles/storage.admin)。请注意,这样操作之后,获得授权的用户将可以访问项目中的所有存储分区和对象。因此,在重置受影响的存储分区或对象的访问权限后,建议您撤消该角色

  • 请确保将您存储分区的管理控制权委托给他人。

    默认情况下,具有项目级层 Owner 角色的成员是在新创建的存储分区上具有 roles/legacyBucketOwner 角色的唯一实体。在任何时候,都至少应有两个成员具有 Owner 角色,这样一来,即使某位团队成员离开了该群组,您的存储分区仍可由其他成员进行管理。

后续步骤

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

发送以下问题的反馈:

此网页
Cloud Storage
需要帮助?请访问我们的支持页面