Questa è la terza parte della mia panoramica sull’IaC basata su un esperimento personale: la costruzione di un Cyber range utilizzando il paradigma IaC. Qui trovi la prima e la seconda parte.

Qualche settimana fa ho incontrato Spacelift e ho avuto la possibilità di testare il loro prodotto. Spacelift viene descritto come:

Collaborative Infrastructure for modern software teams

In pratica, Spacelift offre un’interfaccia web e un framework per mantenere, testare e organizzare infrastrutture utilizzando il paradigma IaC (Infrastructure as Code).

Ho deciso di adattare i miei playbook in modo che potessero essere gestiti all’interno di Spacelift. Anche se mi piace molto Spacelift, pianifico sempre una strategia di uscita. In pratica, posso eseguire i miei playbook al di fuori di Spacelift, e questo mi è utile per lo sviluppo, il test e il debug. Considero questo un blocco “soft”, e questo è molto importante per me.

Questo post riassume come ho utilizzato Spacelift per il mio semplice scenario. Tieni presente che Spacelift è più potente e può effettivamente coprire molti scenari complessi.

Stack: esecuzione di istanze da GitHub

Dalla pagina di documentazione ufficiale:

Stack is one of the core concepts in Spacelift. […] You can think about a stack as a combination of source code, the current state of the managed infrastructure (eg. Terraform state file), and configuration in the form of environment variables and mounted files.

Nel mio scenario, ho bisogno di due stack: uno per Terraform e un altro per Ansible. Ho visto tre approcci per la costruzione e il mantenimento degli stack:

• completamente manuale: tutti gli stack sono creati dagli esseri umani;
• completamente automatizzato: tutti gli stack sono creati da Terraform;
• ibrido: lo stack principale crea attività secondarie.

Nell’approccio completamente automatizzato, tutti gli stack e le relazioni tra di essi sono creati da Terraform. Tutto ciò che riguarda Spacelift può essere gestito con il paradigma IaC, quindi questo potrebbe essere il modo migliore per molti ingegneri DevOps. A volte anche gli stack “builder” sono gestiti all’interno di Spacelift: in questo caso, lo stack che può manipolare i progetti Spacelift deve essere amministrativo.

Nel mio scenario, ho usato un approccio ibrido: lo stack principale costruisce gli stack dipendenti e le relazioni tra di essi, ma crea anche l’infrastruttura AWS. In breve, il mio stack Terraform:

• viene creato manualmente da un repository GitHub;
• viene attivato ad ogni commit su GitHub;
• dopo la fase di pianificazione è richiesta una conferma manuale;
• è responsabile della costruzione dello stack Ansible e delle relative politiche e ambienti;
• è responsabile della costruzione dell’infrastruttura AWS;
• è responsabile di attivare lo stack Ansible.

Vediamo come costruire lo stack Terraform:

• Provider: GitHub
• Repository: dainok/iac
• Branch: master
• Root del progetto: lab-all-in-one-vulnerable-website
• Backend: Terraform
• Amministrativo: true
• Nome: lab-all-in-one-vulnerable-website

Una volta creato, lo stack può essere attivato:

Ambiente e contesto

Gli stack Spacelift possono essere configurati con variabili d’ambiente (all’interno dello stack stesso) o contesto (una sorta di ambiente condiviso). Il mio approccio è definire un contesto contenente dati che possono essere condivisi tra gli stack:

Il contesto può contenere sia variabili d’ambiente che file. Nel mio scenario utilizzo:

• un contesto che definisce il token API di Spacelift;
• un contesto che definisce il token API AWS;
• un contesto costruito dallo stack Terraform che condivide alcuni dati tra lo stack Terraform e lo stack Ansible.

Per essere più specifici, l’ultimo contesto viene utilizzato per condividere la chiave privata SSH con lo stack Ansible e per impostare alcune variabili d’ambiente di Ansible.

Politiche: collegamento di Terraform e Ansible insieme

Spacelift utilizza un progetto open source chiamato Open Policy Agent e il suo linguaggio di regole, Rego, per eseguire pezzi di codice definiti dall’utente che chiamiamo Politiche in vari punti decisionali.

Le politiche possono essere utilizzate per modificare il comportamento dello stack. Ad esempio, possono essere implementati controlli di sicurezza aggiuntivi o può essere richiesto l’approvazione di un utente specifico per la pianificazione. Nel mio caso ho utilizzato:

• una politica push per evitare l’attivazione automatica dello stack Ansible dopo un commit;
• una politica di attivazione per eseguire lo stack Ansible dopo quello di Terraform.

Alla fine ho due stack diversi, uno creato automaticamente:

Lo stack Ansible viene attivato automaticamente:

Azioni manuali

Il mio scenario richiede che distrugga il mio laboratorio dopo ogni sessione su Twitch. Nello stack Terraform posso eseguire singole attività:

Tutto bene?

L’implementazione di Ansible è ancora in fase beta; oltre a ciò, sono riuscito a raggiungere i miei obiettivi. Ho riscontrato alcuni problemi, ma il team di Spacelift mi ha aiutato a risolverli tutti o a trovare buone soluzioni alternative. Nessun software è perfetto, ma la cosa più importante per me è come il fornitore mi supporta quando incontro bug o problemi.

Conclusioni

Ho trovato Spacelift un framework interessante per gestire l’IaC all’interno delle aziende. Contiene molti controlli di sicurezza e integrazioni, e supporta i worker privati (nessuna necessità di un bastion host pubblico). Gli ingegneri possono collaborare insieme tracciando e commentando ogni esecuzione/passaggio/… Gli darei sicuramente un’occhiata più approfondita.

Ma ricorda, l’IaC è l'80% pianificazione e standardizzazione :)

Riferimenti

• Spacelift Docs