Ep. 29: Nuova architettura dell'agente in Checkmk 2.1

Per caricare questo video di YouTube è necessario accettare i cookie pubblicitari.

[0:00:00]	Benvenuti al canale Checkmk. Oggi diamo un'occhiata alla nuova architettura degli agenti.
[0:00:15]	L'agente Checkmk esiste da tempo e non ha subito grandi cambiamenti nell'architettura. Certo, l'agente è stato ampliato, ma l'idea generale di come funziona l'agente non è mai cambiata.
[0:00:28]	Vi spiego rapidamente come funzionava. All'inizio c'era un super server chiamato xinet, che veniva usato per ascoltare sulla porta 6556. Se arrivava una connessione, questo super server avviava lo script dell'agente Checkmk, che a sua volta raccoglieva tutti i dati di monitoraggio e li rimandava su quel socket prima che venisse chiuso.
[0:00:53]	Alcuni anni fa è arrivato systemd, che oggi è il sistema di init de facto per tutte le principali distribuzioni Linux. Abbiamo quindi aggiunto il supporto per questo sistema, ma l'idea alla base è sempre la stessa.
[0:01:06]	Quindi, c'è un'unità systemd in ascolto sulla porta 6556 e se arriva una connessione, esegue lo script dell'agente, recupera le informazioni e le restituisce al server Checkmk.
[0:01:17]	Così è stato fino alla versione 2.1. Con Checkmk 2.1 abbiamo cambiato l'architettura: abbiamo due nuovi componenti, uno sul server Checkmk e l'altro sull'agente Checkmk. Sul lato server, abbiamo il cosiddetto Agent Receiver, che ascolta su una nuova porta.
[0:01:40]	Deve essere separata dall'interfaccia web, quindi non si tratta delle porte 80 e 443. È una porta che inizia con 8000.
[0:01:48]	Sul lato agente, abbiamo il componente Agent Controller, che si occupa di tutte le comunicazioni tra l'agente Checkmk e il server Checkmk.
[0:02:02]	Dal lato dell'agente, l'Agent Controller parla con l'Agent Script vero e proprio, che viene eseguito come demone sul sistema Linux che viene monitorato, attraverso un socket unix, quindi la comunicazione o la comunicazione e la logica di controllo sono separate da questo socket unix, per così dire.
[0:02:23]	Quindi, il controllore agente si occupa solo della comunicazione. Cifra la comunicazione utilizzando la crittografia TLS asimmetrica tra il server Checkmk e l'agente Checkmk.
[0:02:35]	Inoltre, comprime i dati inviati per un trasporto più efficiente ed è possibile estendere l'Agent Controller in diversi modi.
[0:02:46]	Ma al momento le due caratteristiche che abbiamo implementato sono la compressione e, soprattutto, la crittografia TLS. Quindi, dal punti di vista del controllo, non è cambiato nulla.
[0:02:57]	È ancora l'agente che conoscete da anni. È ancora lo script di shell che fa il lavoro pesante del monitoraggio. Abbiamo solo creato servizi e unità systemd pulite che si occupano di tutto questo. Ho già parlato del socket.
[0:03:13]	L'agente Checkmk è in esecuzione come servizio. Abbiamo un servizio che si occupa delle sezioni asimmetriche dell'agente e tutto ciò si riunisce comunicando attraverso il socket unix.
[0:03:22]	Quindi, se si parla con l'agente dal server Checkmk, questo passa attraverso il controller dell'agente. Ma è più o meno la stessa cosa che si conosceva prima. C'è ancora la connessione sulla porta 6556 ed è tutto quello che c'è al momento.
[0:03:38]	Per il futuro, ci sarà un'edizione speciale di Checkmk che includerà un cosiddetto agente push in grado di inviare dati al server Checkmk, invertendo il modo di comunicazione che conoscete.
[0:03:51]	Questo è destinato alle installazioni Checkmk nel cloud, dove non si vuole che il server Checkmk sia in grado di interrogare direttamente l'agente; in questo caso possiamo invertire la direzione della comunicazione e far sì che l'agente Checkmk invii le informazioni al server.
[0:04:07]	Ok, questo è stato un discorso piuttosto tecnico e poco visivo. Diamo quindi un'occhiata a ciò che accade effettivamente con il nuovo agente.
[0:04:17]	Ora stiamo guardando un sito Checkmk appena aggiornato e un agente Checkmk appena aggiornato. Possiamo notare che c'è un servizio non monitorato che è nuovo.
[0:04:30]	È il servizio agente Checkmk. Se diamo un'occhiata a questo servizio, o meglio, se lo inventarizziamo per primo, molto rapidamente, possiamo vedere che c'è uno stato di avviso relativo all'agente. Quindi, diamo un'occhiata a ciò che l'agente ci sta dicendo.
[0:04:51]	E qui vediamo che l'agente è in esecuzione sulla versione 2.1. Questa è ancora la versione migliore al momento della registrazione. E dice che TLS non è attivato sull'host monitorato.
[0:05:03]	Quindi, l'agente controlla se è possibile attivare la crittografia TLS e, in caso affermativo, stampa questo avviso.
[0:05:13]	Quali sono i requisiti per questo? Il requisito è che l'agente sia in esecuzione o che sia alla versione 2.1 e che sia in esecuzione su un sistema con systemd, perché il controller dell'agente ha un requisito per systemd.
[0:05:27]	Senza systemd, non esiste un controllore dell'agente. Ciò significa che sui sistemi senza systemd l'agente Checkmk verrebbe eseguito in modalità legacy, come spiegato in precedenza.
[0:05:39]	Se systemd è disponibile, il controllore dell'agente Checkmk verrà registrato e attivato e si otterrà questo avviso. Quindi, cosa facciamo?
[0:05:52]	Per prima cosa, ovviamente, è possibile configurare il servizio in modo che ignori questo avviso e venga eseguito in modalità legacy. Perché, ovviamente, l'agente continuerà a funzionare anche dopo l'aggiornamento.
[0:06:03]	Non smetterà di funzionare se aggiornate il vostro sistema esistente, quindi sarete ancora in grado di monitorare, ma vi consigliamo di abilitare la crittografia TLS per essere protetti da attacchi man in the middle che potrebbero ascoltare i vostri dati di monitoraggio.
[0:06:20]	Quindi, come si fa? Come si attiva il TLS? Per farlo, dobbiamo andare alla riga di comando del sistema monitorato. Qui c'è il controller dell'agente cmk, che è il binario che gestisce tutto ciò che riguarda il controller dell'agente.
[0:06:39]	Ora diamo un'occhiata a ciò che può fare. Ci sono molti comandi e sottocomandi. La modalità demone è quella che il controllore agente esegue in background e in questo momento è già in esecuzione in background.
[0:06:54]	Abbiamo qui il comando register, che è quello che vogliamo usare. Esiste anche un proxy-register che può essere usato per creare informazioni di registrazione per i sistemi air gap.
[0:07:06]	Quindi, se c'è un sistema che non può registrarsi direttamente sul server di monitoraggio, è possibile farlo da qualsiasi altro sistema che possa parlare con il server di monitoraggio e poi importare questa configurazione sul sistema airgap.
[0:07:20]	Ma in questo esempio manteniamo le cose semplici. Utilizziamo direttamente il comando register perché possiamo parlare con il server Checkmk. Quindi, abbiamo il comando register e diamo un'occhiata a cosa può fare questo comando.
[0:07:35]	Anche in questo caso possiamo vedere diverse opzioni. Quelle importanti sono le OPZIONI in basso. Abbiamo bisogno di un nome di host. Cominciamo con quello. Ho chiamato questo sistema localhost, quindi l'hostname è semplicemente localhost.
[0:08:00]	Devo dare il nome del sito con -i. Ho chiamato il mio sito agent, piuttosto elementare. E con -u, dobbiamo indicare l'utente che ha il permesso di registrare l'agente. Ora facciamo così. Ora abbiamo il certificato del sito del server Checkmk.
[0:08:22]	Otteniamo informazioni su di esso. Potremmo verificare l'intero certificato con il server. Ma in questo caso so con chi sto parlando, quindi lo confermerò qui. Si.
[0:08:33]	Ora ci viene chiesta la password per l'utente che abbiamo appena indicato. Lasciate che la fornisca. Se non ci sono risultati in Linux, tutto ha funzionato.
[0:08:43]	Abbiamo registrato con successo il controller agente per la crittografia TLS con il server Checkmk. Ora diamo un'occhiata allo stato dell'agente.
[0:08:56]	Abbiamo anche il comando di stato per il controller dell'agente. E possiamo vedere che la connessione è alla porta 8000 di localhost verso il sito dell'agente.
[0:09:09]	La connessione ha un UUID e ci sono altre informazioni sul certificato e sulla registrazione in generale. Possiamo vedere che lo stato di registrazione è operativo, il che significa che tutto funziona come previsto.
[0:09:24]	È possibile registrare il proprio host su più server Checkmk. Quindi, se avete, ad esempio, un sito di prova in esecuzione, potete ovviamente registrare l'agente anche con quel sito, in modo che anche quest'ultimo sia in grado di interrogare l'agente.
[0:09:38]	D'altra parte, se un sito non è registrato con questo agente, non può interrogarlo.
[0:09:45]	Quindi, se non c'è registrazione, l'agente non comunicherà con il loro sito, a meno che non si stia operando in modalità legacy, come detto in precedenza, quindi le vecchie regole si applicano ancora se si dispone di una white list di IP che sarà in vigore e la crittografia classica sarà anch'essa in vigore, naturalmente.
[0:10:04]	Ma una volta avviata la prima registrazione, il controller dell'agente accetta solo le connessioni registrate.
[0:10:13]	Quindi, dopo aver fatto questo, torniamo all'interfaccia web. Ora possiamo vedere che il servizio agente Checkmk è già diventato verde.
[0:10:21]	Non c'è nulla di cui cui possiamo lamentarci, stiamo comunicando in modo criptato all'agente. La comunicazione è protetta e nessun altro può intercettare questa comunicazione. Bene, questo conclude questa rapida dimostrazione.
[0:10:38]	Spero che abbiate capito qualcosa di più del nuovo agente. Per approfondire, consultate la nostra guida ufficiale. Il link si trova nella descrizione.
[0:10:47]	E con questo vi ringrazio per aver guardato questo video. Assicuratevi di abbonarvi per non perdere mai un video in futuro. E ci vediamo la prossima volta.