knowledge base
GCP IAM — the fields that actually gate access
Demo KB note — short, reference-style. This is where the quick "how it actually works" notes live, versus long-form writeups.
IAM decisions in GCP come down to a small number of moving parts. Know these and most "who can touch this?" questions answer themselves.
The three pieces
- Members — who: users, groups, service accounts, or whole domains.
- Roles — what: a bundle of permissions (
roles/owner, custom roles, …). - Bindings — the glue: this member has this role on this resource, optionally with a condition.
Permissions worth watching
| Permission | Why it matters |
|---|---|
iam.serviceAccountKeys.create |
mints long-lived static credentials |
iam.serviceAccounts.actAs |
lets an identity become a service account |
resourcemanager.projects.setIamPolicy |
can grant itself anything |
Quick checks
# Who has what on a project
gcloud projects get-iam-policy $PROJECT --format=json
# What a role actually allows
gcloud iam roles describe roles/editor
Inheritance flows down the resource hierarchy (org → folder → project → resource), so a broad grant high up quietly applies everywhere below it.