IAM Authorization with Deny Policies and Temporary Elevation

Managing privileged roles and separation of duties means no single identity can both grant sensitive access and use that access without oversight. Identity and Access Management (IAM) binds a principal such as a user, group, or service account to a role at a defined scope, and every request is checked against that binding. A toxic combination occurs when one principal holds grant permissions like resourcemanager.projects.setIamPolicy together with use permissions like data edit rights.

1.1Just-in-Time Elevation with Privileged Access Manager and Temporary Bindings

Privileged Access Manager (PAM) is the managed service for temporary privilege elevation with justification, approvals, and history. An administrator creates an entitlement that defines who can request which roles on which resources, then a requester creates a time-bound grant with a business justification. After expiry, PAM records when the roles were active, which resources were accessible, the justification, and who approved the grant.

Temporary elevation can also use building blocks that lack built-in workflow:

• IAM Conditions attach a time condition to an allow-policy binding that IAM evaluates on every request, but expired bindings remain in the policy until removed.
• Google Groups provide expiring membership through the Groups API, so access ends without manual removal.
• Service account impersonation places a privileged role like roles/compute.admin on a dedicated service account and grants a group only roles/iam.serviceAccountTokenCreator to mint short-lived tokens.

The PAM grant lifecycle moves through ordered states. First an entitlement defines eligibility, then a grant is requested with justification, then the grant is approved or denied, then the grant becomes active for the approved window, and then the grant expires or is withdrawn into auditable history.

1.2Separation Between Grant Authority and Resource Use

Separation between grant authority and resource use keeps policy administration distinct from data and feature use. Project IAM Admin (roles/resourcemanager.projectIamAdmin) can assign and modify IAM bindings for a project but does not by itself grant data use. Chronicle API Admin (opens in a new tab) (roles/chronicle.admin) provides full use of the application and API services, while Security Admin (roles/iam.securityAdmin) provides a narrower grant path for data-access scopes.

Enforcement follows a fixed order. First the principal sends an API request or opens an application page, then the service queries the IAM policies for that user or group in the bound project, then IAM returns the authorization decision based on roles, conditions, and scope, and then the service enables only the granted features. In a shared project, grant roles must carry IAM Conditions that limit the administrator to specific resource types so a feature administrator cannot escalate into unrelated resources.

1.3Auditing, Super Admins, and Context Constraints

Auditing and context constraints keep elevated power temporary, observable, and revocable. Cloud Audit Logs record SetIamPolicy changes, elevation requests, impersonation, and data access, and traffic flows from the Google Cloud API to Cloud Audit Logs to long-term storage and analysis. IAM Recommender analyzes usage to flag unused and excessive grants that should be removed or converted into PAM entitlements for on-demand use.

Super admins and persistent credentials need special limits because a Google Workspace super admin can modify the organization IAM policy and must be treated as having full access to all resources. Emergency access is isolated in a dedicated organizational unit, exempted from single sign-on, protected with Fast IDentity Online (FIDO) keys for 2-Step Verification, and limited to a minimum of two and a maximum of five users. Persistent keys are restricted with the constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints, while Access Context Manager, Chrome Enterprise Premium, and VPC Service Controls check network, device, and perimeter context on every request.

Managing IAM and access control list permissions means finding why access fails, calculating effective access across inheritance, and replacing broad grants with narrow ones. An IAM allow policy attaches to a Google Cloud resource and binds principals to roles, and each binding applies to the attached resource and to all of its descendants. Analysis must therefore consider inheritance from organization to folder to project to resource.

2.1Diagnosing Failures and Auditing Effective Permissions

Diagnosing IAM failures means checking whether the principal appears in the linked project policy and whether the roles match the required access. A missing user or group, an incorrect predefined or custom role, or a recent SetIamPolicy change by an administrator or automation can all cause denials. Administrators verify membership in IAM & Admin > IAM and review Cloud Audit Logs in Logs Explorer filtered for SetIamPolicy to find the change that removed access.

Auditing effective permissions means calculating the union of resource-level and inherited policies. A Dataproc Metastore (opens in a new tab) service can have its own IAM policy that grants access to only that service instead of the whole project. Service accounts need special attention because a service account is both a resource that other principals can access and a principal that can access other resources. To see who can use a service account, open the service account email and open the Principals with access tab, which requires Service Account Admin (roles/iam.serviceAccountAdmin).

