introduzione
Questo articolo riporta alcuni appunti che ho scritto durante lo studio di Cloud IAM; magari possono essere utili anche ad altre persone, ma attenzione.. il miglior modo per studiare GCP è fare affidamento alla documentazione ufficiale. Questo articolo può aiutarvi a riflettere e a riassumere le caratteristiche fondamentali di IAM in GCP
concetti chiave
Cloud IAM ti consente di concedere l’accesso granulare a risorse specifiche di Google Cloud e aiuta a prevenire l’accesso ad altre risorse. Cloud IAM ti consente di adottare il principio di sicurezza del privilegio minimo, in cui concedi solo le autorizzazioni necessarie per accedere a risorse specifiche.
In Cloud IAM tu gestisci il controllo degli accessi andando a definire CHI (Identity) , che ruoli HA (role) e per quali risorse. utilizzando le seguenti entita’:
- Members.
- Roles.
- Resources.
- Permissions.
- IAM Policy.
Resource
Una risorsa è un prodotto google che un utente o service account può utilizzare e su cui vogliamo costruire un livello di autorizzazione per inibire accessi non autorizzati. Per esempio una vm ma anche un organizzazione o un progetto
MEMBER
Un membro può essere un account Google (per gli utenti finali), un service account (per app e macchine virtuali… vedremo dopo cose’ realmente un service account), un gruppo Google o un dominio Google Workspace o Cloud Identity che può accedere a una risorsa. L’identità di un membro è un indirizzo email associato a un utente, account di servizio o gruppo Google; o un nome di dominio associato a domini Google Workspace o Cloud Identity.
role
Un ruolo è una collezione di permessi. Non è possibile concedere direttamente le autorizzazioni a un utente. Puoi assegnargli un ruolo e quando all’utente viene assegnato il ruolo, ottiene tutte le autorizzazioni associate a quel ruolo. Alcuni esempi di ruoli sono:
ruoli / storage.objectAdmin: questo ruolo ha il controllo completo sugli oggetti in un bucket, inclusa la creazione, l’eliminazione, la lettura e l’elenco degli oggetti. Tuttavia non ha alcun controllo sui metadati del bucket.
ruoli / storage.admin -: questo ruolo ha il controllo completo su un bucket.
Un ruolo può essere predefinito o personalizzato. I due ruoli precedenti sono esempi di ruoli predefiniti. Esistono numerosi ruoli predefiniti già esistenti in base a casi d’uso comuni. Tuttavia, puoi associare un numero di autorizzazioni insieme per formare un ruolo personalizzato in base alle tue esigenze.
Fate attenzione alla gerarchia di risorse google, prendendo ad esempio la seguente struttura,
se io assegno il ruolo di project editor all’utente Bob a livello di folder Product1, significa che Bob sarà project editor per i progetto Dev GCP, Test GCP, Production e relativi servizi. Quindi fate molto attenzione alle gerarchie soprattutto quando andate ad assegnare un ruolo a livello di folder o organizzazione e non a livello di progetto.
Fate attenzioni che alcuni servizi google possono inserire ulteriori livelli di autorizzazione a livello di singolo oggetto: ad esempio è possibile configurare a livello di un certo storage l’utente Mary come Writer.
IAM Policy
{
"bindings": [
{
"role": "roles/storage.objectAdmin",
"members": [
"user:dario.frongillo@gmail.com",
"serviceAccount:my-other-app@appspot.gserviceaccount.com",
"group:admins@italiancoders.com" ]
},
{
"role": "roles/storage.objectViewer",
"members": ["user:bob@example.com"]
}
]
}
che evidenzia che ad esempio il mio utente, un service account e un gruppo google admins hanno il rulo roles/storage.objectAdmin.
Le policy IAM possono essere modificate aggiungendo/rimuovendo ruoli ad un singolo member (dalla cli o dalla dashboard di google cloud) oppure sovrascrivendo le policy IAM di un intero progetto con l apposito comando della cli gcloud:
1- scarico le attuali policy con il comando
gcloud projects get-iam policy [PROJECT_ID] --format JSON > [FILE_PATH]
2- edito il json scaricato andando ad aggiungere o rimuove policy
3- Con la cli vado a sovrascrivere la vecchia IAM Policy con quella rappresentata dal nuovo file editato
gcloud projects set-iam-policy [PROJECT_ID] [FILE_PATH]
TROUBLESHOOTING IAM ROLES
Per organizzazioni molto grandi, con una policy ricca e con tanti utenti si può facilmente incorrere nella situazione in cui non si riesce a capire come mai un certo utente non riesce ad utilizzare un certo servizio a causa dei permessi della IAM Roles. Per queste situazioni google mette a disposizione il Policy Troubleshooter , un potente strumento che semplifica la comprensione del motivo per cui un utente ha accesso a una risorsa o non dispone dell’autorizzazione per utilizzare un servizio google. Dato un indirizzo email, una risorsa e un’autorizzazione, lo strumento di risoluzione dei problemi relativi alle policy esaminerà tutte le policy IAM che si applicano alla risorsa. Rivela quindi se i ruoli del membro includono l’autorizzazione su quella risorsa e, in tal caso, quali criteri vincolano il membro a tali ruoli.
service account
Un service account è simile al normale account dell’utente con la differenza che viene generalmente utilizzato da servizi sviluppati o ad esempio da una vm. Proprio come gli utenti possono avere ruoli diversi, così fa l’account di servizio. I dati utilizzati per l’autenticazione rispetto a GCP vengono forniti come chiave (praticamente è un file in formato json o p12) che può essere quindi utilizzato nel codice. Pertanto, quando gli utenti vengono autenticati con e-mail e password, gli account di servizio vengono autenticati con il file della chiave. Quindi se dovete fare un applicazione che utilizza servizi google come pub/sub o bucket la best practices è quella di creare un service account che rappresenta l applicazione, assegnare a tale service account i ruoli necessari ad usufruire dei servizi gcp e utilizzare la chiave di tale service account per autenticarvi a gcp tramite il vostro servizio.
Oltre ai service account creati dagli utenti, trovate nel vostro progetto una serie di service account di default creati automaticamente da gcp per permettervi di iniziare subito a lavorare quando create un servizio. Ad esempio di default gcp crea un service account con id <project-number>-compute@developer.gserviceaccount.com da assegnare alle vm in modo da permettere l utilizzo di servizi gcp ( es stacktrace per l invio dei log di sistema operativo) dalla vm creata. Fate attenzione che questi service account creati di default hanno il ruolo project editor e pertanto non sono adatti da utilizzare in ambiente di produzione in quanto troppo permissivi.
Un service account non è solo una identity come uno user ma funge anche da risorsa e ha quindi la propria IAM per regolarne l utilizzo. Posso quindi ad esempio assegnare il ruolo editor al utente pippo sul service account X e magari ad un altro utente il ruolo di reader per il server account x. Inoltre un utente è anche in grado di impersonare un service account con il ruolo di service account user applicato a livello di progetto o a livello di service account. Ad esempio:
- Bob ha il ruolo serviceAccountUser sul service account dummy
- Supponiamo che il service account dummy abbia il ruolo Cloud SQL Admin
l utente Bob sarà in grado di spacciarsi come se fosse il service account dummy e quindi creare ad esempio un database.
IAM Best practices
- Usa i ruoli predefiniti e non i ruoli primitivi
- Concedi ruoli autorizzando il minimo essenziale di autorizzazioni per arrivare al tuo scopo: esempio se vuoi far amministrare una vm a Bob assegnagli il ruolo di Compute Admin e non il ruolo di Editor
- Separa l ambiente di produzione da quello di test a livello di progetto
- In un architettura Multi-services gestisci ogni servizio con un apposito service account assegnando al service account il minimo essenziale insieme di ruoli necessari ad adempiere lo scopo del servizio
- Fai attenzione ai bucket, oltre ad IAM ci sono pure le ACL che possono includere altre regole di accesso
- In produzione evita di utilizzare i service account creati di default da GCP
