How GCP IAM Is Different
If you've come from AWS, GCP's IAM model has a few specific traps:
- Roles bind to principals, not to resources. You can't write a resource policy on a Cloud Storage bucket the way you'd write an S3 bucket policy. Permissions live at project / folder / org levels.
- Predefined roles are huge.
roles/editorgrants thousands of permissions across hundreds of services. It's almost never what you actually want. - Service accounts are first-class identities — and historically, their keys were the most-leaked GCP credential type.
Doing Least Privilege Without Pain
The right tooling makes least privilege achievable:
- IAM Recommender — surfaces unused permissions and suggests narrower roles based on observed usage. Run it monthly.
- Custom roles — only when no predefined role fits. Predefined roles are maintained by Google as services evolve; custom roles aren't.
- Conditional IAM — bind roles only when conditions match (e.g. specific resource names, request times, or attribute tags).
- VPC Service Controls — service-perimeter boundaries that block data exfiltration even if IAM is misconfigured. Worth the configuration effort for sensitive datasets.
Workload Identity Federation: Stop Issuing Static Keys
The single highest-impact security improvement in any GCP environment is retiring service account JSON keys. They're long-lived, easy to leak, and the most common compromised-credential type for GCP.
The replacement is Workload Identity Federation — short-lived OIDC tokens minted on demand:
- From AWS, Azure, on-prem — the workload's existing identity (IAM role, managed identity, OIDC token) is exchanged for a Google access token.
- From GitHub Actions — GitHub's OIDC token authenticates to GCP. No
GOOGLE_APPLICATION_CREDENTIALSin repository secrets. - From Kubernetes — Workload Identity for GKE binds K8s service accounts to GCP service accounts.