Idiomatic Way to Secure a Google Storage Bucket

4
votes

My objective is to grant read-write permissions on a Google Storage Bucket to a Compute Instance Template in a way that grants only the permissions that are necessary, but I'm confused about what's considered idiomatic in GCP given the many access control options for Google Storage Buckets.

Currently, I am creating a Managed Instance Group and a Compute Instance Template and assigning the following scopes:

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

to the default Service Account on the Compute Instance. This seems to work fine, but given the link above, I'm wondering if I should explicitly set the Access Control List (ACL) on the Storage Bucket to private as well? But that same page also says "Use ACLs only when you need fine-grained control over individual objects," whereas in this case I need a coarse-grained policy. That makes me wonder if I should use an IAM Permission (?) but where would I assign that?

What's the idiomatic way to configure this?

1
google-cloud-storagegoogle-compute-engine
IAM is usually the first choice if that works for you. The doc mentioned "In most cases, you should use IAM permissions instead of ACLs". – Dagang
I'm actually using Teraform to call Google APIs per terraform.io/docs/providers/google/r/storage_bucket.html. Terraform docs imply an ACL is the way to go, but is it even possible to assign an IAM Policy to a Google Storage Bucket? Does that seem intuitive in this case? – Josh Padnick

1 Answers

5
votes

It turns out the key documentation here is the Identity and Access Management overview for Google Cloud Storage. From there, I learned the following:

  • GCS Bucket ACLs specify zero or more "entries", where each entry grants a permission to some scope such as a Google Cloud User or project. ACLs are now considered a legacy method of assigning permissions to a bucket because they only allow the coarse-grained permissions READER, WRITER, and OWNER.

  • The preferred way to assign permissions to all GCP resources is to use an IAM Policy (overview). An IAM Policy is attached to either an entire Organization, a Folder of Projects, a specific Project, or a specific Resource and also specifies one or more "entries" where each entry grants a role to one or more members.

  • With IAM Policies, you don't grant permissions directly to members. Instead, you declare which permissions a role has, and grant members a role.

Ultimately, the hope is that you assign IAM Policies at the appropriate level of the hierarchy, knowing that lower levels of the hierarchy (like individual resources) inherit the permissions declared by the IAM Policies at higher levels (like at the Project level).

Based on this, I conclude that:

  • You should try to assign permissions to a GCS Bucket by assigning IAM Policies at the right level of the hierarchy.
  • However to limit permissions on a per-object basis, you must use ACLs.
  • When a Bucket is newly created, unless you specify otherwise, it is defined the default Canned ACL of projectPrivate.
  • As of this answer, Terraform does not yet have mature support for IAM Policies and the google_storage_bucket_acl resource represents an interface to a legacy approach to securing a Bucket.

Caveat: I'm only summarizing the docs here and have very limited practical experience with Google Cloud so far! Any corrections to above are welcome.