IAM - Identity and Access Management

What is Google Cloud IAM (Identity and Access Management)?

GCP IAM (Identity and Access Management) controls who can do what on which GCP resources. The model: principal + role + resource. A principal is granted a role that contains permissions, scoped to a specific resource.

Resource Hierarchy

GCP enforces a hierarchy: Organisation -> Folders -> Projects -> Resources.

IAM policies are inherited downward - a role granted at the organisation level applies to all projects inside it. A role granted at the project level applies to all resources in that project.

Organisation: archready.io
  └── Folder: Production
        └── Project: archready-prod
              └── Cloud SQL instance
              └── GCS bucket

This inheritance is a critical design consideration - be careful what you grant at higher levels.

Principals

Principal Type	Description
Google Account	Human user (user:alice@gmail.com)
Service Account	Machine identity for applications and VMs
Google Group	Group of accounts - manage access at group level
Workspace Domain	All accounts in a Google Workspace domain
allAuthenticatedUsers	Any authenticated Google account (avoid)
allUsers	Anyone, including unauthenticated (use only for public resources)

Roles

Basic Roles (avoid in production)

• roles/viewer, roles/editor, roles/owner - overly broad, legacy

Predefined Roles

Fine-grained roles for specific services: roles/storage.objectViewer, roles/cloudsql.client, roles/container.developer. Use these.

Custom Roles

Create a role with exactly the permissions you need. Use for least-privilege when no predefined role fits.

Service Accounts

Service accounts are the GCP equivalent of AWS IAM roles - machine identities for VMs, Cloud Run services, Cloud Functions.

• A Compute Engine VM can be assigned a service account - the metadata server issues short-lived access tokens automatically.
• Cloud Run services and Cloud Functions each have a service account - grant only the permissions those services need.
• Service account impersonation: a principal can be granted roles/iam.serviceAccountTokenCreator to generate tokens as a service account - useful for cross-project access patterns.
• Do not create service account keys unless absolutely necessary. Keys are long-lived credentials that can leak. Use workload identity instead.

Workload Identity Federation

Allows external identities (GitHub Actions, AWS IAM roles, on-premises SAML) to impersonate GCP service accounts without key files. The external system exchanges its token for a short-lived GCP token via the Security Token Service (STS).

For GKE: Workload Identity binds a Kubernetes service account to a GCP service account - pods get GCP credentials automatically.

Policy Binding Structure

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": ["serviceAccount:api@archready-prod.iam.gserviceaccount.com"]
    }
  ]
}

IAM Conditions

Add conditions to bindings for attribute-based access control:

• Time-bound access: grant access only during business hours
• Resource-based: grant access only to resources with specific tags
• IP-based: restrict access to specific IP ranges

Audit Logs

Cloud Audit Logs record who did what, when:

• Admin Activity logs: always on, free - records config changes
• Data Access logs: optional, billed - records data reads/writes (turn on for PCI/HIPAA)

Interview Angle

GCP IAM questions focus on the hierarchy (inheritance - be precise about what level you grant roles), service accounts over key files (workload identity for GKE, metadata server for VMs), and least privilege via predefined or custom roles. Mention audit logs for compliance. Key GCP advantage: Workload Identity Federation eliminates service account keys for CI/CD pipelines.

How does this compare to the other clouds?

See the side-by-side comparison: AWS IAM vs Azure Entra ID vs Google Cloud IAM.