Phase 1 · Lesson 1.2 2 of 20

IAM — identity & access management

Analogy: The bouncer and the VIP list

Now that we have our filing cabinets and manila folders set up, we have a major security problem: anyone who walks into the building can open any drawer. We need to hire a security team.

In Google Cloud, the security team is called IAM — Identity and Access Management.

Imagine a bouncer at a nightclub holding a VIP list. The bouncer only cares about answering three questions: who is trying to get in, what are they allowed to do inside, and where exactly are they allowed to do it?

The three IAM questions Three pillars representing the questions IAM asks: Who, What, and Where, all governed by the principle of least privilege. 1. Who? Identities Users, groups, robots 2. What? Roles Bundles of permissions 3. Where? Scope Org, folder, project, resource The golden rule — least privilege Give the minimum access needed to do the job — not one permission more.

👆 Click a pillar to see the architect's notes

Quick check Build the access policy

Your backend app on a Compute Engine VM needs to upload user photos to a storage bucket. Pick the identity, the role, and the scope.

Identity (the "who")
Role (the "what")
Scope (the "where")

The three pillars

The “who” — identities. Three flavors. Google Accounts are individual humans. Google Groups are collections of humans (always prefer groups — when Alice leaves the company, you remove her from one group instead of tracking down every server she had access to). Service Accounts are robots — when an app talks to a database, it uses a service account, never a human’s credentials.

The “what” — roles. You assign roles, not individual permissions. Basic roles (Owner, Editor, Viewer) are too broad — never use them in production. An Editor can edit literally everything in the project. Predefined roles are surgical: roles/storage.objectViewer only reads storage objects, nothing else. Custom roles exist for the rare case Google’s catalog isn’t specific enough.

The “where” — scope. Bindings attach at a specific level of the hierarchy from Lesson 1.1. A binding at the Project level grants the role across every resource in that project. A binding on a single bucket only works on that bucket. Lower scope means tighter blast radius.

The golden rule — least privilege

Give an identity the absolute minimum amount of access they need to do their job, and not a single permission more. If a developer only needs to read a database, you do not give them permission to write to it or delete from it.

This sounds obvious. It is also the single most violated principle in cloud security.

Architect’s note — avoid service account keys

Avoid downloaded service account JSON keys wherever possible. On Compute Engine, GKE, and Cloud Run, attach the service account to the workload directly — credentials are issued via the metadata server and rotated automatically.

Downloaded JSON keys are the #1 source of GCP credential leaks on GitHub. A whole category of breach you sidestep by using workload identity instead.

The textbook least-privilege answer for a backend app uploading photos: a service account attached to the VM, with roles/storage.objectCreator (write-only — can’t read existing photos back, can’t list, can’t delete), scoped to the single bucket. If the app gets compromised, the blast radius is exactly one bucket and the attacker can only add new objects.

That’s the answer auditors want to see at Wells Fargo, PayPal, Amex — not “Editor on the whole project, trust us.”

Next up: organization policies — the org-wide guardrails that prevent even an Owner from doing dumb things.

← Back to curriculum