--- cuppy_hub: gcp cuppy_path: reference/storage/cloud-storage-access-control.md cuppy_section: docs cuppy_doc: G76G-EQ9R cuppy_doc_uuid: ec32afbe-43a9-40eb-92c2-b7267683c694 cuppy_permalink: https://cuppy.io/gcp/d/G76G-EQ9R cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/reference/storage/cloud-storage-access-control cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 9bd3e1b2932a864024c76cd682fa7e0deebb6587d75477ead30c386778f81f58 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.