How does GCP IAM work and what is the difference between service accounts and user accounts?

GCP IAM (Identity and Access Management) controls who can do what on which GCP resources. It uses a policy-based model with three main components: principals (who), roles (what permissions), and resources (which resources).

Key IAM Concepts

Principals: Google accounts, service accounts, Google groups, Google Workspace domains, or Cloud Identity domains.

Roles: Collections of permissions. Three types exist — Basic roles (Owner, Editor, Viewer), Predefined roles (fine-grained, service-specific), and Custom roles (user-defined).

Policies: Bindings that attach roles to principals on a resource.

Service Accounts vs User Accounts

User Accounts represent a human user (developer, admin). They authenticate with passwords and OAuth2, are managed in Google/Cloud Identity, and are used for interactive access like gcloud CLI or Console.

Service Accounts represent an application or workload (non-human). They authenticate using cryptographic keys or workload identity, are managed in GCP per project, and are used by VMs, Cloud Functions, GKE pods, etc.

Key Differences

Service accounts have no password — they use RSA key pairs or metadata server tokens. Service accounts can be impersonated by other principals (act as). GKE Workload Identity links Kubernetes service accounts to GCP service accounts, eliminating key files. Service account keys should be rotated regularly and avoided when possible — prefer Workload Identity or ADC (Application Default Credentials).

Best Practices

Apply principle of least privilege — grant minimum required permissions. Use predefined roles over basic roles. Avoid using Editor/Owner roles in production. Use Workload Identity for GKE workloads instead of key files. Audit IAM policies with Cloud Asset Inventory and IAM Recommender.