Cloud Storage access control — uniform bucket-level access, the 90-day window, public access prevention, and the five mechanisms
Five ways to grant access to a bucket, the one Google recommends, and the one-way door in the middle of it: uniform bucket-level access can be reversed for 90 days and then becomes permanent. Also public access prevention, IP filtering and credential access boundaries.
markdownreferencev1G76G-EQ9Rstage: buildtrust: officialfamily: storageservice: cloud-storageinterface: anyuniform bucket-level accessfine-grained accessACLsigned URLsigned policy documentpublic access preventionallUsersallAuthenticatedUsersbucket IP filteringcredential access boundaries90 days
Cloud Storage access control
1. The five mechanisms
| Mechanism | What it is |
|---|---|
| IAM | permissions at project and bucket level — the model the rest of Google Cloud uses |
| ACLs | the legacy per-object system |
| uniform bucket-level access | disables ACLs, so IAM alone decides |
| signed URLs | time-limited access through a generated URL |
| signed policy documents | constrain what an upload is allowed to be |
Plus three narrower controls on the same page: public access prevention, bucket IP filtering, and credential access boundaries (downscoping an OAuth token's permissions).
2. Google's recommendation, and the reason
Uniform bucket-level access is marked "(recommended)", and the page's reason for not using fine-grained access is that it carries "an increased chance of unintentional data exposure". Two access-control systems on one object means two places to get it wrong and one of them is per object.
Uniform bucket-level access "allows you to use Identity and Access Management (IAM) alone to manage permissions".
3. The one-way door — read this before you enable it
"Once you enable uniform bucket-level access, you have 90 days to switch back to fine-grained access before uniform bucket-level access becomes permanent."
So the decision is reversible for a quarter and then it is not. Enable it on a new bucket, deliberately, at creation. Enabling it on an inherited bucket whose consumers may depend on object ACLs starts a 90-day clock on a change you have not yet proven safe — and the proof is per consumer, not per bucket.
The hub's reading for a migration: turn it on for every bucket you create on Google Cloud, and treat an existing bucket's ACL usage as a discovery task with a 90-day decision attached.
4. Public access prevention
It blocks access through the allUsers and allAuthenticatedUsers principals. Those two are how a Google
Cloud bucket becomes world-readable, and allAuthenticatedUsers is the more dangerous of the pair precisely
because it reads as if it meant "authenticated to my organization". It does not.
Turn public access prevention on unless the bucket's whole job is to serve the public, and in that case put
the bucket behind Cloud CDN and a load balancer instead (reference/networking/cloud-load-balancing.md).
5. Signed URLs and signed policy documents
A signed URL grants time-limited access without an identity on the caller's side; a signed policy document constrains an upload's specification. Both are the answer to "a browser needs to read or write one object" and neither needs a bucket to be public.
They are also the two mechanisms whose signing identity matters: the signature is only as narrow as the identity that signed it. Sign with a purpose-made service account, not with a broadly privileged one.
Next: reference/storage/errors.md for the refusal strings these settings produce, and
guides/storage/create-a-bucket-that-is-not-public.md for the order to apply them in.