IAM at scale: conditions, deny, federation

Google Cloud · Expert · 17 min

Large organizations need time-bound, attribute-based and keyless access that basic allow policies cannot express.

Beyond plain role bindings, IAM has several precision tools.

Custom roles bundle exactly the permissions you need, at org or project level. They need maintenance as services add permissions, so use them where predefined roles are clearly too broad.

IAM Conditions attach a CEL expression to a binding. Common uses: temporary access (request.time < timestamp(...)), limiting to resources by name prefix (resource.name.startsWith(...)) or by tags. Not every resource type supports every attribute, so test conditions.

Deny policies are evaluated before allow policies and win: deny specific permissions to a principal set, with exceptions, attached at org, folder or project. Use them for hard guardrails such as "nobody except the security group can create service account keys". They use the service.googleapis.com/resource.verb permission format.

Workload Identity Federation lets workloads outside Google Cloud (GitHub Actions, GitLab, AWS, Azure, Kubernetes, any OIDC or SAML IdP) exchange their own token for short-lived Google credentials. No keys. Always set an attribute condition that pins the trusted repository or account; an open provider would trust every GitHub user.

Analysis: Policy Analyzer answers "who can access X", Policy Troubleshooter explains a denial, and role recommendations remove unused permissions from over-granted principals. Privileged Access Manager provides just-in-time, approved elevation.

Example

# Temporary, conditional access that expires by itself
gcloud projects add-iam-policy-binding shop-prod-1234 \
  --member="user:contractor@example.com" --role="roles/logging.viewer" \
  --condition='expression=request.time < timestamp("2026-12-31T00:00:00Z"),title=until-2027'

# Keyless deploys from GitHub Actions
gcloud iam workload-identity-pools create github --location=global
gcloud iam workload-identity-pools providers create-oidc shop-repo --location=global \
  --workload-identity-pool=github --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository == 'example-org/shop'"

gcloud iam service-accounts add-iam-policy-binding deployer@shop-prod-1234.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/111122223333/locations/global/workloadIdentityPools/github/attribute.repository/example-org/shop"

Remember

  • Conditions add CEL constraints (time, resource name, tags) to a binding
  • Deny policies override allows; use them for hard guardrails
  • Workload Identity Federation replaces keys for external workloads; always set an attribute condition

Watch out for

  • Creating a GitHub OIDC provider without an attribute condition, letting any repository impersonate your service account if other bindings are loose.

Check yourself

  1. A user has Owner via an allow policy and a deny policy denies iam.googleapis.com/serviceAccountKeys.create to all users. Can they create a key?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: cloud.google.com/iam/docs/workload-identity-federation