IAM Policies, Conditions and Storage ACLs

Troubleshoot, analyze, and optimize Identity and Access Management (IAM) (opens in a new tab) policy bindings is the practice of finding why access fails, determining what access is actually effective, and removing excess privilege. An allow policy, also called an IAM policy, is attached to a Google Cloud resource and contains role bindings that associate principals such as users, groups, or service accounts with IAM roles. Each binding grants its role both on the attached resource and on all of that resource's descendants, so analysis must always consider inheritance from organization to folder to project to resource.

1.1Diagnose Common Access Failures

Diagnosing common access failures means checking whether the principal is present in the IAM policy of the linked project and whether the assigned roles match the required access. A typical symptom is the error Cannot Authenticate user, because user does not have access to the GCP project associated with this [Chronicle](https://docs.cloud.google.com/chronicle/docs/onboard/log-in-to-new-instance) customer, which means the project does not grant the necessary roles to the user's account or group. Verification is done in the Google Cloud console at IAM & Admin > IAM, where an administrator confirms membership and roles, while only project administrators can change those bindings.

Changes made through automation can cause repeat failures, so recent SetIamPolicy history is a critical first check when access suddenly stops working.

1.2Audit Effective Permissions Across the Resource Hierarchy

Auditing effective permissions across the resource hierarchy means calculating the union of resource-level and inherited policies to enforce least privilege. A resource such as a Dataproc Metastore service can have its own IAM policy instead of or in addition to the project-level policy, which allows access to only the specific resources a collaborator needs. Resources inherit the policies of their parent resources, so the effective policy for a resource is the union of the policy set at that resource and the policy inherited from higher up.

Service accounts (opens in a new tab) require special attention during audits because service accounts are both resources that other principals can access and principals that can access other resources. To view who can use a service account, open the Service Accounts page, select the project, click the service account email, and open the Principals with access tab. Managing that access requires the Service Account Admin (roles/iam.serviceAccountAdmin) role on the service account or owning project, which contains these permissions:

• iam.serviceAccounts.get
• iam.serviceAccounts.list
• iam.serviceAccounts.getIamPolicy
• iam.serviceAccounts.setIamPolicy

1.3Track IAM Policy Changes with Audit Logging

Tracking IAM policy changes with Cloud Audit Logs provides the evidence needed to explain access issues and prove continuous compliance. Administrators review Logs Explorer for administrative activity and filter for IAM policy changes to find SetIamPolicy operations that removed or altered required access. For privileged workloads, audit logging is explicitly enabled for the relevant API, such as adding ADMIN_READ, DATA_READ, and DATA_WRITE log types for the compute.googleapis.com service in the project's policy file.

Exporting these logs for long-term retention lets enterprises analyze privileged access requests, review access patterns, and detect anomalies over time. This history connects a current denial to the exact binding change that caused it, rather than guessing about group membership or role assignment.

1.4Remediate Excess Privilege and Enforce Least Privilege

Remediating excess privilege means shrinking bindings to only the roles required for a task at the smallest scope in the hierarchy. Least privilege design grants users only the roles they require at the narrowest resource level, and resource-level policies are preferred over broad project-level grants when collaborators need only specific resources. After explicit Group Mappings are configured, the Default Access Settings toggle that grants Administrator access to all environments should be disabled so undefined users and groups receive no implicit access.

Ongoing optimization depends on recommendations and entitlement findings rather than one-time cleanup:

• Review and apply role recommendations to remove unused and excessive roles from IAM policies.
• Enforce the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints to reduce persistent service account keys (opens in a new tab).
• Use Cloud Infrastructure Entitlement Management (CIEM) (opens in a new tab) in Security Command Center to identify federated identities from Entra ID, Okta, Active Directory, or AWS IAM Identity Center that hold excess permissions on Google Cloud resources.
• Review offending access grants and recommended remediations directly on the Security Command Center Findings page and track large-scale fixes through cases, response playbooks, and security operations capabilities.

If access is granted to a user's email alias or secondary domain, the allow policy displays the user's primary email address or primary domain, so auditors should search for the primary identity when validating remediation.

1.5Implement Controlled Privileged Access with Impersonation

Controlled privileged access with impersonation replaces standing administrative rights with temporary membership in a privileged group that can impersonate a service account. In this model, the administrator creates a Google group named elevated-compute-access and a service account with the same purpose, then binds narrow permissions so group members act only through the service account for the period of membership. The service account holds the operational role, while the group holds only the ability to use that service account.

The implementation follows an ordered dependency where each binding enables the next step:

1. Create the delegation group: Create the Google group that will hold temporary privileged users.
2. Create the privileged service account: Create the service account and enable the IAM Service Account Credentials API for impersonation.
3. Grant operational access to the service account: Bind the service account to roles/compute.admin on the project so the account, not individual users, can administer Compute Engine instances.
4. Grant usage access to the group: Bind the group to roles/serviceusage.serviceUsageConsumer on the project so members can consume services during impersonation.
5. Grant impersonation rights to the group: Bind the group to roles/iam.serviceAccountTokenCreator on the service account so members can create tokens as that service account.
6. Validate and audit: Use a sample Compute Engine instance to confirm group members can access the instance only through impersonation, with Cloud Audit Logs enabled for review.

Because access flows from group membership to service account impersonation to the target instance, removing the user from the group automatically ends privileged access without changing the underlying resource policies.

Differentiating and managing Cloud Storage ACLs and Uniform Bucket-Level Access means choosing between two access models for buckets and objects. Cloud Storage offers legacy Access Control Lists (ACLs) that grant permissions separately on each bucket and object, and Uniform Bucket-Level Access (UBLA) (opens in a new tab) managed by Identity and Access Management (IAM) that enforces one centralized IAM policy at the bucket level. For least privilege and auditable access, UBLA with IAM is the recommended model and is enforced as a compliance control to set uniform bucket-level access on Cloud Storage buckets.

2.1Legacy Access Control Lists on Buckets and Objects

Legacy Access Control Lists (ACLs) are per-resource permission lists attached to an individual bucket and to individual objects within that bucket. A bucket ACL controls who can list or configure the bucket, while an object ACL can grant read or write to a single object independently of the bucket policy. This means access flows from two separate evaluation paths to the same data: the bucket IAM policy and the object ACL.

The security implication of legacy ACLs is fragmentation and loss of central control. An object uploaded with a permissive ACL can remain accessible even when the bucket IAM policy is restrictive, and ownership changes when different uploaders set different object ACLs. Auditing requires reading every object ACL in addition to the bucket IAM policy, which makes it difficult to prove least privilege, detect unintended allUsers exposure, or inherit consistent permissions from the project, folder, and organization hierarchy.

2.2Uniform Bucket-Level Access Managed by IAM

Uniform Bucket-Level Access (UBLA) is a bucket setting that disables object ACLs and requires all access to buckets and objects to be granted through IAM alone. When UBLA is enabled, the bucket IAM policy applies uniformly to every object in the bucket, and requests that attempt to set or read object ACLs are rejected. Data flows from the requester to Cloud Storage to a single IAM authorization check against the bucket policy and its inherited ancestor policies.

UBLA centralizes authorization, inheritance, and auditing in IAM. Permissions such as storage.buckets.get, storage.buckets.getIamPolicy, storage.objects.get, storage.objects.list, and storage.objects.create are grouped into IAM roles such as roles/storage.objectViewer and granted once at the bucket, project, folder, or organization level. You can get and set IAM policies using the Google Cloud console, the IAM API, or the Google Cloud CLI, and automate them with client libraries or the google_storage_bucket_iam_member Terraform resource. A public-read example adds a binding of roles/storage.objectViewer to allUsers on the bucket, which makes all objects in that bucket publicly readable under UBLA.

2.3Planning Migration from Object ACLs to Centralized IAM

Migration from object-level ACLs to centralized IAM is the process of replacing scattered object ACL grants with equivalent bucket IAM bindings before enforcing UBLA. The risk during transition is either loss of legitimate access if IAM is incomplete, or unintended exposure if permissive ACLs or public bindings are copied without review. Prevent unauthorized access by inventorying current grants, applying least-privilege IAM first, and combining UBLA with preventive controls such as public access prevention and restriction of public access to Cloud Storage buckets.

A safe migration follows an ordered workflow:

1. Inventory existing ACLs: List bucket and object ACLs to identify who has access through ACLs that does not already have it through IAM.
2. Map ACL grants to IAM roles: Translate object-reader and object-writer ACL entries into bucket-level IAM roles, preferring the most limited predefined roles that meet the need.
3. Apply and verify IAM before enforcing UBLA: Add the IAM bindings to the bucket, then test with iam-test-permissions behavior and getIamPolicy reads to confirm intended principals retain storage.objects.get or storage.objects.list and others do not.
4. Enable UBLA and validate: Turn on uniform bucket-level access on the bucket, then re-verify that only IAM principals can access objects and that no object ACL path remains.

During migration, avoid adding allUsers or allAuthenticatedUsers bindings for convenience, require bucket logging for audit evidence, and remove legacy object-ACL management code from applications so new uploads do not depend on ACLs that UBLA will ignore.

Configuring granular IAM roles, conditional bindings, and resource hierarchy inheritance means granting precise permissions by role, location in the hierarchy, and condition. Granular access in Google Cloud is built from Identity and Access Management (IAM) (opens in a new tab) policies that bind principals to roles on specific resources. A principal never receives a permission directly; permissions are grouped into a role, the role is granted to a principal in a binding, and the binding is attached to an organization, folder, project, service, or access policy.

3.1How IAM Roles Grant Precise Permissions

How IAM roles grant precise permissions is defined by the rule that every API request is checked against the roles the authenticated principal holds on the target resource. The principals that can appear in a binding are users, groups, service accounts, and Google domains, and the IAM policy attached to the resource defines which roles each principal holds:

• User account identified by email address, such as for interactive administration
• Google group identified by email address, such as for team-based access
• Service account identified by email address, such as for workloads using one identity across projects
• Google domain, such as for broad organizational membership

Least privilege requires choosing narrow roles instead of broad ones. Predefined roles package the permissions for a specific job, custom roles package only the permissions copied from or modeled on predefined roles, and basic roles grant a very large set of permissions across a project. For Cloud Load Balancing (opens in a new tab), for example, work is split across Compute Load Balancer Admin (roles/compute.loadBalancerAdmin), Compute Network Admin (roles/compute.networkAdmin), Compute Security Admin (roles/compute.securityAdmin), and Compute Instance Admin (roles/compute.instanceAdmin), while a custom role must contain at least the permissions in the predefined roles it replaces and basic owner or editor roles should be avoided because they violate least privilege.

3.2Predefined Roles for Access Context Manager

Predefined roles for Access Context Manager (opens in a new tab) determine whether a principal can view or configure service perimeters, access levels, and access policies. The role determines whether the principal can create policies, list policies, or manage perimeters and levels, and creation, listing, or delegation of scoped policies requires the permission at the organization level.

Permissions granted at the organization level apply to the organization-level access policy and to all scoped policies. After a scoped policy is created, management of that policy can be delegated by adding IAM bindings directly on the scoped policy itself.

3.3Resource Hierarchy Inheritance and Policy Boundaries

Resource hierarchy inheritance and policy boundaries control how IAM policies flow from parent resources to child resources. A child resource always inherits the policy of its parent, so a role granted on a parent automatically applies to all resources below it unless a separate boundary overrides that flow. For the Service Management API (opens in a new tab), each managed service is a child resource of its service producer project, so roles granted on the producer project apply to all managed services that belong to that project.

Scoped policies for Access Context Manager follow a separate boundary that breaks normal folder and project inheritance. Any Access Context Manager permissions granted on folders or projects have no effect on scoped policies, because permissions for scoped policies can only be granted at the organization level or on individual policies. The access control for a scoped policy is therefore independent of the projects or folders in its scope, even though organization-level grants still flow down to every access policy.

3.4Conditional and Context-Aware Bindings

Conditional and context-aware bindings limit when and where a role grant is valid. An IAM conditional binding adds a Common Expression Language (CEL) expression to a role grant so the grant is valid only when request, resource, or time attributes match. The condition travels with the binding in commands such as gcloud ... add-iam-policy-binding ... --condition, and the request is allowed only when both the role permission and the CEL expression evaluate to true. This pattern supports resource-specific grants, such as restricting a principal to one agent application, and time-bound grants, such as access that expires after a window.

Context-aware enforcement also uses group-to-level bindings and policy bindings that connect a policy to a target. A Google group is bound to one or more access levels, members of the group are granted access only if they satisfy the conditions in the bound levels, and multiple selected levels are logically ORed so meeting at least one level is sufficient. An access policy is enforced by binding it to a target resource scope, where data flows from the access policy to the policy binding and then to the target resource such as //cloudresourcemanager.googleapis.com/projects/PROJECT_ID.

Key Facts

• An IAM allow policy grants a role on the attached resource and on all descendants, so effective access is the union of resource-level and inherited parent policies.
• Service accounts are both resources that other principals can access and principals that can access other resources, with access managed through the Principals with access tab and the Service Account Admin role.
• Uniform Bucket-Level Access disables object ACLs so only the bucket IAM policy grants access, and any access previously granted only by an object ACL is revoked when UBLA is turned on.
• IAM conditional bindings use Common Expression Language expressions so a role grant is valid only when request, resource, or time attributes match.
• Access Context Manager permissions granted on folders or projects have no effect on scoped policies, which can only be granted at the organization level or on individual policies.