TopolearnIAM decides every API call in Google Cloud; most access problems and many security incidents trace back to it.
Identity and Access Management (IAM) answers "who can do what on which resource". An allow policy attached to a resource (org, folder, project, or an individual bucket, topic, secret...) contains bindings: a role plus a list of principals.
Principals include user:ada@example.com, group:devs@example.com, serviceAccount:app@proj.iam.gserviceaccount.com, domain:example.com, and special ones like allUsers (anyone on the internet).
A role is a named set of permissions such as storage.objects.get. Three kinds:
- Basic roles: Owner, Editor, Viewer. Broad and coarse; avoid in production.
- Predefined roles: curated per service, e.g.
roles/storage.objectViewer,roles/run.developer. Use these by default. - Custom roles: your own permission list when no predefined role fits.
The effective policy on a resource is the union of its own policy and every ancestor's. Grants only add access; to take something away you remove the binding where it was made (or use deny policies, an advanced feature).
Good practice: grant roles to groups, not individuals; grant at the lowest level that works; prefer predefined roles over Editor. gcloud projects get-iam-policy shows bindings, and the console's Policy Troubleshooter explains why a principal has or lacks a permission.
Example
# Let a group read objects in one bucket only
gcloud storage buckets add-iam-policy-binding gs://shop-dev-assets \
--member="group:frontend@example.com" --role="roles/storage.objectViewer"
# Project-wide grant to a user
gcloud projects add-iam-policy-binding shop-dev-4821 \
--member="user:ada@example.com" --role="roles/run.developer"
# Who has which role on the project?
gcloud projects get-iam-policy shop-dev-4821 \
--flatten="bindings[].members" --format="table(bindings.role,bindings.members)"
# Which permissions are in a role?
gcloud iam roles describe roles/storage.objectViewer --format="value(includedPermissions)"Remember
- A binding = role + principals, attached to a resource
- Prefer predefined roles over Owner/Editor/Viewer
- Effective access is the union of the resource's and all ancestors' policies
- Grant to groups at the lowest level that works
Watch out for
- Granting Editor to make an error go away; it gives write access to nearly every service in the project.