Google Cloud IAM: — Least Privilege Without Breaking Everything

① The GCP IAM model — members, roles, resources & the inheriting allow policy

Picture Sneha, an L1 cloud engineer at Flipkart. On her first day she's told "give the payments team read access to the logs." To do that safely she has to understand three nouns and one rule. The three nouns: member (who), role (what they can do), and resource (on what). The rule: those three are tied together by an allow policy that inherits downward through the resource tree. Get those four ideas and the rest of IAM is detail.

Start with members (Google's docs now call them principals; older APIs still say members). Four kinds matter on day one: a Google account (sneha@flipkart.com), a Google group (payments-readers@flipkart.com — grant to the group, not the person, so leavers lose access automatically), a service account (the robot identity your app runs as), and a workload identity (an outside workload — GitHub Actions, a Kubernetes pod — that gets short-lived GCP credentials with no key file to leak).

Next, roles. A role is a bundle of permissions, and every permission is written service.resource.verb — for example logging.logEntries.list or storage.objects.get. You grant the role, never the raw permission. A binding is one member plus one role on one resource — that's literally a line in the allow policy.

Now the rule that L1 engineers underestimate: the allow policy inherits down the hierarchy. GCP arranges everything as Organization → Folder → Project → resource. If you set roles/viewer for a group at the Organization node, that group can now view every folder, every project, every bucket beneath it — possibly hundreds of projects you've never seen. Inheritance is one-directional (downhill): a grant on a single bucket does NOT bubble up to the project. That asymmetry is the whole game — bind at the smallest scope that does the job.

gcloud projects get-iam-policy flipkart-pay-prod --format=json

{
  "bindings": [
    { "role": "roles/logging.viewer",
      "members": ["group:payments-readers@flipkart.com"] },
    { "role": "roles/owner",
      "members": ["user:sneha@flipkart.com"] }
  ],
  "etag": "BwYg7x1kQ2c=", "version": 1
}

The four nouns, one tap each

Tap each card — every IAM question on the job and the exam is built from these.

② Roles — basic, predefined & custom (and why Editor on prod hurts)

There are exactly three families of role, and picking the right family is most of least privilege. Basic roles — roles/owner, roles/editor, roles/viewer — are the oldest and the broadest. Editor alone carries thousands of permissions across nearly every service. Predefined roles are service-scoped and maintained by Google (e.g. roles/storage.objectViewer, roles/pubsub.publisher) — this is your default. Custom roles are ones you build from a hand-picked list of permissions, for when even the tightest predefined role is still too wide.

Why is Editor on a production project the classic interview red flag? Because Editor can create, modify and delete resources across the whole project — start and stop VMs, edit firewall rules, rewrite Cloud Functions, drop database instances. The trap is that Editor cannot change IAM, so people convince themselves it's "safe." It isn't: an attacker (or a buggy script) with Editor can still take down or tamper with your entire payments stack. Google's own guidance is blunt — don't grant basic roles in production unless there's genuinely no predefined alternative.

The practical workflow when someone asks for access: name the service they need (Cloud Storage? BigQuery? Pub/Sub?), name the verb (read? write? admin?), then look up the predefined role that matches — for read-only object access it's roles/storage.objectViewer, not roles/editor. Only if no predefined role fits — say they need three specific compute permissions and nothing more — do you build a custom role. The cost of custom is that you now own it: when Google adds a new permission to a service, your custom role won't pick it up automatically.

gcloud storage buckets add-iam-policy-binding gs://flipkart-pay-receipts \
  --member="group:payments-readers@flipkart.com" \
  --role="roles/storage.objectViewer"

bindings:
- members:
  - group:payments-readers@flipkart.com
  role: roles/storage.objectViewer
etag: CAE=
Updated IAM policy for bucket [gs://flipkart-pay-receipts].

③ Service accounts — the #1 GCP risk (keys, impersonation & how to cap it)

If there's one thing to remember from this lesson for the job, it's this: service-account keys are GCP's number-one IAM risk. A service-account key is a JSON file holding a long-lived private key. Whoever has the file can authenticate as that service account and inherit everything it can do. There's no password, no MFA, no expiry. So when a key lands in a public Git repo, a CI log, a Slack message, or a leaked laptop, the attacker doesn't need to break anything — they just use the file.

The fix Google now pushes hard: stop downloading keys. For workloads outside GCP (GitHub Actions, an on-prem job, an EKS pod) use Workload Identity Federation; for one identity acting as another inside GCP use impersonation to mint short-lived tokens on demand. Both replace a permanent, leakable file with credentials that expire in about an hour. If your org was created on/after 3 May 2024, GCP even blocks external key creation by default via an org policy.

Now the privilege-escalation trap that the Professional Cloud Security Engineer exam loves. Two role/permission names matter. roles/iam.serviceAccountTokenCreator grants iam.serviceAccounts.getAccessToken — meaning the holder can mint a token for the target SA and become it. actAs (from roles/iam.serviceAccountUser) lets a principal attach an SA to a new VM or function, so that resource runs as the SA. The danger: if either role is granted at the project, folder or org level, the holder can act as every current and future SA below it — and if one of those SAs is an Owner, a low-privileged user has just escalated to Owner. Worse, impersonation chains: A impersonates B impersonates C, walking up to the most powerful account.

# grant tokenCreator on ONE specific SA, to ONE group — not the project
gcloud iam service-accounts add-iam-policy-binding \
  deploy@flipkart-pay-prod.iam.gserviceaccount.com \
  --member="group:release-eng@flipkart.com" \
  --role="roles/iam.serviceAccountTokenCreator"

# now run a command AS that SA with a 1-hour token, no key file
gcloud storage ls gs://flipkart-pay-receipts \
  --impersonate-service-account=deploy@flipkart-pay-prod.iam.gserviceaccount.com

Updated IAM policy for serviceAccount [deploy@flipkart-pay-prod.iam.gserviceaccount.com].
WARNING: This command is using service account impersonation.
All API calls will be executed as [deploy@flipkart-pay-prod...].
gs://flipkart-pay-receipts/2026-06/
gs://flipkart-pay-receipts/2026-05/

④ Tightening down — Recommender, Policy Analyzer & a real investigation

You've granted access carefully — but access drifts. People change teams, projects get over-permissioned "to unblock something," and nobody walks it back. GCP gives you tooling so you don't have to audit by hand. The headliner is IAM Recommender: it compares each principal's granted permissions against what they actually used in the last 90 days and recommends a tighter role. If a service account holds Editor but only ever called a handful of compute read APIs, the Recommender will suggest swapping Editor for roles/compute.viewer.

In the Console, open IAM & Admin → IAM and watch the Analyzed permissions column. A green "Recommendation available" tick next to a principal means the Recommender has a safe trim ready — one click applies it. The column also shows exercised-vs-total permissions, so you can see at a glance who's wildly over-granted. Internally, Google found most granted permissions go unused in a 90-day window — which is exactly the slack least privilege removes.

Two more tools finish the kit. Policy Analyzer answers the two audit questions directly: who can access this bucket? and what can this principal reach? — and crucially it follows impersonation paths, so it catches the indirect access Meera found in section ③. Policy Troubleshooter answers the opposite: why was this exact call allowed or denied? — it walks the allow policy, deny policy and org-policy guardrails for you, which turns a 30-minute AccessDenied hunt into a 30-second one. And the resource hierarchy you learned in section ① is itself the control: it's your blast-radius boundary — keep prod in its own folder/project so a mistake in dev can't reach it.

# 1) WHO can access this bucket? (follows impersonation)
gcloud asset analyze-iam-policy \
  --scope=projects/flipkart-pay-prod \
  --full-resource-name="//storage.googleapis.com/flipkart-pay-receipts" \
  --permissions="storage.objects.get"

# 2) WHAT least-privilege trims does GCP suggest?
gcloud recommender recommendations list \
  --project=flipkart-pay-prod \
  --recommender=google.iam.policy.Recommender \
  --location=global

analysisResults:
- identityList: {identities: [group:payments-readers@flipkart.com]}
  accessControlList: {accesses: [{role: roles/storage.objectViewer}]}
- identityList: {identities: [serviceAccount:analytics@...]}   # via impersonation of deploy-sa
RECOMMENDATION                       PRIMARY_IMPACT  DESCRIPTION
projects/.../recommendations/abc123  SECURITY        Replace roles/editor with roles/compute.viewer