In CodicePlastico, per alcuni clienti, mi capita di occuparmi della governance e dell’infrastruttura dei loro tenant Azure. E, quasi sempre, la prima attività da affrontare è la stessa: rendere riproducibili gli ambienti.
Lo scenario è abbastanza comune. Nel corso del tempo sono state create decine, a volte centinaia, di risorse direttamente dal portale Azure. Resource Group, Storage Account, App Service, Key Vault, database, reti… tutto perfettamente funzionante.
Il problema arriva quando facciamo una domanda apparentemente banale: “se domani dovessimo ricostruire tutto da zero, saremmo in grado di farlo?”
Molto spesso la risposta è: no.
Infrastructure as Code alla riscossa
Il primo passo, quindi, è abbastanza naturale: descrivere l’infrastruttura tramite codice. Bicep, Terraform o qualsiasi altro strumento ci permetta di applicare i principi dell’Infrastructure as Code. L’obiettivo non è solamente automatizzare la creazione delle risorse. Il vero vantaggio è avere una descrizione esplicita dell’infrastruttura, versionabile, verificabile e soprattutto riproducibile.
Non dobbiamo più ricordarci che quello Storage Account aveva quella particolare configurazione o che quella Web App era stata creata in una determinata region.È scritto nel codice.
Problema risolto? Non proprio.
Il problema del giorno dopo
Immaginiamo di aver fatto tutto il lavoro. Abbiamo ricostruito l’infrastruttura, creato i template Bicep, sistemato le pipeline e verificato che sia possibile ricreare l’ambiente partendo da zero.
Perfetto!
Il giorno dopo qualcuno apre il portale Azure e crea una nuova risorsa. Oppure modifica manualmente una configurazione. Oppure crea uno Storage Account in una region diversa da quelle stabilite dall’azienda.
Siamo esattamente al punto di partenza.
Certo, possiamo rilevare il problema successivamente. Possiamo confrontare lo stato reale con quello dichiarato nel nostro repository. Possiamo sistemare la configurazione.
Ma questa, secondo me, non è ancora governance. È manutenzione.
La governance non dovrebbe sistemare gli errori
Quando si parla di governance, l’obiettivo non dovrebbe essere solamente accorgersi che qualcosa è andato storto e sistemarlo. L’obiettivo dovrebbe essere fare in modo che alcune cose non possano andare storte.
Se per ragioni di compliance abbiamo deciso che le nostre risorse possono essere create solamente in determinate region, perché dovremmo permettere ad un utente di crearne una da un’altra parte? Se ogni risorsa deve avere un determinato insieme di tag, perché controllarlo una settimana dopo? Se una determinata configurazione non è ammessa all’interno dell’organizzazione, perché lasciarne la responsabilità alla buona volontà di chi crea la risorsa?
Ed è qui che entrano in gioco le Azure Policy.
Prima i permessi, poi le regole
Uno dei punti che inizialmente può creare un po’ di confusione è la differenza tra Azure Policy e RBAC. In fondo entrambi sembrano avere a che fare con ciò che un utente può o non può fare.
In realtà il punto di vista è diverso.
RBAC si concentra sulle azioni degli utenti. Può rispondere, per esempio, alla domanda: “Alessandro può creare una Web App all’interno di questa subscription?”
Azure Policy si concentra invece sulle caratteristiche delle risorse. La domanda diventa: “Una Web App con queste caratteristiche può esistere all’interno di questa subscription?”
La differenza sembra sottile, ma cambia completamente lo scenario.
Un utente potrebbe avere tutti i permessi necessari per creare una risorsa e, contemporaneamente, non poterla creare perché la configurazione richiesta viola una Policy aziendale.
L’autorizzazione dice che puoi eseguire l’operazione. La Policy dice che la risorsa risultante deve rispettare determinate regole.
Un esempio molto semplice
Supponiamo di aver deciso che tutte le nostre applicazioni debbano essere eseguite in Germania.
Un developer prova a creare una nuova Web App. Ha i permessi necessari. La location richiesta è Germany. La richiesta passa il controllo RBAC, passa la Policy e la risorsa viene creata.
Domani lo stesso developer prova a creare un’altra Web App, questa volta in West Europe. Dal punto di vista dei permessi non è cambiato nulla: è sempre autorizzato a creare Web App. Ma la configurazione non rispetta più le regole che abbiamo definito. La Policy può quindi bloccare la creazione della risorsa.
Questo è il passaggio che, a mio avviso, cambia il modo di vedere la governance di Azure: non stiamo più controllando chi può creare qualcosa, o non solo.
Stiamo controllando che cosa può esistere nel nostro ambiente.
Il vero control plane
Infrastructure as Code rimane fondamentale. Continuerei a considerarlo il primo passo in quasi qualsiasi progetto di questo tipo.
Ma risolve un problema diverso.
IaC permette di descrivere quale dovrebbe essere la nostra infrastruttura e di ricrearla in maniera deterministica.
Le Azure Policy permettono invece di definire i confini entro cui quell’infrastruttura può evolvere. Ed è per questo che, quando penso alla governance di un tenant Azure, tendo a considerare le Policy come il suo vero control plane.
Non voglio scoprire domani che una risorsa non rispetta le nostre regole. Preferisco che quella risorsa non possa proprio nascere.
Nel prossimo post vedremo come trasformare queste regole in vere Policy, come applicarle senza trasformare il tenant in un campo minato e, soprattutto, perché anche le Policy dovrebbero essere gestite come codice.
