GCP IAM & Service Accounts

Identity and access management with roles, service accounts, Workload Identity, and IAM Conditions.

GCPAdvanced

Why

GCP IAM is unified across all services — roles, service accounts, and conditions. Workload Identity lets GKE pods act as service accounts (no keys).

IAM Conditions add time/resource constraints.

When

Configure IAM for every project — least privilege, service accounts for workloads, Workload Identity for GKE. Review regularly.

How

1. Roles — predefined (roles/storage.objectViewer) or custom 2. Service accounts — gcloud iam service-accounts create, for workloads 3. Workload Identity — GKE pod → SA, no keys, recommended 4. Keys — only for external systems, rotate regularly 5. IAM Conditions — time-bound, resource-bound grants 6. Policy — gcloud projects get-iam-policy, set-iam-policy 7. Org Policy — constraints (e.g., restrict regions, disable default SA) 8. IAM Recommender — suggests removing excess permissions

Example

# Create service account + grant role gcloud iam service-accounts create app-sa \ --display-name "App service account" gcloud projects add-iam-policy-binding my-project \ --member serviceAccount:app-sa@my-project.iam.gserviceaccount.com \ --role roles/storage.objectViewer # Workload Identity — GKE pod uses SA gcloud iam service-accounts add-iam-policy-binding app-sa@proj.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member serviceAccount:proj.svc.id.goog[default/my-sa] # k8s annotation metadata: { annotations: { iam.gke.io/gcp-service-account: "app-sa@proj.iam.gserviceaccount.com" } }

Common Problems

⚠Service account key leaks — use Workload Identity, avoid downloadable keys
⚠Default SA too powerful — create custom SA per workload, least privilege
⚠Policy too large — use IAM Conditions, not many individual bindings

Best Practices

✓Use Workload Identity for GKE — no keys, IAM-mapped, most secure
✓One SA per workload — least privilege, blast radius limited
✓Use IAM Recommender — auto-suggests removing unused permissions

FAQ

What is GCP IAM & Service Accounts and what problem does it solve?

Identity and access management with roles, service accounts, Workload Identity, and IAM Conditions. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with GCP IAM & Service Accounts in 5 minutes?

Two steps to run it: (1) Roles — predefined (roles/storage.objectViewer) or custom; (2) Service accounts — gcloud iam service-accounts create, for workloads. Validate on the free tier first, then wire into production.

What is the #1 pitfall with GCP IAM & Service Accounts?

The most frequent issue is: Service account key leaks — use Workload Identity, avoid downloadable keys. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for GCP IAM & Service Accounts?

Best practices for GCP IAM & Service Accounts include: Use Workload Identity for GKE — no keys, IAM-mapped, most secure; One SA per workload — least privilege, blast radius limited; Use IAM Recommender — auto-suggests removing unused permissions. The first one — "Use Workload Identity for GKE — no keys, IAM-mapped, most secure" — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with GCP IAM & Service Accounts?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most GCP IAM & Service Accounts options offer a free tier — validate within free quota before scaling.