1. Roles and bindings #
Who has which rights, where.
Principles #
| Role type | Example | Usage |
|---|---|---|
| Basic | roles/editor | To avoid in production (too broad) |
| Predefined | roles/storage.objectViewer | By default |
| Custom | roles/monRoleLecture | A specific need not covered |
gcloud projects add-iam-policy-binding mon-projet --member=group:devs@exemple.fr --role=roles/run.developer
gcloud projects get-iam-policy mon-projet --format='table(bindings.role, bindings.members)'2. Service accounts #
Application identities.
Best practices #
- One service account per application, with only the roles it needs.
- No downloaded JSON keys: identity attached to the resource (VM, Cloud Run) or Workload Identity Federation from GitHub Actions or another cloud.
- On GKE, Workload Identity links a Kubernetes service account to a Google service account.
gcloud iam service-accounts create api-commandes --display-name="API commandes"
gcloud projects add-iam-policy-binding mon-projet --member=serviceAccount:api-commandes@mon-projet.iam.gserviceaccount.com --role=roles/datastore.user
gcloud run deploy api --image=europe-west9-docker.pkg.dev/mon-projet/app/api:1.0 --service-account=api-commandes@mon-projet.iam.gserviceaccount.com3. Guardrails #
Organization policies and audit.
Controls #
- Organization Policy: allowed regions (
gcp.resourceLocations), forbidding service account keys and public IPs on VMs. - Cloud Audit Logs: admin activity always logged, data access to be enabled.
- VPC Service Controls: a perimeter around services to limit data exfiltration.
Good practice: Use Google groups for IAM bindings: people are then managed in the groups, not in each project.
