Security and IAM

Master GCP IAM roles, service accounts, and identity controls to secure access to your resources.

Simple Explanation (ELI5)

IAM (Identity and Access Management) controls who can do what in GCP. Identities are users (your team), service accounts (for apps), or groups. Roles define permissions (like read, write, delete). You assign roles to identities on resources. Principle of least privilege: give people only the minimum permissions they need.

Why IAM Matters

• Security: Prevent accidental or malicious deletion of resources.
• Compliance: Audit who accessed what, when, and from where.
• Operational safety: Junior engineers can't delete production databases.
• Automation: Apps (service accounts) access only what they need.

Technical Explanation

1. IAM Roles

Bundles of permissions. Basic roles (Owner, Editor, Viewer) are broad. Predefined roles are service-specific. Custom roles allow fine-grained control.

# Grant a user the Editor role on a project
gcloud projects add-iam-policy-binding my-project \
  --member=user:alice@example.com \
  --role=roles/editor

# Grant compute.instanceAdmin on a specific instance
gcloud compute instances add-iam-policy-binding my-vm \
  --member=user:bob@example.com \
  --role=roles/compute.instanceAdmin \
  --zone=us-central1-a

# Remove a role
gcloud projects remove-iam-policy-binding my-project \
  --member=user:alice@example.com \
  --role=roles/editor

2. Service Accounts

Google-managed accounts for applications and workloads. Unlike humans, service accounts don't have passwords. They authenticate using keys or Workload Identity. Perfect for apps, CI/CD pipelines, and automation.

# Create a service account
gcloud iam service-accounts create my-app-sa \
  --display-name="Service account for my-app"

# Grant the service account a role
gcloud projects add-iam-policy-binding my-project \
  --member=serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com \
  --role=roles/storage.objectAdmin

# Create and download a key (use for local dev only)
gcloud iam service-accounts keys create ~/key.json \
  --iam-account=my-app-sa@my-project.iam.gserviceaccount.com

# List keys for a service account
gcloud iam service-accounts keys list \
  --iam-account=my-app-sa@my-project.iam.gserviceaccount.com

# Delete a key
gcloud iam service-accounts keys delete KEY_ID \
  --iam-account=my-app-sa@my-project.iam.gserviceaccount.com

3. Workload Identity (Kubernetes)

Pods in GKE authenticate as service accounts without storing keys. Each pod pod identity maps to a Kubernetes service account, which authenticates with a GCP service account token. This is the modern, secure way to deploy apps.

# Enable Workload Identity on cluster (at cluster creation time)
gcloud container clusters create my-cluster \
  --workload-pool=my-project.svc.id.goog

# Create Kubernetes service account
kubectl create serviceaccount my-ksa -n default

# Create GCP service account
gcloud iam service-accounts create my-gcp-sa

# Bind Kubernetes SA to GCP SA
gcloud iam service-accounts add-iam-policy-binding my-gcp-sa@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[default/my-ksa]"

# Annotate Kubernetes SERVICE account
kubectl annotate serviceaccount my-ksa \
  --namespace default \
  iam.gke.io/gcp-service-account=my-gcp-sa@my-project.iam.gserviceaccount.com

4. Audit & Logging

Cloud Audit Logs capture who did what, when, and from where. Admin Activity logs (all API calls) are free. Data Access logs (read/write to resources) and System Events are optional and chargeable. Always enable audit logs in production.

# Enable audit logging on a project
gcloud projects add-iam-policy-binding my-project \
  --member=serviceAccount:my-app-sa@my-project.iam.gserviceaccount.com \
  --role=roles/logging.viewer

# Query audit logs (using Cloud Logging)
gcloud logging read 'resource.type="gce_instance"' --limit 10 --format json

# Filter for IAM changes
gcloud logging read 'protoPayload.methodName:"SetIamPolicy"' --limit 5

IAM Best Practices

GCP vs AWS vs Azure IAM

Interview Questions

Real-world Scenarios

Scenario 1: Multi-team Project Structure

Your startup has data, backend, and mobile teams. Each team needs different permissions:

• Data team: BigQuery, Cloud Storage, Dataflow (data processing).
• Backend team: Compute Engine, Cloud SQL, Cloud Run (app hosting).
• Mobile team: Cloud Storage (for assets), Firebase (app backend).

Solution: Create three service accounts (or Google Groups for humans). Assign each the minimal roles needed. Each team's CI/CD pipeline uses its own service account. Audit logs show which team deployed what.

Scenario 2: Production vs Staging Access

You don't want engineers to delete production databases by mistake. Use separate projects: my-app-prod and my-app-staging. Grant engineers Editor on staging only. For production, require approval before access (using Cloud IAM Conditions or manual approval process).

Scenario 3: Contractor with Limited Access

A contractor needs to audit Cloud Storage buckets but can't delete anything. Grant storage.objectViewer role on the specific bucket only. When the contract ends, delete the IAM binding. Audit logs will show exactly what they accessed.

Summary

IAM is foundational to GCP security. Master these concepts:

• Roles bundle permissions. Assign roles to identities (users, service accounts, groups).
• Service accounts are for apps. Use Workload Identity in Kubernetes for modern, secure authentication.
• Always follow least privilege. Use Google Groups to scale access management.
• Enable Cloud Audit Logs. Review who accessed what regularly.
• In interviews, talk about principle of least privilege, best practices for key rotation, and real-world access control patterns.