TL;DR
Se devi ricordare solo l’essenziale su Google Cloud IAM, tieni a mente questi punti:
- Come funziona IAM: definisce chi (un’entità) può fare cosa (un ruolo) su quale risorsa.
- Tre tipi di ruoli: IAM offre tre livelli di granularità crescente: ruoli di base (molto ampi), ruoli predefiniti (specifici per servizio) e ruoli personalizzati (creati su misura).
- L’obiettivo finale: applicare il principio del privilegio minimo, dando a ogni utente solo i permessi strettamente necessari, riducendo i rischi di sicurezza.
Introduzione
Man mano che un progetto su Google Cloud cresce, cresce anche il numero di persone e servizi che devono accedervi. La vera sfida non è dare accesso, ma dare l’accesso giusto.
Come puoi permettere a ogni utente di lavorare in autonomia senza però concedere permessi eccessivi?
È qui che entra in gioco Google Cloud Identity and Access Management (IAM): il sistema che ti consente di controllare in modo preciso chi può fare cosa nel tuo ambiente cloud.
Le Basi di IAM: Chi, Cosa e Su Quale Risorsa
Ogni configurazione IAM si basa sempre sugli stessi tre elementi fondamentali. Capirli bene significa capire IAM.
Il “Chi” – l’Entità (Principal)
Il chi rappresenta l’identità a cui assegni un permesso. Può essere:
- un utente
- un gruppo
- un service account (usato da applicazioni e workload)
- un intero dominio Cloud Identity
Il “Fa Cosa” – il Ruolo
Un ruolo è un insieme di autorizzazioni.
IAM non assegna permessi singoli, ma gruppi di permessi già pronti.
Esempio: per gestire una macchina virtuale servono più autorizzazioni (creare, avviare, fermare, eliminare). Invece di assegnarle una per una, IAM le raccoglie in un ruolo che puoi assegnare con un solo passaggio.
Il “Su Quale Risorsa”
Ogni ruolo è valido su una risorsa specifica, che può essere:
- l’intera organizzazione
- una cartella
- un progetto
- una risorsa specifica (VM, bucket, database)
Il livello scelto è fondamentale, perché determina dove quei permessi avranno effetto.
L’Ereditarietà dei Permessi e le Regole di Negazione
IAM sfrutta la gerarchia delle risorse di Google Cloud.
Quando assegni un ruolo a un’entità su una risorsa (ad esempio una cartella), quel ruolo viene ereditato automaticamente da tutte le risorse figlie, come i progetti al suo interno. Questo rende la gestione dei permessi molto più scalabile.
Le Regole di Negazione
IAM supporta anche le regole di negazione, che hanno una caratteristica fondamentale:
👉 vincono sempre.
Se un’azione è negata esplicitamente, IAM blocca l’accesso immediatamente, anche se un altro ruolo la consentirebbe. Questo meccanismo è utile per imporre limiti rigidi in ambienti complessi o altamente regolamentati.
I Tre Tipi di Ruoli: Scegliere Quello Giusto
Google Cloud IAM offre tre tipi di ruoli, pensati per scenari diversi. La differenza principale sta nella granularità dei permessi.
Ruoli di Base: Semplici, ma Pericolosi
I ruoli di base sono i più facili da usare, ma anche i più ampi. Applicati a un progetto, danno accesso praticamente a tutte le sue risorse.
- Visualizzatore (Viewer): può solo leggere le risorse
- Editor: può leggere e modificare le risorse
- Proprietario (Owner): può fare tutto, inclusa la gestione dei permessi e della fatturazione
- Amministratore di Fatturazione: gestisce la fatturazione senza toccare le risorse
⚠️ Attenzione: in progetti reali e collaborativi, questi ruoli sono spesso troppo permissivi e aumentano il rischio di errori o incidenti.
Ruoli Predefiniti: Il Miglior Compromesso
I ruoli predefiniti sono forniti direttamente da Google Cloud e sono specifici per servizio.
Esempio:
invece di assegnare il ruolo di Editor a un progetto, puoi usare un ruolo come compute.instanceAdmin, che permette di gestire solo le macchine virtuali, senza toccare il resto.
Vantaggi principali:
- maggiore granularità
- ruoli mantenuti e aggiornati da Google
- applicabili a livello di organizzazione, cartella o progetto
Per la maggior parte dei casi d’uso, sono la scelta migliore.
Ruoli Personalizzati: Applicare il Privilegio Minimo
Quando neanche i ruoli predefiniti sono abbastanza precisi, entrano in gioco i ruoli personalizzati.
Qui sei tu a definire esattamente quali autorizzazioni includere.
Esempio: un ruolo instanceOperator che consente solo di avviare e fermare le VM, ma non di eliminarle o modificarne la configurazione.
Questo è il modo più efficace per applicare il principio del privilegio minimo:
ogni utente ha solo ciò che serve, niente di più.
Due Cose Importanti sui Ruoli Personalizzati
Prima di usarli, è bene conoscere due aspetti fondamentali:
- Manutenzione Creare un ruolo personalizzato significa anche mantenerlo nel tempo. Se le API o le autorizzazioni cambiano, sarai tu a doverle aggiornare.
- Ambito di applicazione I ruoli personalizzati possono essere creati solo a livello di organizzazione o progetto, non a livello di cartella.
Per questo motivo è meglio usare ruoli predefiniti, quando possibile.
Conclusione
Usare bene IAM significa scegliere il livello di controllo giusto per ogni scenario.
All’inizio i ruoli di base possono sembrare comodi, ma con la crescita del progetto diventano rapidamente un rischio. Passare a ruoli predefiniti o personalizzati è un passo naturale verso un ambiente cloud più sicuro e professionale.
Dai un’occhiata al tuo progetto:
stai ancora usando ruoli di base dove potresti adottare una soluzione più mirata?
Potrebbe essere il momento giusto per fare pulizia.
Alla prossima, e buona gestione dei permessi 💪
Top comments (0)