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

7 / 8

Google Cloud

Identity & Access — Cloud IAM

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

Cloud IAM controls who (members) can do what (roles) on which resources, organised around the GCP resource hierarchy: Organization -> Folders -> Projects -> Resources. IAM policies attach at any level and inherit downward, so a role granted at the organization or folder level applies to everything beneath it. Members can be Google accounts, Google groups, service accounts, or federated identities via Workload Identity Federation.

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

Roles come in three flavours: primitive (Owner/Editor/Viewer — broad, discouraged for production), predefined (curated per-service roles following least privilege), and custom (your own action set). The critical workload concept is the service account — an identity for an application or VM that is granted roles and used to authenticate to Google APIs. Best practice is to avoid long-lived service-account keys, instead using Workload Identity (on GKE) or Workload Identity Federation (for external/CI systems) to obtain short-lived credentials. IAM Conditions add context (time, resource attributes) to refine grants, and the principle throughout is least privilege via predefined roles at the narrowest scope.