访问控制列表 (ACL)

用量

本页面简要介绍访问控制列表 (ACL)。若要了解如何以其他方式控制对存储桶和对象的访问，请阅读访问权限控制概览。

您应该使用访问控制列表吗？

在大多数情况下，您应避免使用 ACL，而应为存储桶启用统一存储桶级访问权限，以防止使用 ACL：

  • 您不能仅使用 ACL 来控制对 Google Cloud 资源的访问权限，因为无法在整个项目或 Cloud Storage 以外的资源上设置 ACL。
  • 启用统一存储桶级访问权限可创建更简单的访问权限控制界面，并让您能够使用其他 Google Cloud 功能。如需了解详情，请参阅您应该使用统一存储桶级访问权限吗。
  • 网域限定共享组织政策和自定义组织政策不会阻止 ACL 授予的访问权限，可能会导致意外访问。
  • 如果在项目中使用 ACL，并且在项目级层或更高级层设置了 IAM 条件，则可能会发生意外行为和访问。

在以下情况下建议使用 ACL：

  • 您需要自定义对存储桶中个别对象的访问，例如，如果您希望对象上传者可以完全控制该对象，但不能完全控制存储桶中的其他对象。
  • 您仅使用 XML API，或者需要与 Amazon S3 进行互操作。

Identity and Access Management (IAM) 和 ACL 可配合使用来授予对存储桶和对象的访问权限，也就是说，用户只需要来自任一系统的相关权限即可访问存储桶或对象。通常，由 IAM 政策授予的权限不会出现在 ACL 中，由 ACL 授予的权限也不会出现在 IAM 政策中。如需了解详情，请参阅 IAM 与 ACL 的关系。

什么是访问控制列表？

访问控制列表 (ACL) 是一种机制，可用于定义谁有权访问您的存储桶和对象，以及他们具有何种级别的访问权限。在 Cloud Storage 中，ACL 适用于个别存储桶和对象。每个 ACL 包含一个或多个条目。每个条目指定了特定用户（或组）可以执行的特定操作，其中包含两部分信息：

  • 权限，此部分信息定义可执行哪些操作（例如读取或写入）。

  • 范围（有时称为授予对象），此部分信息定义谁可以执行指定操作（例如，某一特定用户或一组用户）。

例如，假设您希望任何人都能够访问您存储桶中的对象，但您还希望协作者能够在此存储桶中添加或移除对象。在这种情况下，您的 ACL 应包含两个条目：

  • 一个条目为 allUsers 组授予 READER 权限。

  • 另一个条目在协作者范围内授予 WRITER 权限（可通过多种方式指定此用户，例如，通过其电子邮件）。

对于一个存储桶或对象，您最多可以创建 100 个 ACL 条目。如果条目适用的范围是一个组或网域，则无论组或网域中有多少用户，系统均计为一个 ACL 条目。

如果用户请求访问某一存储桶或对象，Cloud Storage 系统会读取该存储桶或对象 ACL，并确定是允许还是拒绝访问请求。如果 ACL 为该用户授予了请求操作所需的权限，系统会允许该请求。如果 ACL 未向该用户授予请求操作所需的权限，系统则会拒绝该请求并返回 403 Forbidden 错误。

请注意，虽然您可以使用 ACL 来管理大部分涉及存储桶和对象的操作，但能否创建create存储桶取决于您是否具有适当的项目权限。

权限

权限描述针对给定对象或存储桶可以执行哪些操作。

通过 Cloud Storage，您可以分配存储桶和对象的以下同心权限，如下表所示：

