IAM Conditions and Deny Policies for Identities

Scoped authorization in Google Cloud means granting only the intended identities access to only the intended resources under only the intended conditions. Identity and Access Management (IAM) (opens in a new tab) allow policies grant permissions, while IAM Conditions, IAM deny policies, principal access boundary (PAB) (opens in a new tab) policies, and Organization Policy Service constraints narrow that access. Native identities authenticate directly inside Cloud Identity, while external humans and workloads enter through Workforce Identity Federation (opens in a new tab) and Workload Identity Federation with different principal identifiers that must be scoped separately.

1.1Native Identities and Least-Privilege 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 newly created default service account is automatically granted the Editor role (roles/editor) on its project unless the constraints/iam.automaticIamGrantsForDefaultServiceAccounts constraint is set to False. That automatic grant means compromise of one workload can lead to control of the entire project, so the constraint forces deliberate grants with minimal necessary permissions. Least privilege favors job-function predefined roles or custom roles derived from them rather than broad basic roles such as Editor.

Long-lived service account keys expand risk across hybrid environments because stolen keys can be used from outside Google Cloud. The organization enforces constraints/iam.disableServiceAccountKeyCreation set to True and constraints/iam.disableServiceAccountKeyUpload to block creation and upload of user-managed keys in affected projects. When keys cannot be eliminated, constraints/iam.serviceAccountKeyExpiryHours limits rotation to less than or equal to 2160 hours, which is 90 days. Teams are directed to use Workload Identity Federation with short-lived tokens instead of keys wherever possible.

Group and domain sprawl is controlled by preventing external members in Google Groups and by consolidating unmanaged consumer accounts that bypass joiner-mover-leaver processes. Domain restricted sharing (iam.allowedPolicyMemberDomains) or iam.managed.allowedPolicyMembers limits IAM policies so only specified Cloud Identity or Google Workspace customer IDs can be added. These controls keep group membership aligned with employment status and prevent an external identity from entering an allow policy through a group.

1.2Federated Identities Through Workforce and Workload Identity Federation

Workforce Identity Federation federates a Google Cloud organization with an external identity provider (IdP) using Security Assertion Markup Language (SAML) 2.0 or OpenID Connect (OIDC) to enable single sign-on without duplicating users in Cloud Identity. A workforce identity pool is an organization-level resource that defines a namespace for principal identifiers and serves as the container for provider configuration. The pool does not store users or groups like a directory. A single user is addressed as principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT, while a set of users is addressed as principalSet://.../group/GROUP_ID or by mapped attributes such as principalSet://.../attribute.group/security-engineers.

Workload Identity Federation lets workloads running outside Google Cloud, including CI/CD systems and other clouds, authenticate without service account keys. The external workload exchanges its short-lived external OIDC token through Security Token Service for temporary Google access tokens that expire in minutes. Access is granted directly to the federated principalSet:// identifier on the target resource, filtered by custom mapped attributes from the external token. Both federation types depend on attribute mappings that translate IdP claims into Google attributes such as google.subject and google.groups, and on attribute conditions that reject tokens from unauthorized tenants, repositories, or accounts.

Attribute conditions prevent multi-tenant forgery and cross-organization impersonation by accepting only expected issuers, audiences, and subjects. For Microsoft Entra ID, the group identifier should be the Object ID (oid) because it is present on all groups, unique, and immutable. Email is optional and display name can change or duplicate, so neither is safe as the primary group identifier for authorization.

1.3Conditional Role Bindings for Resource-Scoped Access

An IAM Conditions binding is an allow-policy binding that grants a role only when its Common Expression Language (CEL) expression evaluates to true at access time. Resource-based conditions use resource attributes for resource name, type, and service to limit a permission to resources whose names match a prefix or pattern. A common pattern limits Compute Engine access to virtual machines whose names share a prefix for a specific purpose. The resource-name attribute supports Compute Engine, Cloud Storage, BigQuery, Cloud SQL, Secret Manager, Spanner, Cloud Key Management Service, and Google Kubernetes Engine, and the same project-level approach can be adapted to any resource type that accepts IAM allow policies.

