Identity & Access Management (IAM)Identity & Access Management (IAM)

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Overview

Cloud IAM answers one question for every API call: who can do what on which resource? In GCP that decomposes into three parts — a member (the who), a role that bundles permissions (the what), and a resource the binding is attached to (the which). A binding of (member, role) on a resource is an allow policy (formerly “IAM policy”).

The defining feature of GCP IAM is hierarchical inheritance: a policy set on the Organization or a Folder flows down to every project and resource beneath it, and the effective policy at any node is the union of its own bindings and all inherited ones. There is no “deny by inheritance by default” — grants accumulate downward. This makes the resource hierarchy (from the Overview page) the backbone of your entire access model, so get it right early.

Fundamentals

Members (principals)

A member is any identity that can be granted a role. The prefix in the member string tells IAM what kind it is:

Prefer granting roles to groups, not individuals — you then manage access by changing group membership in your identity provider, which is auditable and survives people joining/leaving.

Roles

A role is a named collection of permissions. Permissions themselves (e.g. compute.instances.start) are never granted directly — always via a role. There are three tiers:

Rule of thumb: start from the closest predefined role. Reach for a custom role only when a predefined one is too broad, and reserve basic roles for tiny sandbox projects (or never).

Allow policies & bindings

An allow policy attached to a resource is a list of bindings. Each binding ties one role to a set of members, optionally with a condition:

{
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "group:analysts@example.com",
        "serviceAccount:etl@payments-prod.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": ["group:sre@example.com"],
      "condition": {
        "title": "prod-only",
        "expression": "resource.name.startsWith('projects/payments-prod')"
      }
    }
  ],
  "etag": "BwY...",
  "version": 3
}

The etag provides optimistic concurrency (read-modify-write safely). version: 3 is required whenever conditions are present.

Inheritance down the hierarchy

The effective policy on a resource is the union of bindings set directly on it plus every binding inherited from its project, folders, and organization:

A member of security-admins gets its role on everything; payments-dev gets run.developer on that project only. Because grants only ever add permissions downward, IAM is deliberately permissive by design — the guardrails that can actually forbid things are Organization Policies and IAM Conditions / deny policies, not plain allow bindings.

Key Concepts

Service accounts

A service account (SA) is a special identity for non-human workloads. It is both an identity (it can be granted roles) and a resource (people/SAs can be granted roles on it, like the right to impersonate it). Three types:

• User-managed SAs — you create them per workload (recommended).
• Default SAs — auto-created (e.g. the Compute Engine default SA). These are over-privileged (Editor) by default; disable or replace them.
• Google-managed service agents — used by Google services to act on your resources; you generally don’t touch these.

Keys vs keyless — this is the single most important IAM decision.

Impersonation example (run a command as a deploy SA, no key file):

gcloud storage ls gs://payments-artifacts \
  --impersonate-service-account=deployer@payments-prod.iam.gserviceaccount.com

Workload Identity for GKE maps a Kubernetes service account (KSA) to a Google service account (GSA) so pods get tokens with no mounted key:

gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@payments-prod.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:payments-prod.svc.id.goog[prod-ns/my-ksa]"
# then annotate the KSA:  iam.gke.io/gcp-service-account=my-gsa@payments-prod.iam.gserviceaccount.com

WIF for GitHub Actions — let a GitHub workflow authenticate with no stored secret, restricted to a specific repo:

# 1. Create a workload identity pool + OIDC provider for GitHub
gcloud iam workload-identity-pools create github-pool \
  --location=global --display-name="GitHub Actions"

gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location=global --workload-identity-pool=github-pool \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository=='my-org/my-repo'"

# 2. Let identities from that repo impersonate the deploy SA
gcloud iam service-accounts add-iam-policy-binding \
  deployer@payments-prod.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

The attribute-condition is critical — without pinning repository (or the branch/ref), any GitHub repo could exchange a token for your SA.

Example: granting a role with gcloud

# Grant a group a predefined role on a project
gcloud projects add-iam-policy-binding payments-prod \
  --member="group:payments-dev@example.com" \
  --role="roles/run.developer"

