IAM & Access
Who can do what, where. Everything in GCP hangs off IAM - learn it before compute or storage, because every later topic references it. IAM grants "what you can do", never "what you are".
Start with the nouns. GCP organizes everything into a small set of IAM objects - the resource hierarchy you grant access on, plus the roles and members you grant:
The "Resources" band above is really a whole tree - the same one from Resource hierarchy, shown here so you can see how access granted high up is inherited down:
That much you know: the objects, and the hierarchy they sit in. The remaining question is how you connect them - and that takes three pieces:
- Member / principal - the identity. A Google account, service account, Google group, or Workspace / Cloud Identity domain.
- Role - a named bundle of permissions (e.g.
roles/storage.objectViewer). You never assign raw permissions directly. - Policy - the binding list attached to a resource:
{member ↔ role}pairs. This is the actual grant.
Binding = member + role. A resource's policy is just a collection of bindings, inherited down the hierarchy you just saw.
Put those together and you get the one question IAM exists to answer:
In this section
Work through the pages in order - each builds on the last.
- Roles - the three role kinds (basic, predefined, custom) and which to pick.
- Members & Policies - member types, how bindings form a policy, and allow / deny / organization policies.
- Service Accounts - identities for workloads: creation, least privilege, attaching, keys, and impersonation.
- Workload Identity & Federation - let GKE / external identities use Google service accounts, keylessly.
- IAM Best Practices - groups over individuals, least privilege, no keys.