Google Cloud IAM uses a resource hierarchy model where permissions inherit down from Organization to Folders to Projects. Unlike AWS where permissions are primarily user-centric, GCP IAM binds roles (collections of permissions) to principals at various levels of the hierarchy. This lab teaches you to design and implement GCP IAM from organization setup through service accounts and workload identity federation.
GCP IAM follows a different model than AWS. Instead of users having attached policies, GCP binds roles to members at specific resource hierarchy levels. Permissions flow down: if you have a role at the organization level, you have it for all folders and projects below. Understanding this hierarchy is fundamental to GCP security.
| Level | Purpose | Example |
|---|---|---|
| Organization | Root of hierarchy, tied to Cloud Identity/Workspace domain | example.com |
| Folder | Grouping mechanism for projects (departments, environments) | Production, Development |
| Project | Container for resources, billing boundary | web-app-prod, data-pipeline-dev |
| Resource | Individual GCP services | GCS bucket, GCE instance, BigQuery dataset |
user:alice@gmail.com - Individual Google account
group:devs@example.com - Google Group for team access
serviceAccount:sa@project.iam.gserviceaccount.com
domain:example.com - All users in Cloud Identity domain
allUsers - Anyone on the internet (public)
allAuthenticatedUsers - Any Google account
Set up organization, folders, and projects.
Work with predefined roles and IAM bindings.
Design custom roles with only required permissions.
Configure machine identities for applications and automation.
Use organization policies to enforce security constraints.
Configure federation with AWS, Azure, GitHub, and more.
Use GCP tools to find and fix IAM issues.
Service account keys in code, repos, or unsecured locations.
Using Owner/Editor roles or organization-level permissions.
Resources exposed to allUsers or allAuthenticatedUsers.