Cloud Storage access control becomes difficult when teams mix several different mechanisms without understanding which one is authoritative. A bucket might use IAM, legacy ACLs, public access prevention, signed URLs, service account credentials, IAM Conditions, and organization policy at the same time. If the operator treats all of these as interchangeable "permissions," troubleshooting becomes slow and data exposure becomes easier.
The safer model is to decide first who should access the data, for how long, and under which identity. Then choose the mechanism that matches that requirement. This is the operational perspective most useful to an Associate Cloud Engineer.
IAM and ACLs are separate permission systems
Cloud Storage historically supports both Identity and Access Management and Access Control Lists.
IAM fits the wider Google Cloud authorization model. Roles can be granted at project and bucket scope, inherited where appropriate, and combined with conditions. This is usually the preferred model for modern environments because it is consistent with how access is managed across Google Cloud.
ACLs are specific to Cloud Storage and can grant permissions to individual objects. When IAM and ACLs are both active, access can be granted by either system. That creates a subtle risk: an administrator may remove an IAM binding and assume the object is private, while an ACL still grants access.
That is one reason Google recommends uniform bucket-level access for many environments. It reduces the number of parallel permission systems an operator must reason about.
Uniform bucket-level access simplifies authorization
Uniform bucket-level access disables bucket and object ACLs so access is granted exclusively through IAM.
This changes more than the user interface. Requests to modify ACLs fail, object ownership behavior changes, and access that existed only through an ACL is removed. If an existing bucket contains historical per-object sharing, enabling the feature without an access migration can break applications.
Uniform bucket-level access also becomes important for newer Cloud Storage capabilities. Google documents it as required for features such as managed folders, bucket-level IAM Conditions, and access by Workforce Identity Federation or Workload Identity Federation principals.
A critical operational detail is the 90-day rule: after uniform bucket-level access has been continuously enabled for 90 days, it cannot be disabled. That makes pre-migration analysis important.
Before enabling it on an established bucket, export or inspect existing ACLs and identify principals whose only access comes from those ACLs. Test automated tools as well as human workflows: older software may explicitly call ACL APIs even when its real data access could be represented in IAM. Because those ACL operations begin returning errors under uniform bucket-level access, application compatibility is part of the migration.
Treat the change as an access-control migration, not as a harmless toggle.
Put roles at the narrowest useful scope
A bucket should not inherit broad access from a project merely because project-level IAM is convenient.
If one workload needs to read one bucket, a bucket-scoped role is often easier to review than a project-wide storage role. If several buckets form one managed data domain, project-level access may be appropriate. The right scope depends on the administration boundary.
Avoid giving applications Storage Admin unless they truly need to manage bucket configuration and permissions. Reading objects, writing objects, and administering a bucket are distinct tasks and should be represented by distinct roles.
Service accounts are especially useful for workload access. An application can run with a dedicated identity whose storage permissions are limited to the required buckets. In larger environments, separate identities for ingestion, processing, and publishing reduce blast radius and make audit logs easier to interpret. A data loader that only creates objects does not need permission to change bucket IAM, and a reporting service that only reads a prefix should not automatically receive write access.
Google Cloud service accounts provide the identity-management foundation; the storage design should then grant that identity only the object operations it needs.
Signed URLs solve a different problem than IAM
Sometimes the consumer of an object should not have a Google Cloud identity at all.
A signed URL provides time-limited access to a specific Cloud Storage resource. Anyone who possesses the URL can use it while the signature is valid, so it behaves more like a temporary capability than an IAM identity.
This makes signed URLs useful for controlled downloads and uploads, such as allowing a customer to download a generated report or upload a file directly to a bucket without receiving broad bucket credentials.
The security boundary is therefore possession of the URL. Treat the URL itself like a temporary secret and avoid exposing it to systems that retain request strings longer than intended. Applications should keep expiration windows appropriate to the use case and avoid leaking signed URLs into logs, analytics systems, tickets, or referer headers.
Signed URLs are not a substitute for IAM when a persistent workload identity exists. They are better for narrow, temporary delegation.
Public access prevention protects against accidental exposure
Public access prevention is designed to stop buckets and objects from being made public through IAM or ACL grants.
It can be enforced at the bucket level or through organization policy. When enforced, permissions cannot be granted to broad public principals such as anonymous internet users.
An important nuance is that signed URLs are not blocked by public access prevention. A private bucket can therefore remain protected from public IAM or ACL grants while an application issues controlled signed URLs for selected objects.
That separation is useful: public access prevention defines an organizational guardrail, while signed URLs provide deliberate time-bounded sharing.
For sensitive environments, enforcing public access prevention higher in the hierarchy can be safer than relying on every bucket owner to remember the correct setting.
Conditions and managed folders add precision
Uniform bucket-level access enables IAM Conditions directly on a bucket. Conditions can constrain when a binding applies based on supported attributes.
Managed folders provide a way to organize object namespaces and apply IAM at a more granular logical level than the entire bucket. They can help when a single bucket contains separate application or tenant data domains that need independent administration.
These tools should be used to make the policy clearer, not to create a puzzle. If an environment accumulates overlapping conditions, managed-folder grants, project grants, service account roles, and organization constraints, troubleshooting becomes difficult even when each individual control is valid.
A good policy model makes it possible to explain access in a short sentence: "This workload identity can read objects under this managed folder, and nothing can make the bucket public."
Troubleshoot 403 errors systematically
A Cloud Storage 403 should be investigated as an authorization decision, not immediately treated as a bad password.
First identify the identity used by the request. Local development tools may be using a human Application Default Credentials token while the deployed application uses a service account.
Second identify the required permission for the failed operation. Listing objects, reading an object, writing an object, changing retention, and modifying bucket IAM need different permissions.
Third inspect the scope of the relevant role. A role on one bucket does not help a request to another bucket with a similar name.
Fourth check the access model. If uniform bucket-level access is enabled, object ACL troubleshooting is irrelevant. If it is not enabled, an unexpected ACL may grant or deny assumptions about who should have access.
Finally check broader controls such as organization policy, public access prevention, and IAM Conditions.
Migrate legacy ACL-heavy buckets deliberately
Existing buckets can carry years of per-object ACL history.
Before enabling uniform bucket-level access, inventory principals that receive access only through ACLs. Map those permissions to IAM roles at the appropriate bucket or project scope. Test application behavior, especially software that explicitly reads or writes ACL metadata.
The migration should also identify public objects. Record which applications depend on object-level semantics, because those are the workloads most likely to reveal hidden ACL assumptions during testing. If an application currently depends on anonymous access, decide whether that behavior is truly required, whether public access prevention should be enforced, or whether signed URLs or a controlled delivery layer is safer.
Once access has been represented in IAM, enable uniform bucket-level access and monitor for failures. Do not assume an ACL migration is complete because one test object works.
Choose the mechanism from the access story
A strong Cloud Storage design can be summarized by use case.
Use IAM for durable access by users, groups, and workloads with Google Cloud identities.
Use uniform bucket-level access when you want IAM to be the single authorization system and do not need per-object ACLs.
Use managed folders and IAM Conditions when the bucket requires finer policy boundaries that remain understandable.
Use public access prevention when organizational policy says data must not become anonymously public.
Use signed URLs when an unauthenticated external party needs narrow, temporary access to a specific resource.
For deeper security architecture, the same distinctions also matter to the Professional Cloud Security Engineer. The goal is not to combine every available control. It is to use the fewest controls necessary to express the intended access model clearly and safely.