2.2Uniform Bucket-Level Access Versus Legacy ACLs

Uniform Bucket-Level Access (UBLA) is the recommended Cloud Storage model that disables object ACLs and enforces one bucket IAM policy for all objects. When UBLA is enabled, the bucket IAM policy applies uniformly to every object, and requests that try to set or read object ACLs are rejected. Data flows from the requester to Cloud Storage to a single IAM check against the bucket policy plus inherited ancestor policies.

Legacy Access Control Lists (ACLs) are per-resource lists attached to an individual bucket and to individual objects. A bucket ACL controls listing or configuring the bucket, while an object ACL can grant read or write to one object independently of the bucket policy. This fragmentation lets an object uploaded with a permissive ACL remain accessible even when the bucket IAM policy is restrictive, and auditing requires reading every object ACL.

A safe migration inventories bucket and object ACLs first, then maps ACL entries to limited bucket IAM roles, then applies and verifies IAM before enforcing UBLA, and then enables UBLA and re-verifies that only IAM principals retain access.

2.3Granular Roles, Conditional Bindings, and Inheritance Boundaries

Granular IAM roles, conditional bindings, and inheritance boundaries grant precise permissions by role, location, and condition. 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 attaches to an organization, folder, project, service, or access policy. For Cloud Load Balancing, work splits across Compute Load Balancer Admin, Compute Network Admin, Compute Security Admin, and Compute Instance Admin, while basic Owner or Editor roles should be avoided because they violate least privilege.

Resource hierarchy inheritance flows only downward, so a child always inherits its parent policy. For the Service Management API, each managed service is a child of its producer project, so roles on the producer project apply to all its managed services. Scoped policies for Access Context Manager break normal inheritance because permissions on folders or projects have no effect on scoped policies, which can only be granted at the organization level or on individual policies. Conditional bindings add Common Expression Language (CEL) expressions so a grant is valid only when resource, time, or request attributes match, and Cloud Load Balancing caches IAM permissions for five minutes before role changes take effect.

Granting permissions to different identity types means scoping native and federated identities with conditions, deny policies, and boundaries. Identity and Access Management (IAM) allow policies grant permissions, while IAM Conditions, IAM deny policies (opens in a new tab), principal access boundary policies, and organization policy constraints narrow that access. Native identities authenticate inside Cloud Identity, while external humans and workloads enter through federation with different principal identifiers.

3.1Native Identities, Federated Identities, and Guardrails

Native identities are Cloud Identity users, Google Groups, and service accounts that authenticate directly to Google Cloud. Default service accounts are high risk because a new default service account is automatically granted the Editor role unless the constraints/iam.automaticIamGrantsForDefaultServiceAccounts constraint is set to False. Long-lived keys expand risk, so organizations set constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload to True and limit any remaining key lifetime with constraints/iam.serviceAccountKeyExpiryHours to less than or equal to 2160 hours, which is 90 days.

Federated identities avoid keys by exchanging external tokens for short-lived Google tokens. Workforce Identity Federation federates an external identity provider with a workforce identity pool using SAML 2.0 or OpenID Connect, without duplicating users in Cloud Identity. A single user is addressed as principal://.../subject/SUBJECT and a set of users as principalSet://.../group/GROUP_ID. Workload Identity Federation lets outside workloads like CI/CD systems exchange short-lived external tokens for temporary Google access tokens that expire in minutes. Both depend on attribute mappings that translate provider claims into Google attributes and on attribute conditions that reject tokens from unauthorized tenants or repositories.

3.2Conditional Bindings for Resource-Scoped Access

IAM Conditions bindings grant a role only when a CEL expression evaluates to true at access time. Resource-based conditions use resource name, type, and service to limit a permission to resources whose names match a prefix or pattern, such as Compute Engine virtual machines that share a naming prefix. The resource-name attribute supports Compute Engine, Cloud Storage, BigQuery, Cloud SQL, Secret Manager, Spanner, Cloud Key Management Service, and Google Kubernetes Engine.