# Grant on a single resource (bucket) instead of the whole project
gcloud storage buckets add-iam-policy-binding gs://payments-artifacts \
  --member="serviceAccount:etl@payments-prod.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Inspect who has access
gcloud projects get-iam-policy payments-prod --format=json

IAM Conditions

Conditions add attribute-based rules on top of a binding using CEL (Common Expression Language). Common uses:

• Time-bound access: request.time < timestamp('2026-12-31T00:00:00Z')
• Resource-name scoping: resource.name.startsWith('projects/_/buckets/logs-')
• Restrict to a resource type: resource.type == 'storage.googleapis.com/Bucket'

Conditions turn a broad role into a narrow, context-aware grant without inventing a custom role.

IAM deny policies

Allow policies only add access. Deny policies attach denial rules that are evaluated before allows and override them — the way to say “no one except X may ever do Y”, even if some inherited binding grants it. Use them for hard guardrails (e.g. deny iam.serviceAccountKeys.create org-wide).

Organization Policies vs IAM

Keep the two straight:

Org policies are the compliance guardrails (see Overview); IAM is the day-to-day access model.

IAM Recommender & least privilege

The IAM Recommender (part of Policy Intelligence) analyzes 90 days of actual usage and recommends removing unused permissions or swapping a broad role for a tighter one. Policy Analyzer answers “who can access this resource?” and “what can this member access?”. Together they let you drive toward least privilege with evidence rather than guesswork.

Best Practices

1. Grant to groups, not individuals. Manage access by group membership in your IdP — auditable, and it survives joiners/leavers without policy edits.
2. Prefer predefined roles over basic roles. Owner/Editor/Viewer are far too broad; predefined roles are curated and least-privilege by design.
3. Never download service account keys. Use attached SAs, impersonation, or Workload Identity Federation. Enforce with iam.disableServiceAccountKeyCreation. Leaked keys are the top GCP breach vector.
4. One dedicated SA per workload. Don’t share SAs across apps; a compromise should be contained to that one workload’s narrow permissions.
5. Disable or de-privilege default service accounts. The Compute Engine default SA gets Editor — replace it with a least-privilege user-managed SA.
6. Use Workload Identity Federation for CI/CD and external clouds. GitHub Actions, GitLab, and AWS workloads should exchange their native identity for short-lived GCP tokens — no secrets stored anywhere.
7. Always pin WIF attribute conditions to a specific repo/branch/subject. An unpinned pool provider is effectively a public door into your project.
8. Grant at the lowest effective node. Bind on the project or resource, not the org/folder, unless the access genuinely needs to be that broad — inheritance makes high grants very wide.
9. Use IAM Conditions for time-boxed and scoped access. Elevate access for a window, or scope a role to a resource-name prefix, instead of a permanent broad grant.
10. Use deny policies for hard “never” rules. Codify non-negotiables (no key creation, no deletion of audit sinks) so no inherited allow can override them.
11. Run the IAM Recommender regularly and remove unused grants. Drive to least privilege with usage evidence; stale broad grants are silent risk.
12. Separate duties across environments. Different groups/SAs for dev/staging/prod; no single human identity should hold prod admin by default.
13. Reserve Owner for break-glass only. Keep it out of daily workflows; log and alert whenever it is used.
14. Enable Cloud Audit Logs (Admin Activity + Data Access) and monitor IAM changes. Alert on new key creation, role grants at org/folder level, and setIamPolicy calls.
15. Manage IAM as code (Terraform). Prefer authoritative-but-scoped resources like google_project_iam_member over _policy to avoid accidentally wiping bindings you don’t manage; review every change in PRs.

References

• IAM overview
• IAM roles and permissions
• Understanding allow policies
• Policy inheritance & resource hierarchy
• Service accounts overview
• Best practices for using service accounts
• Workload Identity Federation
• WIF with deployment pipelines (GitHub Actions)
• GKE Workload Identity
• IAM Conditions overview
• IAM deny policies
• IAM Recommender / Policy Intelligence
• Organization Policy Service
• google-github-actions/auth