保护 Google 存储桶的惯用方法答案

【问题标题】：Idiomatic Way to Secure a Google Storage Bucket保护 Google 存储桶的惯用方法
【发布时间】：2017-09-01 01:41:59
【问题描述】：

我的目标是以仅授予必要权限的方式将 Google 存储桶的读写权限授予计算实例模板，但鉴于 many access control options，我对 GCP 中认为惯用的内容感到困惑用于 Google 存储桶。

目前，我正在创建一个托管实例组和一个计算实例模板并分配以下范围：

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/compute.readonly
https://www.googleapis.com/auth/devstorage.read_write

到计算实例上的默认服务帐户。这似乎工作正常，但鉴于上面的链接，我想知道我是否应该将存储桶上的访问控制列表 (ACL) 也显式设置为private？但是同一页还说“仅当您需要对单个对象进行细粒度控制时才使用 ACL”，而在这种情况下，我需要一个粗粒度策略。这让我想知道我是否应该使用 IAM 权限 (?) 但我应该在哪里分配呢？

配置这个的惯用方式是什么？

【问题讨论】：

IAM 通常是您的首选。该文档提到“在大多数情况下，您应该使用 IAM 权限而不是 ACL”。
我实际上是在使用 Teraform 根据terraform.io/docs/providers/google/r/storage_bucket.html 调用 Google API。 Terraform 文档暗示 ACL 是可行的方法，但是否可以将 IAM 策略分配给 Google 存储桶？在这种情况下，这看起来很直观吗？

标签： google-cloud-storage google-compute-engine

【解决方案1】：

事实证明，这里的关键文档是用于 Google Cloud Storage 的 Identity and Access Management overview。从那里，我学到了以下内容：

GCS 存储桶ACL 指定零个或多个“条目”，其中每个条目授予某个范围的权限，例如Google Cloud 用户或项目。 ACL 现在被认为是为存储桶分配权限的传统方法，因为它们只允许粗粒度权限 READER、WRITER 和 OWNER。
为所有 GCP 资源分配权限的首选方法是使用 IAM 政策 (overview)。 IAM 策略附加到整个组织、项目文件夹、特定项目或特定资源，并且还指定一个或多个“条目”，其中每个条目授予一个或多个角色成员。
使用 IAM 策略，您不能直接向成员授予权限。相反，您声明一个角色拥有哪些权限，并授予成员一个角色。

最终，希望您在层次结构的适当级别分配 IAM 策略，知道层次结构的较低级别（如单个资源）继承较高级别（如项目级别的 IAM 策略）声明的权限)。

基于此，我得出结论：

您应该尝试通过在层次结构的正确级别分配 IAM 策略来为 GCS 存储桶分配权限。
但是，要限制每个对象的权限，您必须使用 ACL。
新创建 Bucket 时，除非您另外指定，否则它定义为默认的 Canned ACL 或 projectPrivate。
截至本答案，Terraform 尚未对 IAM 策略提供成熟的支持，google_storage_bucket_acl 资源代表了与传统方法保护存储桶的接口。

警告：我只是在这里总结文档，到目前为止，我对 Google Cloud 的实践经验非常有限！欢迎对以上内容进行更正。

【讨论】：