Hello cloud Gurus,
I notice that there have been some changes in the Google Cloud Console. When Creating a bucket in GCS I can enter the name, select if its a regional bucket, multiregional or dual region. The new thing I notice is that the Storage classes are now simplified and you have a Standard, NEarline and coldline available. I like that. The second thing is that we have to specify how access will be controlled and the options are ACLs (which they call as legacy) and a new option called Bucket Only Policy. I looked at Bucket only policy and it seems to be the go to or desired method. I would like to know whether it is better than acls ? It seems to be more integrated with Audit Logs etc
Google document suggests:
You want to use GCP security features such as Cloud Audit Logs and Domain Restricted Sharing, which only track access granted through Cloud IAM policies, not ACLs.
However the document says:
Certain GCP services that export to Cloud Storage cannot export to buckets that have Bucket Policy Only enabled. These services include:
Stackdriver, Cloud Audit Logs, and Cloud Datastore.
This is highly confusing whether to use Bucket Level Policy or ACLs and which one is audit logged better?
Thank you
1 Answers
Hello, Asad! You’ve mentioned a few separate things, so I’ll try to address them all. 🙂
1) Google has improved the UI for creating new buckets and has now "untangled" the bucket location from its default storage class. I like this, too! 😁 If you remember back to the lecture where I introduced this, I was pointing out that the GCP console UI was quite clumsy in this regard and that you should think about these two things separately. I’m not sure that Google changing this had anything to do with me pointing it out, but who knows? 😉
2) Google’s talk about policies and ACLs really just amounts to whether you set security at the bucket level (policies) or at the object level (ACLs). In a similar way to how it’s a good idea to use groups for granting access to users, It can definitely simplify security to control access to resources in aggregate, too. In come cases, permissions should be granted at the level of a project–e.g. this group of users get read access to all objects in all buckets that live in this project. In other cases, different buckets in the same project will need different access settings for different groups, and bucket-level policies can still handle this. And although it is usually simpler (and therefore easier to secure correctly) when we can structure the access controls to be bucket-level, it is sometimes necessary to control access differently for objects that reside in the same bucket–so that’s where we’d use ACLs. From the docs: Use ACLs only when you need fine-grained control over individual objects.
3) Since it is easier to mess up security when ACLs are being used, Google is now offering (in Beta) "Uniform bucket-level access", which disables ACLs for a bucket. This closes off the possibility of ACLs granting access to objects, which means that you only need to audit your bucket policies instead of auditing every single object’s permissions individually. But more than that, though, since Cloud Audit Logs... only track access granted through Cloud IAM policies, not ACLs, then turning off the ACLs means that you will see tracked activity in there (instead of just maybe seeing it).
I hope this helps!
Mattias
I would also like to ask how to create a Bucket Only Policy and how does it relate to projects. What permissions are needed to enable services in a compute instance write to my bucket with a service account ?