Most GCP security incidents are identity problems: an over-broad role, a leaked service account key, a permission nobody remembers granting. IAM is the control that matters most, and these six practices cover the ground that actually gets exploited.
1. Prefer Predefined Roles Over Primitive Ones
The primitive roles — Owner, Editor, Viewer — are enormous. Editor can modify almost everything in the project. Use the fine-grained predefined roles instead:
# Too broad --role=roles/editor # Scoped to the job --role=roles/storage.objectViewer
2. Grant to Groups, Not Individuals
Binding roles to individual users means access drifts as people join and leave. Bind to Google Groups and manage membership there, so offboarding one person removes their access everywhere at once.
3. Avoid Service Account Keys
Exported service account keys are long-lived secrets that leak into repos and images. Prefer Workload Identity (for GKE) and attached service accounts (for Compute/Cloud Run) so workloads authenticate without a downloadable key:
# GKE Workload Identity — no key file anywhere iam.gke.io/gcp-service-account: app@project.iam.gserviceaccount.com
4. Use Least Privilege for Service Accounts
A service account should hold only the roles its workload needs. The default Compute service account often has Editor — strip it down. A compromised workload inherits exactly its service account's power.
5. Set Up an Organization Policy
Organization policies enforce guardrails no project can violate — like blocking public IPs or restricting which domains can be granted access. They stop mistakes before IAM bindings are even attempted:
constraints/iam.disableServiceAccountKeyCreation: enforced
6. Review with the Policy Analyzer
Access accumulates. Use IAM Recommender and Policy Analyzer to surface unused permissions and over-grants, then trim them on a schedule:
gcloud recommender recommendations list \ --recommender=google.iam.policy.Recommender --project=my-app-prod
Summary
Secure GCP IAM comes down to scope and hygiene: use predefined roles, grant to groups, avoid downloadable keys, keep service accounts minimal, enforce org-level guardrails, and prune with the recommender. None of it is exotic — it is the steady discipline that keeps a single leaked credential from turning into a project-wide breach.