What is CEL and why does GCP use it for IAM conditions?

CEL (Common Expression Language) is a lightweight expression language developed by Google for evaluating boolean conditions. GCP uses CEL because it is safe to execute (no side effects or loops), fast to evaluate at scale, and expressive enough to handle complex conditions involving timestamps, string matching, and nested attribute access. CEL expressions in IAM conditions are evaluated on every API request, so performance and safety are critical.

Can IAM conditions replace resource-level policies entirely?

No. IAM conditions add constraints to existing role bindings but cannot grant permissions beyond what the role allows. They are best for narrowing broad roles — for example, giving someone the Editor role but only for resources with a specific label. For fine-grained resource-level access control, you should still use individual role bindings or custom roles alongside conditions.

What happens if a CEL expression has a syntax error?

GCP validates CEL expressions when you create or update the IAM binding. If the expression is invalid, the API returns an error and the binding is not created. The builder validates your expression before generating it, so you can catch syntax issues before attempting to apply the policy via gcloud or Terraform.

GCP IAM Condition Builder

IAM & SecurityGCP

Build GCP IAM Conditions using Common Expression Language (CEL) with a guided form.

Last verified: April 2026

IAM Condition Configuration

Condition Title

Description (optional)

Condition Type

Start Time (optional)

Access begins at this time (UTC)

End Time (optional)

Access expires at this time (UTC)

Common Condition Presets

IAM Binding with Condition

Output will appear here...

About This Tool

GCP IAM Conditions allow you to grant permissions that are only effective when specific criteria are met — such as time of day, resource attributes, or request attributes. Conditions use the Common Expression Language (CEL), which has its own syntax for logical operators, string functions, and timestamp comparisons that can be tricky to write correctly. This builder provides a guided form that generates valid CEL expressions for common patterns like restricting access to specific resource types, enforcing time-based access windows, or limiting permissions to resources with certain labels.

Real-World Scenario

A contractor needs temporary Compute Engine admin access for a 2-week migration project, but only during business hours (9am-6pm EST, weekdays only). Instead of creating and revoking IAM bindings daily, you use the builder to generate a CEL expression that combines a date range (request.time >= timestamp('2026-04-07T00:00:00Z') && request.time < timestamp('2026-04-21T00:00:00Z')) with day-of-week and hour-of-day checks. Access automatically expires without any manual cleanup.

When to Use This Tool

•Creating time-bound access conditions that grant permissions only during business hours or a maintenance window
•Restricting roles to specific resource types — for example, granting compute.admin only for instances, not disks or networks
•Building conditions that limit access based on resource labels, such as allowing edits only to resources tagged environment=development
•Implementing request-level conditions that require specific API fields, like restricting instance creation to specific machine types

Pro Tips

TIP

Time-based conditions use UTC timestamps, not your local timezone. A condition like request.time < timestamp('2026-04-15T17:00:00Z') expires at 5pm UTC, which is 10am Pacific. This catches teams every time they set a maintenance window condition in their local time and wonder why access was revoked 7 hours early.

TIP

CEL expressions have a maximum length of 12,288 characters. If your condition combines many resource type checks or label comparisons, you can hit this limit. Break complex conditions into separate role bindings with simpler conditions rather than packing everything into one expression.

TIP

Not all IAM roles support conditions. Primitive roles (Owner, Editor, Viewer) and some pre-defined roles cannot have conditions applied. If the API rejects your condition, check whether the role has the iam.conditions.* permissions. Custom roles always support conditions.

How It Works Under the Hood

The builder constructs CEL expressions by combining field access paths (request.time, resource.type, resource.name, resource.labels) with comparison operators and literal values. For time-based conditions, it generates timestamp() function calls with RFC 3339 formatted strings. For resource conditions, it uses string matching functions like startsWith(), endsWith(), and matches(). The generated expression is validated against CEL grammar rules before output.

Frequently Asked Questions

What is CEL and why does GCP use it for IAM conditions?: CEL (Common Expression Language) is a lightweight expression language developed by Google for evaluating boolean conditions. GCP uses CEL because it is safe to execute (no side effects or loops), fast to evaluate at scale, and expressive enough to handle complex conditions involving timestamps, string matching, and nested attribute access. CEL expressions in IAM conditions are evaluated on every API request, so performance and safety are critical.
Can IAM conditions replace resource-level policies entirely?: No. IAM conditions add constraints to existing role bindings but cannot grant permissions beyond what the role allows. They are best for narrowing broad roles — for example, giving someone the Editor role but only for resources with a specific label. For fine-grained resource-level access control, you should still use individual role bindings or custom roles alongside conditions.
What happens if a CEL expression has a syntax error?: GCP validates CEL expressions when you create or update the IAM binding. If the expression is invalid, the API returns an error and the binding is not created. The builder validates your expression before generating it, so you can catch syntax issues before attempting to apply the policy via gcloud or Terraform.

Featured In

IAM Policy Mistakes That Get You Breached (Across All Clouds)

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.