Cloud Storage Access Control with IAM and ACLs

Evaluate Access Control Methods in Cloud Storage (opens in a new tab) means comparing how Identity and Access Management (IAM), uniform bucket-level access (opens in a new tab), and Access Control Lists (ACLs) control who can read or change buckets and objects. Cloud Storage buckets are private by default, and access is granted with bucket-level IAM roles such as roles/storage.objectViewer. Public access makes objects readable to everyone on the public internet, so the choice between public and private determines the trust boundary around the data.

1.1Public and Private Access Configurations

Public and private access configurations in Cloud Storage define whether data is open to the internet or limited to specific principals. A private bucket grants access only to users, groups, or service accounts that receive an IAM role on the bucket, while a public bucket grants read access to everyone. Private sharing can target one person with a user binding or many collaborators with a group binding, such as granting roles/storage.objectViewer to group:my-group@googlegroups.com or to user:jeffersonloveshiking@gmail.com.

Public access is created with a bucket-level IAM policy that makes all objects in the bucket readable to everyone on the public internet. Because that policy applies to the whole bucket, a single change exposes every current and future object inside it. Best practice is to block public access unless the use case truly requires open distribution, and to keep sensitive data private with least-privilege IAM roles.

1.2Uniform Bucket-Level Access for Consistent Management

Uniform bucket-level access for consistent management is a Cloud Storage bucket setting that unifies access control under a single permission system. When uniform bucket-level access is enabled on a bucket, only bucket-level IAM roles grant access to the bucket and its objects, and individual object ACLs no longer apply. This consistency simplifies management because administrators review one IAM policy per bucket instead of different rules on each object, and it is required to use some features such as managed folders.

Uniform bucket-level access is managed by principals with the Storage Admin (roles/storage.admin) role on the bucket, which contains the storage.buckets.get, storage.buckets.list, and storage.buckets.update permissions. Before enabling uniform bucket-level access, check whether applications still depend on object ACLs by viewing the storage.googleapis.com/authz/acl_operations_count metric for the GCS Bucket resource in Cloud Monitoring. If the metric shows ACL operations, those workflows must move to IAM before uniform access is turned on, or they will stop working.

1.3Access Control Lists (ACLs) for Per-Object Exceptions

Access Control Lists (ACLs) for per-object exceptions are per-object and per-bucket rules that grant OWNER, READER, or WRITER permission to specific users, groups, domains, or special entities. A bucket also has a default object ACL that sets the starting ACL for new objects created in that bucket. When uniform bucket-level access is disabled, both bucket-level IAM policies and object ACLs can grant access, so two different systems must be checked to know who can reach an object.

ACLs allow fine-grained exceptions, such as giving one user control of one object without changing the bucket policy. That flexibility creates risk because permissions can drift across thousands of objects and become hard to audit. Uniform bucket-level access removes that drift by disabling object ACLs, which is why uniform access is recommended as the standard for consistent accessibility.

1.4Choosing a Secure Access Strategy

Choosing a secure access strategy for Cloud Storage combines private defaults, uniform control, and group-based IAM grants. The two access models compare as follows:

To secure cloud storage resources, apply consistent controls across buckets. The bucket stays as the policy boundary, where IAM grants flow from the bucket to all objects inside it:

• Block public access to Cloud Storage buckets unless open internet reads are required.
• Use uniform bucket-level access to keep bucket and object permissions in one IAM policy.
• Grant access to Google groups instead of many individual users, and use IAM conditions or signed URLs for temporary or single-object sharing.
• Require Storage Admin (roles/storage.admin) for changing uniform bucket-level access and monitor ACL usage before migration.

Together these practices prevent accidental exposure from a forgotten public grant or a hidden object ACL.

Analyze the Characteristics of Public, Private, and Uniform Access means explaining how Cloud Storage (opens in a new tab) decides who can reach buckets and the objects inside them. Private access limits data to specific principals through IAM, public access opens data to the internet, and Uniform Bucket-Level Access makes IAM the single, consistent rule for a whole bucket. Together these options let you balance open accessibility against tight security.

2.1Private Access with Identity and Access Management

