# How IAM Works — Google Cloud Platform

Source: https://www.skillbyai.com/en/gcp/i-model

> Write allow-policy bindings with predefined roles at the right level.

## 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.

![A tree: one top node branching to two folder nodes, each branching to project nodes and then small resource leaves, with arrows showing inheritance downward.](assets/figures/gcp/section-2-map.svg) — Figure 2.1 — IAM policy inheritance from organization to resource.

## Granting a predefined role to a group

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

```bash
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.

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

- [ ] Predefined roles
- [ ] Custom roles
- [x] Basic roles such as Editor
- [ ] Conditional bindings

*Answer:* Basic roles such as Editor. Basic roles span almost every service in the project; predefined roles are scoped to one service.