Courses GCP securityIAM & resource hierarchy

IAM, conditions & deny policies

Additive allows, conditions, and enforceable denies.

Advanced35 min · lesson 2 of 15

GCP IAM is deceptively simple — bindings of principals to roles on resources — but the details that matter for security are the role granularity, how policies compose across the hierarchy, and the newer deny policies that let you write true guardrails.

Roles, conditions, and least privilege

Avoid the basic roles (Owner/Editor/Viewer) — Editor alone can modify almost everything. Prefer predefined roles, which Google keeps current as APIs evolve, and reach for custom roles only when no predefined role fits (accepting that you must maintain them). IAM Conditions tighten a grant further: access only to resources with a name prefix, only from a corporate network, or only during a change window. Bind roles to Google Groups rather than individuals so membership changes in your IdP flow through without editing IAM.

a conditional, least-privilege binding

# Grant object read ONLY on buckets whose name starts with "reports-",
# and only to the analytics group — not project-wide storage access.
gcloud projects add-iam-policy-binding payments-prod \
  --member="group:[email protected]" \
  --role="roles/storage.objectViewer" \
  --condition='expression=resource.name.startsWith("projects/_/buckets/reports-"),title=reports-only'

How policies compose — and deny policies

Allow policies are additive and inherited down the hierarchy: a principal’s effective access is the union of every binding from the organization down to the resource. There is no allow-override — only accumulation — which is why a stray Editor binding at a folder is dangerous. IAM deny policies close that gap: they are evaluated before allows and block matching principals from named permissions regardless of any grant, giving you an enforceable "nobody outside break-glass may delete logs" rule.

Effective access resolution

1deny policies

checked first — matching permission blocked

2union of allow bindings

org + folder + project + resource

3IAM conditions

refine per binding

4effective access

what the principal can actually do

Allows accumulate down the tree; a deny policy overrides them. Audit inherited bindings — access can come from a level you are not looking at.

Inherited Editor is a silent over-grant

Because allow policies accumulate, a broad role granted high in the hierarchy quietly applies to every project below. Use Policy Analyzer to answer "who can actually access this resource, and via which binding?" — the grant is often inherited from a folder or the org, not the project you are inspecting.

Resource hierarchy & org policyService accounts & impersonation