Private access with Identity and Access Management (IAM) (opens in a new tab) means only named principals can act on buckets, managed folders, and objects. IAM is the system that enforces this by granting roles to principals, where each role bundles one or more permissions such as storage.objects.get or storage.objects.create. Principals are the “who” of IAM and include:

• Individual user accounts identified by email address
• Service accounts identified by email address
• Google groups identified by group email address
• Domains associated with Google Workspace or Cloud Identity

An IAM policy is the collection of roles set on a resource, and the access it grants flows downward from the resource where it is set to everything contained within it. A policy set on a project applies to all buckets, managed folders, and objects in that project, while a policy set on a bucket applies only to that bucket and its contents. Permissions granted at different levels add together, so a user can have read access from the project level and create access only on one bucket.

Private control can be refined below the bucket with managed folders. A managed folder is not a true directory tree but a resource overlay used only for permission checking, and it can grant or revoke additional access beyond the IAM permissions set on the bucket. You cannot set an IAM allow policy directly on an individual object, and you cannot set an IAM deny policy on a bucket, managed folder, or individual object. IAM deny policies attached higher in the hierarchy still override any allow, so a denied principal cannot use that permission on the resource or any sub-resource within it.

2.2Public Access Options for Internet Sharing

Public access options for internet sharing define how data can be read by entities outside your organization, including anonymous users on the internet. Buckets and objects are private by default, and they become public only when you grant access to a special public principal through IAM or through legacy ACLs. The two public scope identifiers work differently: allUsers represents any entity on the internet, while allAuthenticatedUsers represents most authenticated accounts, including service accounts.

In the Google Cloud console both identifiers appear with the label Public, which makes them easy to confuse. Granting a read role such as Storage Object Viewer to allUsers means traffic flows from any internet client directly to the bucket or object without authentication. Granting the same role to allAuthenticatedUsers still requires the requester to authenticate with a Google account or service account before Cloud Storage serves the data. Choose allUsers only for truly public content such as website assets, and choose allAuthenticatedUsers when every viewer must still prove identity.

2.3Uniform Bucket-Level Access for Single-System Enforcement

Uniform Bucket-Level Access for single-system enforcement is a bucket setting that makes IAM the only access control system for that bucket and all objects within it. When uniform access is enabled on a bucket (opens in a new tab), bucket ACLs and object ACLs are disabled, so permission checks use only the bucket-level and higher IAM policies. This creates one consistent rule: the policy applies to the bucket, and the same policy automatically applies to every managed folder and object inside it.

Without uniform access, a bucket uses fine-grained control where IAM and ACLs work in tandem. In that mode a user needs the relevant permission from either system to access data, and object ACLs work independently from IAM roles and do not appear in the IAM policy hierarchy. Only Storage Legacy Bucket roles stay synchronized with bucket ACLs, where changing one updates the other, while all other IAM roles leave ACLs unchanged. Because this split can leave hidden object-level grants, you should avoid ACLs and enable uniform access for consistent, least-privilege security.

2.4Comparing Access Choices for Storage Scenarios

Comparing access choices for storage scenarios shows how private control, public grants, and uniform enforcement differ by audience and control system. Private IAM control is the default for internal data, public grants are the exception for shared content, and uniform access is the recommended way to enforce either choice consistently.

Carefully evaluate policies before setting them at the project, bucket, or managed folder level, because a higher-level grant can give access to objects that were previously private.

Differentiate Between IAM Policies and Access Control Lists (ACLs) in Cloud Storage (opens in a new tab) means contrasting broad, inherited IAM grants with narrow, per-object ACL grants. An IAM policy grants broad, inherited access through roles, while an ACL grants narrow, per-bucket or per-object access to specific accounts. A user needs permission from only one of the two systems to access a bucket or object, so both systems must be checked unless Uniform Bucket-Level Access is enabled.

3.1Identity and Access Management Policies in a Hierarchy

Identity and Access Management Policies in a hierarchy are the recommended way to control access in Cloud Storage. A principal, which is the “who” such as a user, group, domain, service account, or the public, is granted a role under Identity and Access Management (IAM) (opens in a new tab), and each role bundles one or more permissions such as storage.objects.get or storage.objects.create. The set of roles attached to a resource is called an IAM policy, and that policy applies to the resource itself and to everything contained within it.

