I tre tipi di ruolo

In Cloud IAM un role è una collezione di permission (nel formato service.resource.verb, es. storage.objects.get). Non assegni mai permission singole ai principal: assegni ruoli. Esistono tre famiglie.

I basic role (detti anche primitive) — roles/owner, roles/editor, roles/viewer — precedono IAM e coprono un intero progetto in modo grossolano: viewer legge tutto, editor modifica tutto, owner aggiunge la gestione IAM e billing. Sono troppo ampi per la produzione: violano il least privilege perché danno accesso anche a servizi che il principal non usa.

I predefined role hanno la forma roles/<servizio>.<ruolo> (es. roles/storage.objectViewer, roles/compute.instanceAdmin.v1, roles/pubsub.publisher) e sono curati da Google per una mansione specifica. Sono la scelta standard: bilanciano granularità e manutenzione, e vengono aggiornati da Google quando un servizio introduce nuove permission.

I custom role li definisci tu elencando le permission esatte, quando nessun predefined combacia. Si creano a livello di organization o di project (non di folder) e vanno mantenuti a mano: se un servizio aggiunge una permission, la devi inserire. Usali solo quando serve davvero.

Principal, binding e policy IAM

Un principal è l’identità a cui concedi il ruolo: user:, group:, serviceAccount:, un intero domain:, oppure allUsers/allAuthenticatedUsers. Un service account è un’identità per i workload (una VM, un’app), non per gli umani.

L’IAM policy di una risorsa è una lista di binding; ogni binding associa un role a uno o più principal (con condition opzionali). Preferisci sempre assegnare ruoli a un group invece che a singoli utenti: cambi l’appartenenza al gruppo senza toccare le policy.

Resource hierarchy ed ereditarietà

Le risorse sono organizzate gerarchicamente: Organization → Folder → Project → risorse. Una policy impostata a un livello alto viene ereditata verso il basso: i permessi effettivi su una risorsa sono l’unione della sua policy e di quelle di tutti gli antenati. Non esiste un “override” che toglie: un binding concesso a livello di organization non può essere revocato più in basso (per negare esplicitamente servono le IAM deny policy).

Conseguenza pratica: concedi i ruoli al livello più basso che soddisfa il bisogno. roles/viewer messo su un folder si propaga a tutti i project sottostanti, spesso molto più di quanto volevi.

Least privilege con gcloud

Per assegnare un binding a livello project:

gcloud projects add-iam-policy-binding PROJECT_ID --member="group:devs@example.com" --role="roles/storage.objectViewer"

Per revocarlo usa remove-iam-policy-binding con gli stessi --member/--role. I comandi equivalenti esistono agli altri livelli: gcloud resource-manager folders add-iam-policy-binding FOLDER_ID ... e gcloud organizations add-iam-policy-binding ORG_ID ....

Per leggere la policy effettiva di un progetto: gcloud projects get-iam-policy PROJECT_ID. Un custom role si crea con gcloud iam roles create ... --permissions=.... Quando devi capire perché un principal ha (o non ha) accesso, usa il Policy Troubleshooter.

La regola d’oro: davanti a “quale ruolo assegnare?”, scegli il predefined più stretto che copre il compito; ricorri al custom solo se nessun predefined basta; non usare mai un basic role.

Trappole tipiche d’esame

  • Accesso in sola lettura agli oggetti di un bucket → soluzione: roles/storage.objectViewer, non roles/viewer né roles/storage.admin; il basic role è troppo ampio, l’admin consente anche scrittura ed eliminazione.
  • Molte persone che cambiano ruolo nel tempo → soluzione: assegna il ruolo a un group:, non a singoli user:; gestisci l’accesso variando l’appartenenza al gruppo, non le policy.
  • Nessun predefined combacia esattamente → soluzione: crea un custom role con le sole permission necessarie; non ripiegare su roles/editor perché “tanto funziona”.
  • Una VM deve chiamare Cloud Storage → soluzione: usa un service account come identità del workload, non credenziali di un utente umano.
  • Serve revocare un accesso ma resta attivo → soluzione: è ereditato da un livello superiore; rimuovi il binding dove è stato concesso (folder/org) o applica una IAM deny policy — toglierlo solo sul project non basta.
  • Scelta tra basic e predefined per least privilege → soluzione: preferisci sempre il predefined; i basic role esistono per casi legacy, non per assegnazioni mirate.