存储桶 对象
READER 允许用户列出存储桶的内容。还允许用户读取存储桶元数据（不包括 ACL）。 允许用户下载对象的数据。
WRITER 为用户提供由 READER 权限授予的所有访问权限。此外，还允许用户创建、替换和删除存储桶中的对象，包括使用分段上传创建对象。 不适用。您不能将此权限应用于对象。
OWNER 为用户提供由 WRITER 权限授予的所有访问权限。还允许用户读取和写入存储桶元数据（包括 ACL），并在存储桶上使用标记。 为用户提供由 READER 权限授予的所有访问权限。还允许用户读取和写入对象元数据（包括 ACL）。
默认 创建存储桶时，系统会对存储桶应用预定义的项目专用 ACL。存储桶的所有权始终属于 project-owners 组。 上传对象时，系统会对对象应用预定义的项目专用 ACL。对象的所有权始终属于上传了相应对象的原始请求者。

在本页面中，我们通常将权限称为 READER、WRITER 和 OWNER，在 JSON API 和 Google Cloud 控制台 中这些权限也是这样指定的。如果您使用的是 XML API，则等效权限分别为 READ、WRITE 和 FULL_CONTROL。

范围

范围指定谁具有指定权限。

ACL 由一个或多个条目组成，其中的每个条目会向某一范围授予权限。您可以使用以下任何实体指定 ACL 范围：

范围（“受益者”） 实体类型 示例
适用于所有实体的特殊标识符 用户 allUsers
适用于所有有效账号的特殊标识符 用户 allAuthenticatedUsers
用户账号电子邮件地址 用户 collaborator@gmail.com
Google 群组电子邮件设置 群组 work-group@googlegroups.com
为项目方便而使用的值 项目 owners-123456789012
Google Workspace 网域 网域 USERNAME@YOUR_DOMAIN.com
Cloud Identity 网域 网域 USERNAME@YOUR_DOMAIN.com
员工身份池中的单个身份 主账号 //iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
群组中的所有员工身份 PrincipalSet //iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

  • 适用于所有实体的特殊标识符：

    特殊范围标识符 allUsers 表示互联网上的任何实体。请注意，虽然此标识符是 User 实体类型，但是在使用 Google Cloud 控制台时，它会被标记为 Public 实体类型。

  • 适用于所有有效账号的特殊标识符：

    特殊范围标识符 allAuthenticatedUsers 表示大多数经过身份验证的账号，包括服务账号。如需了解详情，请参阅 IAM 概览。请注意，虽然此标识符是 User 实体类型，但是在使用 Google Cloud 控制台时，它会被标记为 Public 实体类型。

  • 用户账号电子邮件地址：

    所有拥有用户账号的用户都必须有一个与该账号关联的唯一电子邮件地址。您可以使用与用户账号关联的任何电子邮件地址来指定范围。

    Cloud Storage 会识别 ACL 中提供的电子邮件地址，除非相应条目被移除或替换。如果用户更改了电子邮件地址，您应对 ACL 条目进行更新以反映这些更改。

  • Google 群组电子邮件地址：

    每个 Google 群组都有一个关联的唯一电子邮件地址。例如，Cloud Storage Announce 群组具有以下电子邮件地址：gs-announce@googlegroups.com。您可以通过点击任意 Google 群组主页上的关于来找到与 Google 群组关联的电子邮件地址。

    与用户账号电子邮件地址一样，Cloud Storage 会识别 ACL 中提供的群组电子邮件地址，除非相应条目被移除。您不必担心 Google 群组电子邮件地址的更新，因为 Google 群组电子邮件地址是永久性的，不太可能更改。

  • 为项目方便而使用的值：

    便利值使您可以向项目的查看者、编辑者和所有者授予批量访问权限。便利值结合了项目角色和关联的项目编号。例如，在项目 867489160491 中，编辑者可标识为 editors-867489160491。您可以在 Google Cloud 控制台 主页上找到您的项目编号。

    您通常应该在生产环境中避免使用便利值，因为它们需要授予基本角色，不建议在生产环境中这样做。

  • Google Workspace 或 Cloud Identity：

    Google Workspace 和 Cloud Identity 客户可以将其电子邮件账号与互联网域名相关联。执行此操作时，每个电子邮件账号均应采用 USERNAME@YOUR_DOMAIN.com 形式。您可以使用与 Google Workspace 或 Cloud Identity 关联的任何互联网域名来指定范围。

  • 员工身份：

    借助员工身份联合，您可以使用外部身份提供方 (IdP) 通过 IAM 对一组用户进行身份验证和授权，以便用户能够访问 Google Cloud 服务。