Resource Manager tags provide a second scoping axis by annotating resources so policies allow or deny based on tag presence across the hierarchy. Managing these bindings requires resourcemanager.projects.getIamPolicy and setIamPolicy on projects, the equivalent folder permissions on folders, or broad administration through Project IAM Admin, Folder Admin, Organization Admin, or Security Admin. A conditional binding never removes access granted by an unconditional binding for the same principal and role.

3.3How Deny Evaluation Overrides Allow Grants

Deny evaluation is the order in which IAM checks deny policies before allow policies on every request. Traffic flows from the request to the deny evaluation engine first and then, only if no deny rule blocks it, to the allow policy evaluation. If any applicable deny rule matches the principal, permission, and condition, the action is blocked even if an allow policy grants it higher in the hierarchy.

A deny policy attaches at an organization, folder, or project and flows downward to all descendants. A resource can have up to 500 deny policies attached, with a combined total of up to 500 deny rules, and deny changes generally take effect within 2 minutes and sometimes take 7 minutes or more. Each deny rule names denied principals in IAM v2 format, denied permissions like iam.googleapis.com/roles.delete, optional exception principals and exception permissions, and an optional CEL condition based only on resource tags. If the condition is true or cannot be evaluated, access is denied; only a false condition lets the allow policy decide.

Centralized designs deny sensitive actions like roles.create, roles.delete, and roles.update to principalSet://goog/public:all at the organization with an exception for a central group. Scoped designs attach a deny to one project like example-prod to subtract an inherited folder grant inside only that project.

Defining access control across hierarchy levels means granting the smallest role at the lowest scope that still covers the job. Identity and Access Management (IAM) (opens in a new tab) binds a principal to a role on a resource, and the effective allow policy for any resource is the union of its own policy plus all policies inherited from its parents. A grant at a higher level flows to every child, while a grant at a lower level applies only within that child.

4.1How Allow Policies Flow from Organization to Resource

How allow policies flow is defined by the Google Cloud resource hierarchy and downward inheritance. The Organization resource sits at the apex, folders sit below the organization, projects sit inside folders or the organization, and service resources like Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints sit inside exactly one project. Resource Manager creates and organizes this hierarchy, so moving a node also moves which policies the node inherits.

Choose a higher level when many children need the same access, and choose a lower level or add a condition when only a subset should have it. Because Owner includes Editor and Editor includes Viewer, an inherited role that already covers the need makes an additional lower-level grant redundant.

4.2Custom Roles with Precise Permissions

Custom IAM roles are user-created roles that contain only the permissions required for a task. Permissions have the form service.resource.verb and correspond closely to API methods, such as resourcemanager.organizations.get. A permission is never granted directly; permissions are bundled into a role and the role is granted on a resource.

The setIamPolicy permission on an organization, folder, or project allows the holder to grant all other permissions on that scope, so it must be excluded from custom roles unless policy administration is the intended job. Least-privilege placement grants the custom role at the smallest scope, such as Publisher on one Pub/Sub topic rather than on the project, and grants to groups rather than individual users. Moving a project into a folder can grant additional roles, while moving it out can remove roles and break applications.

4.3Conditional, Tag-Based, and Override Controls

Conditional and tag-based controls narrow broad hierarchy grants without creating a separate role for every exception. IAM Conditions add a condition expression to a binding so the role can be used only when the request satisfies tests on resource tags, resource name, resource type, service, IP address, or date and time. Tags annotate resources by purpose, environment, or sensitivity, so one policy can enforce the same rule on scattered resources that share a tag independent of folder placement.

Controls that restrict inherited access are needed because lower-level allows only add access and never remove it. Deny policies attach at the organization, folder, or project, are evaluated before allows, and can block permissions that an inherited allow would otherwise grant. Organization policies inherit but can be superseded lower in the tree, while hierarchical firewall policies inherit with allow, deny, or delegate decisions at each level. Folders can nest up to 10 levels deep, a parent can hold no more than 300 direct child folders, and display names must be unique within the same level.