Resource Manager tags provide a second scoping axis by annotating resources so policies can conditionally allow or deny based on tag presence across the resource hierarchy. Managing these bindings requires resourcemanager.projects.getIamPolicy and resourcemanager.projects.setIamPolicy on projects, the equivalent folders.getIamPolicy and folders.setIamPolicy on folders, or broad administration through Project IAM Admin (roles/resourcemanager.projectIamAdmin), Folder Admin, Organization Admin, or Security Admin (roles/iam.securityAdmin).

1.4Deny Policies, Boundaries, and Federation Partitioning

Access is evaluated at request time against all policies attached to the resource, not at authentication time. Allow policies in IAM grant permissions to principals or principal sets, deny policies explicitly block permissions regardless of allows, and principal access boundary policies bound by iam.googleapis.com/PrincipalAccessBoundaryPolicy limit what a compromised principal can reach. The boundary reduces phishing and data exfiltration blast radius by capping the resources a principal can access even when allow policies are broader.

Group governance determines which policy layer stays least-privilege as the environment scales:

Federation scope is further contained by partitioning Cloud Identity and Workforce Identity Federation usage by service rather than by user. Each service grants access to one principal family so administration stays consistent. Custom organization policy constraints using MemberTypeMatches enforce that partitioning by allowing only iam.googleapis.com/WorkforcePoolPrincipal and iam.googleapis.com/WorkforcePoolPrincipalSet in Gemini Enterprise projects while blocking those types elsewhere. The wildcard identifier principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/* matches every user the IdP can authenticate and must never be granted roles, because growth in the IdP directly becomes over-permissioning.

Privilege escalation across hybrid identity is prevented by keeping emergency-access and highly-privileged users in Cloud Identity even when other users federate. Emergency users are created in Cloud Identity, excluded from single sign-on, and secured with password plus security-key two-step verification so IdP misconfiguration, outage, or compromise cannot lock out recovery. Highly-privileged users such as Organization Administrator (roles/resourcemanager.organizationAdmin) and Security Admin stay in Cloud Identity with security keys and additional single sign-on verifications. Workforce sessions that permit console use, Identity-Aware Proxy web applications, and federated refresh and access tokens must expire at least daily, and pools using just-in-time groups need even shorter sessions because activation and expiration do not take effect until re-authentication or SCIM provisioning completes.

Identity and Access Management (IAM) (opens in a new tab) deny policies are guardrails that prevent specific principals from using specific permissions on Google Cloud resources, regardless of the roles granted to them. A deny policy (opens in a new tab) contains one or more deny rules, and each deny rule names denied principals, denied permissions, and optional exceptions and conditions that narrow when the denial applies.

2.1How Deny Evaluation Overrides Allow Grants

Deny evaluation is the enforcement order in which IAM checks all relevant deny policies before checking relevant allow policies for a 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 principal cannot perform the action even if an allow policy grants a role containing that permission at the same level or higher in the hierarchy.

Each deny policy attached to the resource hierarchy is evaluated independently of all other deny policies, so a single matching deny rule in any policy is enough to block access. A resource can have up to 500 deny policies attached, with a combined total of up to 500 deny rules across those policies. Access changes from deny policies are eventually consistent and generally take effect within 2 minutes, although in some cases propagation can take 7 minutes or more.

2.2Attachment Points and Inheritance Across the Hierarchy

An attachment point is the organization, folder, or project resource to which a deny policy is directly attached and from which enforcement flows downward. When a deny policy is attached to an organization, folder, or project, the denial applies to that resource and to all of its descendants, including child folders, child projects, and service-specific resources inside those projects. A deny at the organization level therefore blocks the permission in every folder and project under that organization unless an exception principal or exception permission removes a specific principal or permission from the denial.

Attachment points use Cloud Resource Manager identifiers, URL-encoded for the REST API, that name the exact scope of enforcement:

Multiple deny policies can be attached to the same resource to separate concerns, such as placing compliance-related deny rules in one policy and operational deny rules in another. Because inheritance flows only downward, a policy attached to a lower-level project like example-prod does not affect its parent folder or sibling projects, while a policy attached higher affects everything below it.

2.3Structure of a Deny Rule: Principals, Permissions, and Exceptions

A deny rule is the unit inside a deny policy that binds a set of principals to a set of denied permissions, with optional exceptions that carve principals or permissions back out. The deny policy also carries metadata that identifies and versions the policy, including name in the form policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, uid, kind set to DenyPolicy, optional displayName, etag for concurrent-update protection, createTime, and updateTime.

The principal fields control who the rule targets. deniedPrincipals lists individual principals such as user accounts, service accounts, and single workforce or workload identities, and sets of principals such as Google groups, Cloud Identity domains, workforce or workload identity sets, and all users on the internet as principalSet://goog/public:all. exceptionPrincipals lists principals exempt from the denial even if they match deniedPrincipals directly or through group or set membership, such as a break-glass admin group inside a denied public:all set. Deleted principals whose IDs begin with deleted: cannot be used in deny rules, and email aliases are normalized to the user's primary email address.

The permission fields control what is blocked and use the IAM v2 format SERVICE_FQDN/RESOURCE.ACTION, where Google APIs use *.googleapis.com, for example iam.googleapis.com/roles.delete or cloudresourcemanager.googleapis.com/projects.delete. Only permissions supported in deny policies can be denied, and permission groups can deny sets of permissions at once. The deniedPermissions field names the blocked permissions, while the optional exceptionPermissions field names permissions that remain usable even when included in deniedPermissions or in a denied permission group.

When deniedPrincipals includes a broad set such as principalSet://goog/public:all, the rule depends on service agents to keep Google Cloud services functioning, so the design should add the project, folder, or organization service agent principal set to exceptionPrincipals. Without that exception, automated service agents that fall inside the broad denial could lose permissions their managed services depend on.

2.4Denial Conditions and Permission Groups

A denial condition is an optional Common Expression Language (CEL) expression that limits when a deny rule applies based on resource tags. If the expression evaluates to true or cannot be evaluated, the permission is denied; if the expression evaluates to false, the permission is not denied and allow policies decide access. Denial conditions must be based on resource tags, such as resource.matchTag('12345678/env', 'prod'), and other functions and operators are not supported.

Permission groups let a single deny rule block a related set of permissions without listing each permission individually, and exceptionPermissions then restores narrow slices inside that group. For example, a rule can deny cloudresourcemanager.googleapis.com/folders.* to everyone except principalSet://goog/group/project-admins@example.com, while exceptionPermissions keeps folders.list and folders.get usable. The dependency flows from the permission group to the exception list: the group defines the broad boundary, and the exception defines the precise hole in that boundary.

2.5Common Designs: Centralized Administration and Scoped Exceptions

Centralized administration uses an organization-level deny policy to reserve sensitive actions for one team while leaving broad allow grants in place. A deny rule denies iam.googleapis.com/roles.create, roles.delete, and roles.update to principalSet://goog/public:all with exceptionPrincipals set to principalSet://goog/group/custom-role-admins@example.com, and the policy is attached to the organization. Even if both Yuri and Tal hold roles/iam.organizationRoleAdmin, only Yuri, who belongs to custom-role-admins, can create, delete, or update custom roles, because Tal matches the denied set without an exception.

Scoped exceptions use a lower-level deny policy to subtract inherited allow grants from one child without re-granting roles everywhere else. The eng group holds roles/iam.serviceAccountKeyAdmin on the Engineering folder, but a deny policy attached to the example-prod project denies iam.googleapis.com/serviceAccountKeys.create and serviceAccountKeys.delete to principalSet://goog/group/eng@example.com. Members of eng can therefore create and delete service account keys in sibling projects like example-dev and example-test, but not in example-prod, because the project-level denial overrides the folder-level allow grant only inside that project. A further exceptionPrincipals entry for eng-prod can then re-enable the blocked permissions for that subset inside example-prod without changing the folder grant.

Identity and Access Management (IAM) (opens in a new tab) Conditions are attribute-based controls that attach a Common Expression Language (CEL) expression to a role binding in an allow policy. The role binding grants permissions only when the expression evaluates to true for that specific request, so the same principal may be authorized at one time or location and unauthorized at another. IAM policy evaluation checks the principal, the target resource, and the request context against the condition before allowing the action.

3.1Condition Attributes for Resource and Request Context

Condition attributes in IAM Conditions describe the resource being accessed and the context of the request. Resource attributes evaluate the service, type, or name of the target resource and are typically used to narrow a broad role binding to only matching resources. Request attributes evaluate details about the incoming request and allow the binding to depend on when, where, and how access is attempted.

Request attributes depend on signals outside the IAM binding itself. The access level signal is produced by Access Context Manager (opens in a new tab), which defines conditions such as membership on the corporate network, while time and network signals come from request metadata. The IAM Condition then references those signals in CEL, so the workflow depends on Access Context Manager for context and on IAM for enforcement.

3.2Common Expression Language Expressions for Temporal and Context-Aware Limits

A CEL condition in a role binding contains a title, a description, and an expression string that must return true for access to apply. The expression uses typed attributes such as request.time and functions such as timestamp() to compare the current request against policy intent. A temporal condition assigns temporary access by bounding the grant in time:

"condition": {
  "title": "Expires_December_1_2023",
  "description": "Expires on December 1, 2023",
  "expression": "request.time < timestamp('2023-12-01T00:00:00.000Z')"
}

In this example, the binding that grants roles/datastore.user to user:travis@example.com applies only when request time is before the specified timestamp. After that time the expression evaluates to false and that binding no longer contributes permissions, which supports just-in-time and expiring access patterns. Conditional bindings can be created through three interfaces:

• REST API for programmatic policy updates that include a condition block
• gcloud command-line tool with --condition for add-iam-policy-binding operations
• IAM page in the Google Cloud console for adding a condition during role grant

The choice of interface does not change evaluation behavior, but automation favors the API and gcloud when many bindings share the same temporal logic.

3.3Inherited Conditions from Container Resources

Inherited conditions are conditions attached to a container resource that flow down to the resources contained within it. Many services do not support attaching a conditional binding directly to the service-specific resource, including Sensitive Data Protection (opens in a new tab), Workload Manager (opens in a new tab), Model Armor, and App Topology (opens in a new tab). For those services, the conditional grant must be attached to a project, folder, or organization allow policy, and the condition is then inherited by the child resources in that container. Support for which resource and request attributes can be inherited varies by service, so the attribute reference for IAM Conditions must be checked for each service before relying on inheritance.

3.4Service-Specific Conditions for Load Balancing Operations

Service-specific conditions use product-provided CEL functions to inspect operation details that generic resource and request attributes cannot express. For Compute Engine forwarding rules, the functions compute.isForwardingRuleCreationOperation() and compute.matchLoadBalancingSchemes() distinguish creation of new load balancers from management of existing ones and distinguish internal from external schemes. The following expression permits a request only when it is not a forwarding-rule creation, or when it creates a rule with an internal scheme:

!compute.isForwardingRuleCreationOperation() || (
  compute.isForwardingRuleCreationOperation() &&
  compute.matchLoadBalancingSchemes(['INTERNAL', 'INTERNAL_MANAGED'])
)

Because EXTERNAL is omitted from the scheme list, a principal with this condition can create internal load balancers and can manage, modify, and delete any existing load balancer, but receives a permissions error when attempting to create an external forwarding rule. The same pattern restricts the GKE service account service-PROJECT_ID@container-engine-robot.iam.gserviceaccount.com with role roles/container.serviceAgent to creating only new internal forwarding rules while retaining management of existing rules. Without that grant, creating a GKE Service of type LoadBalancer without an internal annotation, or creating an Ingress that requires an external Application Load Balancer, fails with a 403 error for compute.forwardingRules.create.

Key Facts

• IAM deny policies are evaluated before IAM allow policies, and any matching deny rule blocks the permission even if an allow policy grants it at the same level or higher.
• A resource can have up to 500 IAM deny policies attached with a combined total of up to 500 deny rules, and deny changes generally take effect within 2 minutes.
• IAM denial conditions must be based on resource tags, and a condition that evaluates to true or cannot be evaluated denies access while only a false condition allows the allow policy to decide.
• An IAM Conditions binding grants a role only when its Common Expression Language expression evaluates to true, and a conditional binding never removes access granted by an unconditional binding.
• Workload Identity Federation exchanges short-lived external OIDC tokens for temporary Google access tokens, while Workforce Identity Federation federates an external identity provider with a workforce identity pool without duplicating users in Cloud Identity.