同心权限和范围

如果在 Cloud Storage 中指定了 ACL，您无需列出多个范围也能授予多项权限。Cloud Storage 使用同心权限，因此，授予 WRITER 权限时，READER 权限也会一起提供；授予 OWNER 权限时，READER 和 WRITER 权限也会一起提供。

指定 ACL 时，大多数工具都允许您为同一条目指定多个范围。其中最为宽松的权限就是授予给该范围的访问权限。例如，如果您为某个用户提供了两个条目（分别对应存储桶的 READER 权限和 WRITER 权限），该用户将拥有存储桶的 WRITER 权限。

在 XML API 中，无法为同一范围提供两个 ACL 条目。例如，同时向某一用户授予存储桶的 READ 权限和 WRITE 权限将会引发错误。正确的做法是为该用户授予 WRITE 权限（READ 权限会随之一起提供）。

预定义 ACL

预定义 ACL（有时也称为预设 ACL）是一组特定 ACL 条目的别名，可用于对一个存储桶或对象一次性快速应用多个 ACL 条目。

下表列出了预定义 ACL，同时还提供了适用于每个预定义 ACL 的 ACL 条目。使用下表时，请注意以下事项：

  • 项目所有者群组拥有项目中存储桶的所有权，而创建某个对象的用户拥有该对象的所有权。如果某个对象是由匿名用户创建的，则项目所有者群组拥有该对象的所有权。

  • 此表采用的是 JSON API 中对权限的描述方式，即 OWNER、WRITER 和 READER。等效的 XML API 范围为 FULL_CONTROL、WRITE 和 READ。

    JSON API/gcloud storage XML API 说明
    private private 为存储桶或对象所有者授予相应存储桶或对象的 OWNER 权限。
    bucketOwnerRead bucket-owner-read 为对象所有者授予 OWNER 权限，为存储桶所有者授予 READER 权限。 这仅适用于对象。
    bucketOwnerFullControl bucket-owner-full-control 为对象和存储桶所有者授予 OWNER 权限。 这仅适用于对象。
    projectPrivate project-private 根据角色为项目团队授予权限。所有团队成员都具有 READER 权限。项目所有者和项目编辑者具有 OWNER 权限。这不但是新创建存储桶的默认 ACL，也是新创建对象的默认 ACL（除非该存储桶的默认对象 ACL 发生了更改）。
    authenticatedRead authenticated-read 为存储桶或对象所有者授予 OWNER 权限，为所有已通过身份验证的用户账号持有人授予 READER 权限。
    publicRead public-read 为存储桶或对象所有者授予 OWNER 权限，为所有用户（包括已通过身份验证的用户和匿名用户）授予 READER 权限。对某个对象应用此 ACL 时，互联网上的任何人都可以在不进行身份验证的情况下读取该对象。对某个存储桶应用此选项时，互联网上的任何人都可以在不进行身份验证的情况下列出对象。

    * 请参阅表格末尾有关缓存的注释。
    publicReadWrite public-read-write 为存储桶所有者授予 OWNER 权限，并为所有用户（包括已通过身份验证的用户和匿名用户）授予 READER 和 WRITER 权限。此 ACL 仅适用于存储桶。对某一存储桶应用此 ACL 时，互联网上的任何人都可以在不进行身份验证的情况下列出、创建、替换和删除对象。

    * 请参阅表格末尾有关缓存的注释。

* 默认情况下，可公开读取的对象使用 Cache-Control 标头提供，带有此标头的对象可在系统中缓存 3600 秒。如果需要确保立即显示更新，应将对象的 Cache-Control 元数据设置为 Cache-Control:private, max-age=0, no-transform。

默认 ACL