Configuring Access Context Manager means defining context-aware boundaries from user identity, device state, and network context. An access policy is the organization-wide container that holds access levels and VPC Service Controls service perimeters, and enforcement happens when those levels and perimeters attach to resources through bindings, IAM conditions, and ingress rules. An access level alone does not block traffic until it is attached to an enforcement point.

5.1Service Perimeters for Exfiltration Protection

VPC Service Controls service perimeters are context-based boundaries that protect projects and restricted APIs from data exfiltration. A service perimeter encloses member projects and services to protect, and it denies requests that originate outside the perimeter unless an access level or ingress rule explicitly allows them. Perimeters also control egress across the boundary, and they do not replace least-privilege IAM inside the perimeter.

A regular perimeter defines one security zone, while a bridge perimeter connects projects that remain in different regular perimeters for controlled sharing without merging zones. Cross-perimeter flows need a matching pair: the source perimeter needs an egress rule that permits the call, and the destination perimeter needs an ingress rule that accepts the source identity and network. Bridges should be minimized because each bridge creates east-west policy that must be reviewed.

5.2Access Levels from Identity, Network, and Device Signals

Access levels are named requirements that a request must meet before protected access is honored. Identity and IP address work for any device, including unmanaged devices, but cannot prove device health. Device type, operating system, browser posture, certificate-based mutual TLS, and third-party vendor posture require managed devices with Endpoint Verification or Chrome Enterprise Premium. If a device is not managed, it must be treated as unmanaged and untrusted.

A basic level is built in Basic mode without code, such as allowing only a corporate public IP range. A custom level is written as a CEL expression that can combine identity, network, device, browser, and vendor signals, such as requiring a non-expired CrowdStrike assessment. Assigning multiple separate levels to the same app is a logical OR, so a device needs to satisfy only one level; to require corporate network plus compliant device plus strong credential together, those checks must live in one level.

5.3Attaching Levels, IAP Paths, and Dry-Run Testing

Attaching levels connects the access level to the traffic path from client to resource. An access binding assigns a level to a group and applies uniformly everywhere members go, including Identity-Aware Proxy (IAP), APIs, and console. An IAM condition attaches a level to one role grant, so different virtual machines or apps can have different policies. For VPC Service Controls (opens in a new tab), an ingress rule checks both IAM permission and whether the outside request satisfies the referenced level, while requests from inside skip ingress evaluation.

IAP TCP-forwarding for SSH acts as an intermediary between the client device and the virtual machine and performs authentication, IAM authorization, optional access-level verification, and auditing. A connection is considered inside the perimeter when the source is the external IP of a perimeter virtual machine, Private Google Access from a perimeter virtual machine, or a Private Service Connect endpoint in the perimeter. New perimeters should first run in dry-run mode, which logs violations as though enforcement were active without blocking access, so missing ingress rules, egress rules, or access levels can be fixed before enforcement.

Applying Policy Intelligence means using evidence, simulation, and troubleshooting to enforce least privilege and audit effective access. Policy Intelligence includes IAM Recommender, Policy Analyzer, Policy Simulator, and Policy Troubleshooter, which together show what access exists, what would change, and why a request was allowed or denied. Federated identities face strict limits across these tools, so sensitive reviews must use non-federated identities.

6.1Enforcing Least Privilege with IAM Recommender

IAM Recommender (opens in a new tab) is the Policy Intelligence feature that finds role bindings granting more permissions than a principal actually uses. The recommender compares permissions inside the granted role with permissions the principal actually used during an observation period, then suggests a less-privileged replacement role. The binding owner reviews the evidence and impact, applies the tighter role, and monitors for failures, because removing seasonally needed or break-glass permissions can disrupt operations.

Workforce Identity Federation users cannot view recommendations in the federated console, and federated identities cannot call the Recommender API at recommender.googleapis.com. Data does not flow from the recommender to a federated caller through either path, so least-privilege review must use a non-federated identity with the required recommender permissions.

6.2Auditing Effective Access with Policy Analyzer

Policy Analyzer is the Policy Intelligence capability that audits who has access to what across the organization, folder, and project hierarchy. Effective access is the union of direct grants on the asset plus inherited grants from ancestors, so a user with no direct binding on a bucket or dataset can still act through a higher-level role. An audit starts from the target asset, expands upward through ancestors, and maps each binding back to its principal.

