How IAM Works

Principal, role, resource

Google Cloud IAM answers who can do what on which resource. Principals include Google accounts, Google groups, service accounts, Workspace/Cloud Identity domains and federated identities. A role is a collection of permissions such as storage.objects.get. There are three kinds: basic roles (Owner, Editor, Viewer), which are very broad and should be avoided in production; predefined roles maintained by Google for each service (for example roles/storage.objectViewer or roles/run.invoker); and custom roles you assemble yourself. An allow policy attached to an organization, folder, project or individual resource contains bindings of role to principals, and policies are inherited downward, with the effective permissions being the union. IAM Conditions can limit a binding, for example to resources with a certain name prefix or until a certain date, and deny policies can block specific permissions regardless of grants.

Policies flow down the hierarchy

A binding on a folder applies to every project and resource below it.

Granting a predefined role to a group

Bind roles to groups, then manage group membership in Workspace or Cloud Identity.

gcloud projects add-iam-policy-binding shop-dev-123456 \
  --member="group:shop-devs@example.com" \
  --role="roles/run.developer"

# bucket-level grant instead of project-wide
gcloud storage buckets add-iam-policy-binding gs://shop-dev-assets-123 \
  --member="group:shop-analysts@example.com" \
  --role="roles/storage.objectViewer"

gcloud projects get-iam-policy shop-dev-123456 --format=json

Editor is not least privilege

The basic Editor role can change almost every resource in a project. Grant predefined roles per service, and use the IAM recommender in the console, which suggests removing permissions a principal has not used.

Quick check: Which role type should normally be avoided for production workloads because it is too broad?

• Predefined roles
• Custom roles
• Basic roles such as Editor
• Conditional bindings