创建存储桶或上传对象时，如果您没有为这些存储桶或对象明确分配一个 ACL，系统会为其指定默认 ACL。您可以更改系统为对象指定的默认 ACL；具体方法请参阅更改默认对象 ACL。请注意，当您更改默认 ACL 时，存储桶中的现有对象或项目中的现有存储桶的 ACL 保持不变。

默认存储桶 ACL

所有存储桶的所有权均属于项目所有者群组。此外，项目所有者被授予其项目中使用预定义 ACL 的任何存储桶的 OWNER 权限。

如果您在创建某个存储桶时使用的是默认存储桶 ACL，也就是说，您在创建该存储桶时没有指定预定义 ACL，系统会对您的存储桶应用预定义 projectPrivate ACL。

默认对象 ACL

默认情况下，任何对某一存储桶具有 OWNER 权限或 WRITER 权限的人都可以将对象上传至该存储桶。上传对象时，您可以提供预定义 ACL，也可以不指定任何 ACL。如果您没有指定 ACL，Cloud Storage 则会对该对象应用相应存储桶的默认对象 ACL。每个存储桶都有一个默认对象 ACL，如果您没有预定义的 ACL 或没有在请求中指定 ACL（仅限于 JSON API），系统则会对上传至该存储桶的所有对象应用此 ACL。每个存储桶的初始默认对象 ACL 值为 projectPrivate。

系统会根据对象的上传方式应用相应的对象 ACL：

  • 基于身份验证上传

    如果您是通过身份验证方式请求上传某一对象，且在上传时没有指定任何对象 ACL，那么系统会将您列为该对象的所有者，并对该对象默认应用预定义的 projectPrivate ACL。也就是说：

    • 您（上传该对象的人）将被列为对象所有者。 对象所有权不能通过修改 ACL 来更改，只能通过替换对象更改对象所有权。

    • 您（对象所有者）将被授予对象 OWNER 权限。如果您尝试向所有者授予低于 OWNER 的权限，Cloud Storage 会自动将此权限升级为 OWNER。

    • 项目所有者和项目编辑者群组拥有对象 OWNER 权限。

    • 项目团队成员群组拥有对象 READER 权限。

  • 匿名上传

    当未经过身份验证（匿名）的用户上传对象时（如果存储桶为 allUsers 群组授予 WRITER 或 OWNER 权限，就可能发生这种情况），系统则会对相应对象应用默认的存储桶 ACL（如上所述）。

    匿名用户无法在对象上传期间指定预定义的 ACL。

ACL 行为

Cloud Storage 会强制执行一些 ACL 修改规则来阻止您设置会导致数据无法访问的 ACL，从而帮助您遵守最佳做法：

  • 您应用的 ACL 不能指定不同的存储桶或项目所有者。

    存储桶和对象所有者不能通过修改 ACL 来更改。如果您对某个存储桶或对象应用新的 ACL，请确保该存储桶或对象所有者在新的 ACL 中保持不变。

  • 存储桶或对象所有者始终拥有相应存储桶或对象的 OWNER 权限。

    存储桶的所有者是指项目所有者群组，对象的所有者是指上传了该对象的用户或项目所有者群组（如果对象是由匿名用户上传的）。

    当您对某个存储桶或对象应用新的 ACL 时，Cloud Storage 会分别为该存储桶或项目所有者添加 OWNER 权限（如果您没有授予此权限）。Cloud Storage 不会向项目所有者群组授予对象的 OWNER 权限（除非该对象是由匿名用户创建的），因此您必须明确包含此权限。

您应用的 ACL 不能更改存储桶或对象的所有权（不要与 OWNER 权限混淆）。在 Cloud Storage 中创建存储桶和对象后，该存储桶和对象的所有权将无法更改。但是，您可以通过替换对象有效地更改对象（而非存储桶）的所有权。替换过程基本上是先执行删除操作，然后立即执行上传操作。在上传操作期间，执行上传的人将成为对象的所有者。请记住，要替换某个对象，执行替换操作（并将因此而获得对象所有权）的人必须对对象上传的存储桶具有 WRITER 或 OWNER 权限。

后续步骤