What is Identity & Access — Cloud IAM in Google Cloud?

7 / 24

Google Cloud

Identity & Access — Cloud IAM

Grant least-privilege roles to members across a project/folder/organization hierarchy.

IAM answers who may do what, on which resource, through a hierarchy that inherits downward.

A franchise org chart: a permission granted to a regional manager (folder) automatically applies to every store (project) under them. Robots on staff carry job-specific badges (service accounts), and instead of permanent keys they get temporary passes issued on the spot (Workload Identity), so nothing reusable is ever left lying around.

Key Concepts

    Organization -> Folder -> Project -> Resource

A policy set high applies to everything beneath it, which is why granting Editor at the organisation to "unblock" someone is so damaging.

A binding is three parts.

    member   user, group, service account, or a federated identity
    role     a named set of permissions
    resource the scope it applies at

Roles come in three kinds.

    basic       Owner, Editor, Viewer -- far too broad, avoid
    predefined  curated per service, e.g. storage.objectViewer
    custom      your own set, when predefined does not fit

Basic roles are the thing to call out. Editor can modify almost everything in the project, including IAM in many cases. Predefined roles at the narrowest scope is the whole discipline.

Service accounts are identities, and the key file is the hazard.

    on GKE          Workload Identity
    on Cloud Run / GCE  the attached service account
    outside GCP     Workload Identity Federation

All three give short-lived tokens. A downloaded JSON key is a long-lived credential that ends up in a repository — which is why disableServiceAccountKeyCreation is a standard organisation policy.

disableServiceAccountKeyCreation

Service account impersonation lets a human temporarily act as a service account for a task, leaving an audit trail, instead of holding its key.

IAM Conditions add context to a binding — only during business hours, only on resources with a given name prefix — which is how you grant narrowly without writing a custom role.

Policy Intelligence is underused. The Recommender flags roles far broader than the principal actually uses, and the Policy Troubleshooter explains exactly why a specific call was allowed or denied, which beats guessing.

Groups, not individuals. Bind roles to a group and manage membership in the directory, so access leaves with the person.

What the interviewer is probing.1. "Why avoid the basic roles?" Probing: the breadth. Stalls: "They are fine for small teams." Moves up: Editor can modify nearly everything in the project including much of IAM; predefined roles at the narrowest scope is the discipline.

2. "How does the resource hierarchy affect permissions?" Probing: inheritance. Stalls: "Each project is separate." Moves up: policies at organisation or folder level inherit to everything beneath, so a broad grant high up is hard to see and hard to undo.

3. "How do you let GitHub Actions deploy without a key file?" Probing: Workload Identity Federation. Stalls: "Store the JSON key as a secret." Moves up: federation exchanges the GitHub OIDC token for a short-lived Google token, so no long-lived credential exists.

4. "What is service account impersonation for?" Probing: auditable elevation. Stalls: "Sharing accounts." Moves up: a human acts as a service account temporarily for a task, leaving an audit trail, instead of holding its key.