An authorization path connects a principal to a permission through a role binding at a specific level. Direct paths come from the asset policy, inherited paths flow downward from parents, conditional bindings restrict paths by tags or request context, and principal access boundary policies cap what a principal can reach. Complex paths flow through custom roles, service accounts, and Google Groups, where a human holds roles/iam.serviceAccountUser to act through a service account attached to compute, and the binding names the group while the effective principal is each member.

6.3Simulating Changes and Troubleshooting Discrepancies

Policy Simulator and Policy Troubleshooter validate changes before deployment and diagnose current access. Policy Simulator replays recent access activity against a proposed allow policy and reports only attempts from the last 90 days with a different outcome. A simulation is scoped to one resource, separates roles proposed to be added from roles proposed to be removed, and returns an empty list ({}) when nothing would change. Errors such as code 12 with UNSUPPORTED_RESOURCE identify permissions like storage.objects.get or pubsub.topics.publish that the simulator could not evaluate.

Policy Troubleshooter evaluates why a principal does or does not have a permission under current allow and deny policies, including access through Google group or Cloud Identity domain membership. A result of Unknown means membership could not be resolved, not that access was granted or denied.

Managing permissions through groups means granting IAM roles to a group email once and changing access through membership instead of policy edits. A Google Group is a named collection of Google Accounts and service accounts with a unique email address, and every member inherits all IAM roles granted to that group. This structure enforces role-based access control for join, move, and leave events while keeping allow policies stable.

7.1Group Hierarchies and Inheritance Flows

A functional group hierarchy organizes groups by job responsibility so each group receives only the permissions needed for that function. Foundational groups separate organization administration from network, billing, security, logging, development, and DevOps duties, such as gcp-organization-admins, gcp-billing-admins, gcp-network-admins, gcp-security-admins, and gcp-developers. Organization-level roles apply to all contained resources and must be granted sparingly, with more than one user per remaining group for resilience.

Permission inheritance flows from the resource allow policy to the parent group to each nested group and user. An administrator adds the parent group email as a principal on an organization, folder, project, or service-specific resource, and members of a nested child group receive that access transitively. A member inherits the IAM roles regardless of their Google Groups role as owner, manager, or member, because the Groups role controls discussion and management, not authorization. Service agents cannot be added to groups unless the external members option is turned on.

7.2Assigning Roles to Groups by Job Function

Assigning roles to groups maps permissions to job responsibilities instead of individual accounts. A role granted on a container like an organization, folder, or project applies to all contained service resources, while a role granted on a service-specific resource like a Compute Engine instance or Cloud Storage bucket limits access to only that resource. Google Groups (opens in a new tab) therefore support both central visibility and granular least privilege depending on attachment level.

When sensitive data needs tighter control, broad predefined roles are replaced with fine-grained or custom roles. Deleting a group is irreversible, so all IAM roles must be revoked first and at least 7 days allowed to pass before deletion.

7.3Lifecycle, Synchronization, and Auditing

Group lifecycle covers provisioning, membership changes, safe deletion, and periodic review. The identity source determines where users originate: Cloud Identity or Google Workspace manages users centrally under a verified domain, while an external provider like Microsoft Entra ID or Okta retains users outside Google and asserts identities through a workforce identity pool. To connect an external provider, the flow moves from creating the workforce pool to configuring Google Cloud in the provider to registering the provider in Google Cloud to mapping administrative groups to assigning users.

Day-to-day access changes through membership operations, so removing a user from a group immediately removes roles that flowed only through that group. IAM Recommender identifies unused permissions with REMOVE_ROLE findings, which can be exported through BigQuery Data Transfer Service into BigQuery and visualized in Looker for enterprise review. Cloud Audit Logs provide the audit trail for both IAM policy changes and group membership changes when data sharing is enabled, while viewing groups requires roles/resourcemanager.organizationViewer and viewing membership logs requires roles/logging.viewer.

Identifying use cases for Privileged Access Manager means distinguishing standing access from temporary elevation that needs governance. Privileged Access Manager (PAM) (opens in a new tab) uses an entitlement that pre-authorizes who can elevate to which roles on which resources, and a grant that temporarily activates those privileges and then removes them automatically. After expiry, audit logs show who had access to what and when, including justification and approver.

