Identity and Access Management

转到示例

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

本页面重点介绍了与 Cloud Storage 相关的 IAM 功能。如需了解 IAM 及其功能的详细说明,请参阅 Identity and Access Management,尤其应参阅管理 IAM 政策部分。

概览

借助 IAM,您可以控制谁有权访问您的 Google Cloud 项目中的资源。资源包括 Cloud Storage 存储分区和存储在存储分区的对象,以及 Compute Engine 实例等其他 Google Cloud 实体。

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

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

主帐号指的是 IAM 适用的“谁”。主帐号可以是个人用户、群组、网域,甚至是全体公众。主帐号被授予角色,使他们能够在 Cloud Storage 以及整个 Google Cloud 中执行操作。每个角色都是一项或多项权限的集合。权限是 IAM 的基本单位:每项权限允许您执行一种特定的操作。

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

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

权限

权限允许主帐号对 Cloud Storage 中的存储桶或对象执行特定操作。例如,storage.buckets.list 权限允许主帐号列出项目中的存储桶。您不能直接授予主帐号权限,而应授予捆绑了一项或多项权限的角色

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

角色

角色包含一个或多个权限。例如,Storage Object Viewer 角色包含 storage.objects.getstorage.objects.list 权限。您可以将角色授予主帐号,从而允许他们对项目中的存储桶和对象执行操作。

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

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

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

您可以同时在项目级层和存储分区级层使用某些角色。在项目级层使用时,这些角色包含的权限适用于项目中的所有存储分区和对象。在存储分区级层使用时,这些权限仅适用于特定存储分区以及其中的对象。此类角色的示例包括 Storage AdminStorage Object ViewerStorage Object Creator

某些角色只能在一个级层应用。例如,您只能在存储桶级层应用 Storage Legacy Object Owner 角色。

与 ACL 的关系

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

旧版存储分区角色 等效 ACL
Storage Legacy Bucket Reader Bucket Reader
Storage Legacy Bucket Writer Bucket Writer
Storage Legacy Bucket Owner Bucket Owner

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

用于更改 ACL 的 IAM 权限

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

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

自定义角色

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

主帐号类型

主帐号分为许多不同的类型。例如,Google 帐号和 Google 群组代表两种常规类型,而 allAuthenticatedUsersallUsers 是两种特殊类型。如需查看 IAM 中的典型主帐号类型的列表,请参阅与身份相关的概念

便利值

Cloud Storage 支持便利值,这是一个可以专门应用于 IAM 存储桶政策的特殊主帐号集。您通常应该在生产环境中避免使用便利值,因为它们需要授予基本角色,不建议在生产环境中执行这样的操作。

便利值是由两部分组成的标识符,由基本角色和项目 ID 组成:

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

便利值充当授予基本角色与 IAM 角色的主帐号之间的桥梁:授予便利值的 IAM 角色,实际上也授予给指定项目 ID 的指定基本角色的所有主帐号。

例如,假设 jane@example.com 和 john@example.com 拥有名为 my-example-project 的项目的 Viewer 基本角色,并且您在该项目中拥有名为 my-bucket 的存储分区。如果将 my-bucketStorage Object Creator 角色授予便利值 projectViewer:my-example-project,则 jane@example.com 和 john@example.com 均会获得 my-bucketStorage Object Creator 权限。

您可以授予和撤消对存储桶便利值的访问权限,但请注意,Cloud Storage 在某些情况下会自动应用这些值。如需了解详情,请参阅 Cloud Storage 中基本角色的可修改行为

条件

IAM Conditions 允许您设置条件,控制如何向主帐号授予权限。Cloud Storage 支持以下类型的条件特性:

  • resource.name:根据存储分区或对象名称授予对存储分区和对象的访问权限。您还可以使用 resource.type 授予对存储分区或对象的访问权限,但这样做对于使用 resource.name 而言几乎是多余的。 以下条件示例将 IAM 设置应用于具有相同前缀的所有对象:
    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')
  • 日期/时间:设置权限的失效日期。
    request.time < timestamp('2019-01-01T00:00:00Z')

这些条件表达式是使用通用表达式语言 (CEL) 子集的逻辑语句。您可以在存储分区 IAM 政策的角色绑定中指定条件。

请注意以下限制:

  • 您必须先对存储分区启用统一存储分区级层访问权限,然后才能在存储分区级层添加条件。尽管条件是在项目级允许的,但您应该迁移项目中的所有存储分区,以实现统一存储分区级访问权限,从而防止 Cloud Storage ACL 替换项目级 IAM 条件。您可以应用统一存储分区级访问权限限制条件,为您项目中的所有新存储分区启用统一存储分区级层访问权限。
  • gsutil iam ch 命令不适用于包含条件的政策。如需修改包含条件的政策,请使用 gsutil iam get 检索相关存储分区的政策,在本地进行编辑,然后使用 gsutil iam set 将其重新应用于该存储分区。
  • 4.38 或更高版本的 gsutil 才能使用条件。
  • 当使用 JSON API 针对具有条件的存储分区调用 getIamPolicysetIamPolicy 时,您必须将 IAM 政策版本设置为 3。
  • 由于 storage.objects.list 权限是在存储分区级授予的,因此您无法使用 resource.name 条件特性来限制对存储分区中部分对象的对象列出访问权限。没有存储分区级 storage.objects.list 权限的用户可能会遇到控制台和 gsutil 功能降级的问题。
  • 已过期的条件依然保留在 IAM 政策中,直到您将其移除。

与 Cloud Storage 工具结合使用

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

如需查看有关哪些 IAM 权限允许用户使用不同的 Cloud Storage 工具执行操作的参考文档,请参阅 IAM 和 Cloud Console 搭配使用IAM 和 gsutil 搭配使用IAM 和 JSON 搭配使用IAM 和 XML 搭配使用

最佳做法

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

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

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

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

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

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

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

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

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

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

    如果具有管理员权限的某个人离开了群组,则您应确保您的存储桶和资源仍可由其他团队成员管理。实现此目的的两种常用方法如下:

    • 将项目的 Storage Admin 角色授予群组(而非个人)。

    • 将项目的 Storage Admin 角色至少授予两个人。

后续步骤