When an IAM Condition trusts the caller: CEL bypass and Deny gaps

IAM Conditions and Deny policies are how GCP narrows access below a role. A condition that trusts an attribute the caller can set, or a Deny policy with a gap, can be walked straight through.

How the attack works

A role binding grants access only when a CEL condition holds, but the expression keys on a request-time attribute the principal can control, such as a self-asserted tag or path prefix, so they satisfy it at will. Cloud Audit Logs then show the principal performing an action the intended condition was meant to block, because the condition evaluates true. Using the bypass, the principal reads objects the restricted binding was supposed to fence off, and an existing Deny policy does not cover the exact permission and resource combination, so it never denies the action. In ATT&CK terms this is T1078.004, Valid Accounts: Cloud Accounts, with T1548, abuse of an elevation control mechanism, and T1484, Domain or Tenant Policy Modification.

Why it works

The condition trusts an input the caller can influence, and the Deny policy has a coverage gap. The request evaluates as allowed, but allowed by a flawed condition is not the same as authorized in intent.

How to fix it

Removing the principal leaves the flawed logic open to anyone else who can meet the weak condition. Rewrite the CEL to key only on trusted, server-evaluated attributes the principal cannot set, close the Deny-policy gap for that permission and resource, then verify with Policy Troubleshooter that the access is now denied. Audit every conditional binding for caller-controllable CEL and missing Deny coverage, and bake Policy Troubleshooter checks into the change process. Scope what was read from Cloud Audit Logs and Data Access logs filtered to the principal across the bypass window.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse the condition bypass, the harden-and-verify containment, and the fleet-wide CEL audit.