Cloud Identity e federazione con l’IdP aziendale

Cloud Identity è l’Identity Provider (IdP) e la directory che gestisce utenti e gruppi di un’organizzazione Google Cloud. Nella maggioranza degli scenari enterprise, però, la source of truth resta un IdP esterno (Active Directory, Azure AD/Entra ID, Okta): l’obiettivo è federare l’identità, non ricrearla. Le identità umane vengono sincronizzate (tipicamente con Directory Sync/GCDS) e l’autenticazione viene delegata all’IdP via SSO (SAML/OIDC). Questo centralizza la enforcement di MFA, delle password policy e del provisioning/deprovisioning: quando un dipendente lascia l’azienda, la disabilitazione nell’IdP revoca l’accesso a Google Cloud.

Punto chiave d’esame: la federazione riguarda chi sei (authentication), mentre IAM decide cosa puoi fare (authorization). Google Cloud non concede permessi a un utente perché autenticato: servono binding IAM espliciti. Preferisci sempre assegnare i ruoli ai gruppi, non ai singoli utenti — i gruppi sono l’unità di RBAC che rende governabile la separation of duties e riduce il drift dei permessi.

Service account: impersonation e short-lived credentials vs chiavi statiche

I service account rappresentano l’identità dei workload e delle applicazioni, non delle persone. La regola cardine è evitare le service account key statiche (file JSON scaricabili): sono credenziali long-lived che, se esfiltrate, restano valide finché non vengono ruotate, e la loro rotazione/inventario è un incubo operativo. Puoi impedirne del tutto la creazione con l’organization policy iam.disableServiceAccountKeyCreation, che agisce come guardrail preventivo (non concede nulla, blocca soltanto).

L’alternativa raccomandata è la service account impersonation: un principal con il ruolo roles/iam.serviceAccountTokenCreator ottiene un token OAuth a breve durata per agire come il service account, senza mai possedere una chiave. Le short-lived credentials limitano la finestra di esposizione e sono tracciabili nei log. Applica il least privilege anche al service account stesso: assegna solo i ruoli necessari, evita Owner/Editor primitivi, e usa service account distinti per workload distinti così un compromesso resta contenuto.

Workload Identity Federation e Workload Identity per GKE

Per i workload che girano fuori da Google Cloud (on-prem, AWS, Azure, pipeline CI/CD come GitHub Actions), la Workload Identity Federation elimina la necessità di chiavi statiche: si stabilisce una trust relationship con un IdP esterno (OIDC/SAML), i cui token vengono scambiati per short-lived credentials Google Cloud. Il workload esterno usa la propria identità nativa e impersona un service account, senza segreti da distribuire e ruotare.

Per i workload dentro GKE, l’equivalente è la Workload Identity (Workload Identity Federation for GKE): mappa un Kubernetes service account a un IAM service account, così i pod ottengono credenziali Google Cloud automaticamente. Questo evita l’anti-pattern di montare una chiave JSON come secret nel cluster o di affidarsi ai permessi ampi del node service account (che darebbero a tutti i pod gli stessi diritti). Concetto trasversale: entrambe le soluzioni rimpiazzano credenziali long-lived con federazione e token effimeri.

Accesso privilegiato e separation of duties

Il least privilege va accompagnato dalla separazione dei compiti: chi amministra le identità non dovrebbe essere lo stesso che approva i pagamenti o gestisce le chiavi crittografiche. Usa i custom role quando i predefiniti sono troppo ampi, sfrutta le condizioni IAM per accessi contestuali o time-bound, e ricorda che le IAM deny policy / explicit deny hanno la precedenza su qualsiasi allow — utili per vietare azioni sensibili a prescindere dai ruoli concessi.

Trappole tipiche d’esame

  • Workload CI/CD esterno che deve accedere a GCS senza segreti → Workload Identity Federation: federa l’IdP OIDC della pipeline e impersona un service account; NON generare e archiviare una service account key JSON.
  • Pod GKE che chiama API Google Cloud → Workload Identity for GKE: mappa il KSA all’IAM service account; NON montare chiavi come secret né appoggiarti al node service account.
  • “Impedire a chiunque di creare chiavi statiche” → organization policy iam.disableServiceAccountKeyCreation: è un guardrail preventivo; un ruolo IAM non “vieta”, concede soltanto — la restrizione va imposta a livello di policy.
  • App che deve agire temporaneamente come un altro service account → impersonation con serviceAccountTokenCreator: genera short-lived credentials tracciabili; evita di condividere una chiave long-lived.
  • Gestire l’accesso di 200 sviluppatori a un progetto → binding IAM sui gruppi, non sugli utenti: federa i gruppi dall’IdP; l’assegnazione per-utente non scala e rompe la separation of duties.
  • Bloccare un’azione sensibile a un principal che ha già un ruolo ampio → IAM deny policy: l’explicit deny vince sull’allow; non serve rimuovere il ruolo se la deny copre lo scenario.