8.1When to Choose Temporary Elevation

Standard IAM versus PAM-controlled elevation differ in persistence and governance. Standard IAM bindings grant persistent, always-on access until manually removed, which fits stable day-to-day duties under least privilege. PAM entitlements grant temporary, on-demand access that activates only after a request, optional approval, and a defined window, then expires automatically.

Choose PAM for emergency break-glass access without waiting for approval, production troubleshooting and deployments, sensitive customer-data operations, privileged database maintenance, contractor access, and remediation of excessive permissions flagged by IAM recommender. In each case traffic flows from the requester to the entitlement to a time-bound grant on the target project, folder, or organization, and the grant flows back to automatic expiry.

8.2Entitlements, Approvals, and Grant Lifetimes

A PAM entitlement is a policy object bound to an organization, folder, or project that specifies privileged roles, target resources, eligible principals, justification requirements, maximum duration, approval workflow, and scope controls. Eligible principals can include users, Google groups, contractors, service accounts, and agent identities, and a requester can only request against an entitlement they were added to. With Security Command Center Premium or Enterprise tier, requesters can customize scope to a subset using up to five resource filters and only the required roles.

Approval workflows control whether grants activate immediately or wait for review. Entitlements can require justification plus approval, allow emergency access without approval while recording justification, require multi-party approval so a second approver must concur, or require up to two sequential approval levels. Service accounts or agent identities can serve as programmatic approvers by validating ITSM tickets in DevOps pipelines, and they can also self-elevate only when an automated task needs the role.

Grant requests follow strict concurrency and deadline rules:

1. Request: Eligible principal selects entitlement, optional customized scope, duration, justification, and notification emails.
2. Approval wait: Request enters Approval awaited and must be approved or denied before it expires.
3. Activation: Approved immediate grant becomes Active, while approved scheduled grant becomes Scheduled until its activation time.
4. Expiry and removal: PAM removes the roles automatically, and requesters can withdraw early.

One user can have a maximum of 10 open grants per entitlement in Active, Scheduled, or Approval awaited state. Immediate grants must be approved within 24 hours, while scheduled grants can be scheduled up to 7 days ahead and must be approved before activation time.

8.3Layered Defense, Guardrails, and Logging

Layered defense places PAM between persistent IAM baselines and application entry controls. Cloud IAM grants minimum permanent roles with conditions and deny policies, PAM manages just-in-time elevation on top of that baseline, and Identity-Aware Proxy requires its own IAM decision with the IAP-Secured Web App User role before a protected application is reached. A user can hold an active PAM grant yet still be denied by IAP or by a deny policy.

PAM depends on its organization-level service agent to perform escalations. PAM uses only service-org-ORGANIZATION_NUMBER@gcp-sa-pam.iam.gserviceaccount.com, even for folder or project scopes, and does not create folder-level or project-level agents. Administrators must grant the Privileged Access Manager Service Agent role to that identity, add it to exceptionPrincipals in relevant deny policies, add it to VPC Service Controls access levels or ingress rules, and allow pam-noreply@google.com for notifications. Context-Aware Access adds per-request checks such as corporate network or certificate-based mutual TLS, where Chrome Enterprise Premium is user-centric and VPC Service Controls is resource-centric for all user and service account identities. Cloud Audit Logs record who requested elevation, what was granted, when it was active, justification, and approver, while ADMIN_READ, DATA_READ, and DATA_WRITE logs show resource activity during the grant window.

Key Facts

• The effective IAM allow policy for any resource is the union of its own policy plus all policies inherited from its organization, folder, and project parents, and lower-level allows only add access.
• An IAM deny policy is evaluated before allow policies, and any matching deny rule blocks the permission even if an allow policy grants it higher in the hierarchy.
• 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.
• Privileged Access Manager grants temporary elevation through entitlements and time-bound grants with justification and approval, using only the organization-level service agent that must be exempted from deny policies and perimeters.
• Policy Simulator reports only access attempts from the last 90 days with a different outcome, while Policy Troubleshooter returns Unknown when it cannot resolve group or domain membership.