IAM policies can be attached at the project level, bucket level, or managed folder level, but they cannot be attached directly to an individual object. Permissions flow downward and add together through the hierarchy, so a project-level grant applies to all buckets, folders, and objects in that project, while a bucket-level grant applies only to that bucket and the folders and objects inside it. For example, a user can receive the Storage Object Viewer (roles/storage.objectViewer) role on a project to read objects in every bucket, plus the Storage Object Creator (roles/storage.objectCreator) role on bucket A to create objects only in that bucket.

IAM also supports deny policies, which block a permission even when an allow policy or an ACL would grant it. Deny policies override all allow grants, but they cannot be set on buckets, managed folders, or individual objects. When reviewing access, project and bucket policies must be checked together, because viewing a project policy does not show bucket policies, and tools such as gcloud storage return only the bucket policy without inherited project permissions.

3.2Access Control Lists for Single Buckets and Objects

Access Control Lists for single buckets and objects are a legacy, fine-grained system that grants permission on a single bucket or a single object to a specific scope under access control lists (ACLs) (opens in a new tab). Unlike IAM, an ACL does not inherit through the resource hierarchy and does not appear in IAM policies, so each object can have different readers or owners. This object-specific granularity makes ACLs flexible for one-off sharing, but difficult to audit at scale.

Each ACL entry pairs a scope with a permission, and permissions are concentric, which means WRITER also includes READER, and OWNER also includes both WRITER and READER. Common scopes include:

• allUsers for anyone on the internet, shown as Public in the console
• allAuthenticatedUsers for most authenticated accounts, including service accounts
• Individual user account email address
• Service account email address
• Google group email address
• Google Workspace or Cloud Identity domain name

Because object ACLs work independently from most IAM roles for Cloud Storage (opens in a new tab), granting an IAM role such as Storage Object Viewer does not change an object’s ACL, and granting an object ACL does not change IAM.

3.3How IAM Policies and ACLs Work Together

How IAM Policies and ACLs work together determines who can actually reach data when both systems are active. Cloud Storage grants access when either system allows it, so permissions granted by IAM do not appear in ACLs and permissions granted by ACLs do not appear in IAM. This means an evaluator must check project-level IAM, bucket-level IAM, and object ACLs to know the full access for an object.

One exception is Legacy Bucket roles, which stay synchronized with bucket ACLs in both directions. Adding or removing a Legacy Bucket IAM role updates the matching bucket ACL, and changing that bucket ACL updates the matching IAM role:

All other IAM roles, including project-level roles and Legacy Object roles, work independently from ACLs. IAM permission to change ACLs is itself controlled by IAM, where the storage.buckets.get, getIamPolicy, setIamPolicy, and update permissions together allow work with bucket and default object ACLs, and the matching storage.objects permissions together allow work with object ACLs.

3.4Uniform Bucket-Level Access to Simplify Security Operations

Uniform Bucket-Level Access to simplify security operations is a bucket setting that disables ACLs and makes IAM the only system for granting access to that bucket and its objects. When Uniform Bucket-Level Access is enabled, all access flows from project-level, bucket-level, and managed folder-level IAM policies, and per-object ACL grants are no longer evaluated. This removes hidden or inconsistent object-level permissions and leaves one hierarchy to review, change, and audit.

Uniform Bucket-Level Access simplifies security operations because administrators manage roles in one place with consistent inheritance from bucket to objects. New objects automatically follow the bucket’s IAM policy instead of receiving a separate default object ACL. Buckets without this setting keep both systems active, which is why enabling Uniform Bucket-Level Access is recommended for uniform, least-privilege control.

Key Facts

• Cloud Storage buckets are private by default and become public only when a read role is granted to allUsers for open internet access or to allAuthenticatedUsers for authenticated access.
• Uniform Bucket-Level Access disables bucket and object ACLs so only bucket-level, managed folder-level, and project-level IAM policies control access to the bucket and all objects inside it.
• IAM policies inherit downward and add together, so a project-level grant applies to all buckets and objects while a bucket-level grant applies only to that bucket and its contents.
• An IAM deny policy overrides any IAM allow policy and any ACL grant, even when the ACL would grant READER to the same principal.
• Storage Legacy Bucket Reader, Writer, and Owner roles stay synchronized with matching bucket ACLs, while all other IAM roles work independently from ACLs.