Il modello dei ruoli: basic, predefined e custom

Google Cloud IAM risponde alla domanda “chi (identity) può fare cosa (role) su quale risorsa”. I basic role (Owner, Editor, Viewer, storicamente detti primitivi) sono ampi e concessi a livello di progetto: comodi ma incompatibili con il least privilege, vanno evitati in produzione e nelle risposte d’esame che citano il “principio del privilegio minimo”. I predefined role sono granulari, mappati a servizi specifici (es. roles/storage.objectViewer) e mantenuti da Google: sono la scelta di default. I custom role si usano quando nessun predefined combacia con la separation of duties richiesta: offrono il controllo piu fine ma introducono un costo di manutenzione (le nuove permission dei servizi non vengono aggiunte automaticamente). Regola d’esame: predefined finche bastano, custom solo per esigenze specifiche, basic quasi mai.

Resource hierarchy, ereditarieta e org policy

La gerarchia Organization -> Folder -> Project -> resource e lo strumento primario di isolamento e separation of duties. Le policy IAM si ereditano verso il basso e sono additive: una binding assegnata a un folder si propaga a tutti i progetti sottostanti, e una policy figlia non puo togliere un permesso concesso a un livello superiore. Questo spinge a progettare la gerarchia (per ambiente prod/non-prod, per business unit, per confine di compliance) prima di distribuire gli accessi.

Le org policy sono un livello diverso da IAM: non dicono “chi puo fare cosa”, ma pongono guardrail su “cosa e consentito” nell’intera organizzazione o in un suo ramo. Esempi tipici da scenario: bloccare la creazione di service account key, limitare le region delle risorse per data residency, imporre domain restricted sharing, vietare gli IP esterni sulle VM. Sono constraint ereditati, ideali per la compliance perche valgono anche per gli utenti con ruoli potenti.

Identity dei workload: service account, impersonation e Workload Identity Federation

I service account sono le identity delle applicazioni. Le service account key statiche (file JSON) sono la principale fonte di leak e vanno evitate. Per i workload che girano su GCP si usa l’identity nativa dell’ambiente (es. Workload Identity per i pod GKE); per i workload esterni - GitHub Actions, AWS, Azure, on-prem con un IdP OIDC/SAML - la risposta e la Workload Identity Federation, che scambia il token dell’IdP esterno con credenziali short-lived senza creare alcuna chiave.

Per gli accessi umani o cross-service la service account impersonation (tramite il ruolo token creator) genera credenziali temporanee on-demand: niente chiavi da ruotare e tutto tracciato negli audit log. Sul fronte umano, Cloud Identity e l’IdP che gestisce utenti e gruppi; la best practice di least privilege su scala e assegnare i ruoli ai Google Groups (sincronizzati dall’IdP aziendale) e non ai singoli, cosi onboarding e offboarding diventano una modifica di appartenenza al gruppo. Strumenti come IAM Recommender aiutano poi a ridurre i permessi in eccesso nel tempo.

Trappole tipiche d’esame

  • Workload esterno (GitHub Actions/AWS) deve accedere a GCP senza gestire segreti -> Workload Identity Federation: scambia il token esterno con credenziali short-lived; scaricare una service account key e la risposta sbagliata.
  • Impedire in tutta l’organizzazione la creazione di key -> org policy constraint, non IAM: IAM e additiva e non “nega”; solo un guardrail org policy blocca l’azione anche per gli Owner.
  • Accesso temporaneo a un service account senza distribuire credenziali -> impersonation: ruolo token creator piu credenziali short-lived, non la chiave JSON permanente.
  • Gestire gli accessi di centinaia di persone -> ruoli ai Google Groups via Cloud Identity: il binding per singolo utente non scala e complica l’offboarding.
  • Data residency o region consentite per compliance -> org policy resource location restriction: e un guardrail di gerarchia, non un ruolo IAM.
  • Togliere un permesso concesso a livello di folder mettendo una policy restrittiva sul progetto -> non funziona: l’ereditarieta IAM e additiva; per limitare si riprogetta la gerarchia o si usano le org policy.