In un contesto in cui i dati rappresentano il cuore pulsante di ogni organizzazione, gestirli in modo efficace, sicuro e scalabile è diventata una priorità strategica. MinIO si pone come una risposta concreta a queste necessità. MinIO è una piattaforma di object...
La nostra raccolta di articoli e approfondimenti tecnici
Una raccolta di video dai nostri eventi, webinar e molto altro
Una raccolta dei nostri Casi di successo
In un contesto in cui i dati rappresentano il cuore pulsante di ogni organizzazione, gestirli in modo efficace, sicuro e scalabile è diventata una priorità strategica. MinIO si pone come una risposta concreta a queste necessità. MinIO è una piattaforma di object...
Prima di scoprire come automatizzare l’installazione e aggiornamento di LogOS con Dr.WOLF, vediamo in dettaglio di cosa si tratta. LogOS SIEM è una soluzione offerta da Seacom in ambito Security, che permette di raccogliere e visualizzare le informazioni utili al fine di comprendere lo stato di salute dei sistemi informativi. Partendo dai log prelevati dalle macchine ed utilizzando tecnologie dedicate, è possibile capire se i sistemi possono considerarsi sicuri, oppure se sono affetti da qualche vulnerabilità. Inoltre, questa soluzione consente di conoscere anche lo stato delle macchine non solo dal punto di vista della sicurezza ma anche delle componenti hardware.
Questa soluzione prevede l’integrazione di diverse tecnologie che a seconda dello use case possono variare:
Come si evince dall’immagine, la soluzione si basa su Wazuh, che tramite gli agent reperisce dagli host target le informazioni di sicurezza utili per alimentare il Wazuh server. I dati presenti nelle opportune cartelle degli host di Wazuh, contenenti i log con le informazioni arricchite da Wazuh stesso, sono prelevati da Filebeat ed inseriti su opportuni topic Kafka. A questo punto, un Logstash è in ascolto sui topic Kafka e si occupa di indicizzare i log su Opensearch, da cui saranno visibili i dati tramite Opensearch Dashboards.
In contesti di produzione in cui le performance, la sicurezza, l’affidabilità e la resilienza degli applicativi sono fondamentali, essi vengono installati in cluster. Solitamente, per questo genere di soluzione, il cliente decide di effettuare installazioni on-premise, per cui è possibile che una singola installazione di LogOS possa prevedere decine di macchine dedicate.
In questi contesti, dunque, installare, manutenere ed aggiornare gli applicativi in decine di macchine può risultare molto oneroso. Abbiamo quindi deciso di automatizzare LogOS con Dr.WOLF.
Dr. WOLF (Wazuh Opensearch Logstash Filebeat) nasce quindi dall’esigenza di automatizzare l’installazione e aggiornamento delle componenti, utilizzando GitLab e Ansible.
GitLab è un repository open source che permette di collaborare allo sviluppo di software ed abilita alle funzionalità DevOps e di Intelligenza Artificiale. Nel nostro caso abbiamo utilizzato GitLab sia per mantenere il codice utile al funzionamento della soluzione, sia per orchestrare la pipeline CI/CD con la quale effettuare l’installazione delle componenti. Inoltre, sfruttando proprio la pipeline CI/CD è possibile mantenere la storia di tutte le operazioni effettuate, in modo tale da poter effettuare rapidamente anche un rollback ad una versione precedente in caso di eventuali problemi.
Ansible è un tool open source che permette di automatizzare l’installazione, configurazione, gestione e orchestrazione dei processi. Dato che è uno standard de facto, vista la compatibilità con GitLab e data l’esistenza di ruoli ufficiali già presenti, abbiamo deciso di utilizzare questa tecnologia nella nostra soluzione. Per il funzionamento di Ansible è necessario fornire contestualmente al playbook da eseguire anche un inventario nel quale vengono fornite indicazioni riguardo le macchine target da contattare ed eventuali variabili necessarie al funzionamento del playbook stesso.
Dr. WOLF, dunque, è una repository GitLab contenente una pipeline CI/CD divisa in diversi stage, l’ultimo dei quali utilizza comandi Ansible per installare le componenti desiderate.
La pipeline sarà divisa come segue:
Nel prossimo paragrafo dettaglieremo meglio ciascuno degli step della pipeline.
Questo task di inclusione avviene prima dell’esecuzione dei singoli stage. Al fine di installare le componenti volute, è necessario includere nella pipeline di Dr. WOLF anche i riferimenti delle pipeline delle singole componenti.
Questo step è necessario affinché possano essere eseguiti gli stage mancanti nella definizione della pipeline di Dr. WOLF. Oltre alla inclusione di tutte le pipeline delle componenti desiderate, dovremmo poi effettuare il clone di tutte le repository degli applicativi utilizzati, come vedremo in seguito.
Questo stage è necessario per includere in Dr. WOLF tutte le repository delle componenti che vogliamo installare, dato che esse contengono sia i vari ruoli Ansible sia altre informazioni utili come ad esempio i check che sono stati definiti per ciascuna di esse.
Questo stage si occupa di verificare se l’utente ha specificato tra le variabili l’utilizzo della chiave ssh o meno. Nel caso in cui non fosse definita, o fosse vuota, allora questo stage viene ignorato e non viene affatto eseguito a livello di pipeline, utilizzando quindi i soli username e password forniti per accedere alle macchine in ssh.
Questo stage si occupa della creazione dell’inventario padre contenente tutte le informazioni che abbiamo passato come variabili CI/CD. Il compito della generazione dell’inventario padre è demandata ad uno script python. In questo step, è presente anche un pre-task che si occupa di inizializzare la chiave SSH con cui accedere alle macchine.
Questo stage non è presente nella definizione della pipeline di Dr. WOLF. Questo vuol dire che ogni singola pipeline che abbiamo incluso, procederà alla esecuzione dei propri check definiti nelle proprie pipeline, se presenti. I check saranno comunque consistenti dato che prenderanno in considerazione gli inventari padre generati precedentemente. Ogni componente, dunque, effettuerà i propri check.
Questo stage si occupa di eseguire tutti i playbook ansible presenti al fine di creare l’inventario figlio e riempire il file /etc/hosts delle macchine con gli hostname e ip di tutte le componenti.
Questo stage non è presente nella definizione della pipeline di Dr. WOLF. Questo comporta il fatto che verranno prelevati tutti gli stage deploy presenti nella pipeline delle singole componenti. Per questo motivo, sarà possibile eseguire manualmente le singole componenti utilizzando questo stage. Verranno eseguiti i playbook corrispondenti agli applicativi che vogliamo includere, allo stesso modo di come si farebbe eseguendo le pipeline delle singole componenti separatamente.
Dato che l’esigenza era quella di gestire diversi applicativi per poterli integrare tra loro, anziché gestirli tutti in una unica grande repository abbiamo pensato di dividerli ognuno in una propria repository dedicata e lasciare che Dr. WOLF si occupasse solo di mettere assieme i pezzi mancanti agendo da orchestratore, per poter concludere l’integrazione di tutte le componenti.
In questo modo possiamo anche decidere di utilizzare le repository delle singole componenti per poter effettuare installazioni mirate.
Ad esempio, possiamo notare come la pipeline di Opensearch riesca ad effettuare tutte le operazioni necessarie al fine di installare l’applicativo:
Oltre che come orchestratore dei vari flussi, GitLab è fondamentale per la gestione automatizzata dell’inventatario, effettuata tramite variabili CI/CD. Infatti, tramite la corretta compilazione delle variabili è possibile automatizzare la creazione dell’inventario padre, contenente tutte le informazioni utili per il deploy degli applicativi, ad esempio gli host sui quali installare i nodi data di Opensearch piuttosto che lo username e la password per l’utente admin di Wazuh.
L’inventario padre, dunque, racchiude tutte le informazioni utili all’installazione ed è grazie ad esso che è possibile generare i singoli inventari figli che possiamo utilizzare per eseguire i playbook Ansible. L’esigenza di dividere tra inventario padre ed inventari figli era anche quella di poter utilizzare il più possibile notazioni fedeli a quelle consigliate dai ruoli Ansible dei singoli applicativi, adattando la nostra soluzione a quelle dei ruoli ufficiale piuttosto che il contrario, minimizzando le modifiche agli stessi.
Per alcune delle singole componenti abbiamo integrato anche dei playbook Ansible che permettano operazioni di management degli applicativi. Ad esempio, per Kafka, abbiamo ideato un ruolo con il quale è possibile creare topic specificando il numero di partizioni e repliche, eliminare topic ed effettuare una stampa dei topic presenti, sempre utilizzando le variabili CI/CD e sempre utilizzando GitLab e Ansible, in modo da tenere traccia delle configurazione effettuate e da poterle eseguire da un singolo punto di accesso, senza l’esigenza di entrare sul terminale delle macchine.
Tutto il flusso funziona in maniera automatica dopo aver studiato attentamente i ruoli ansible ufficiali dei singloli applicativi, facendo in modo che l’inventario figlio contenesse tutte le informazioni di cui ha bisogno per essere eseguito correttamente. Abbiamo anche messo a punto un sistema di versionamento, tale per cui la versione 1.0.0 di Dr. WOLF è composta dalle seguenti versioni degli applicativi:
|
Applicativo |
Versione |
Versione Dr. WOLF |
|
Confluent Kafka |
7.6.1 |
1.0.0 |
|
Opensearch |
2.8.0 |
1.0.0 |
|
Wazuh |
4.7.4 |
1.0.0 |
|
Logstash |
7.10.2 |
1.0.0 |
|
Filebeat |
7.10.2 |
1.0.0 |
Dr. WOLF è una soluzione che permette di installare e aggiornare diversi applicativi che si integrano tra loro, in particolare per la soluzione LogOS, utilizzando GitLab e Ansible. La svolta di questa soluzione è che possiamo gestire l’installazione e l’aggiornamento anche delle singole componenti qualora si rendesse necessario, senza intaccare in alcun modo il funzionamento generale di Dr. WOLF. Potremmo quindi velocizzare l’installazione delle componenti necessarie alla soluzione LogOS con Dr. WOLF, centralizzandone la gestione e mantenendo anche una storia delle azioni compiute, in modo da poter reagire in maniera reattiva ad eventuali problematiche. Oltre a questo, è possibile integrare tra loro non solo le componenti che formano LogOS, ma anche altre tecnologie. Infatti, è in fase di sviluppo anche l’integrazione tra MinIO e Dremio per la nostra proposizione Data Lakehouse, seguendo gli stessi procedimenti descritti nel corso dell’articolo.