 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
Nelle edizioni commerciali di Checkmk
puoi configurare i pacchetti degli agenti in modo che possano essere eseguiti sull'host da un utente senza privilegi, cioè non droote.
Questa funzione è inizialmente pienamente utilizzabile per gli agenti Linux, che sono stati installati come pacchetti DEB o RPM.
Il prerequisito per l'esecuzione senza privilegi è che il pacchetto dell'agente sia stato installato all'interno di una singola directory. L'opzione per selezionare una directory di installazione è disponibile per Linux, così come per Solaris e AIX.
Le due regole correlate "Installation paths for agent files (Linux, UNIX)" e "Run agent as non-root user (Linux)" sono state deprecate. Si prevede di rimuoverle entrambe in una futura versione di Checkmk.
 |
La funzionalità qui presentata è una technical preview, ovvero un'anteprima di una nuova funzionalità che sarà soggetta a sviluppo e ampliamento fino a nuovo avviso. Durante questa fase, è possibile che la funzionalità non solo venga aggiunta, ma anche modificata in modo tale che le configurazioni esistenti diventino obsolete e tu debba ricrearle. Ti chiediamo comprensione al riguardo. |
2. Configurazione dei pacchetti degli agenti
I pacchetti degli agenti si configurano in Agent Bakery, che puoi aprire all'indirizzo Setup > Agents > Windows, Linux, Solaris, AIX. Clicca sul pulsante "Agent rules". Alla voce "Agent rules > Linux/UNIX agent options" troverai la regola "Customize agent package (Linux)".
2.1. Specificare la directory di installazione
Con Directory for Checkmk agent puoi specificare la directory di installazione:
Tutti i file del pacchetto agente vengono installati in questa directory invece che in directory come /etc/, /usr/lib/ o /var/lib/.
Per motivi di sicurezza, non selezionare alcuna directory nella home directory di un utente.
Per Solaris e AIX hai finito. Per Linux, puoi anche specificare l'esecuzione senza privilegi.
2.2. Configurazione dell'esecuzione senza privilegi
Dopo aver selezionato Customize user, sono disponibili due opzioni di base per l'agente Linux:
I valori predefiniti Run agent as root, set agent controller user e cmk-agent as user specificano esattamente il comportamento predefinito dell'agente Checkmk per Linux, anche senza configurare questa regola,
in modo che l'Agent Controller venga eseguito sotto cmk-agent e lo script dell'agente sotto root.
La novità, tuttavia, è l'opzione di specificare un utente diverso come cmk-agent.
La seconda opzione è Run agent as non-root, set agent user. Questo specifica che, oltre all'Agent Controller, anche lo script dell'agente verrà eseguito con l'utente specificato, ovvero entrambi senza privilegi.
Puoi anche assegnare ID numerici all'utente (UID) e al gruppo (GID). Tieni conto delle convenzioni della tua distribuzione Linux e di eventuali limitazioni esistenti dei file system utilizzati.
L'ultima opzione determina se l'utente selezionato in questa regola debba essere creato qualora non esista già.
2.3. Preparazione dell'esecuzione con privilegi dei singoli plug-in dell'agente
Per i plug-in dell'agente, la regola Plug-ins, local checks and MRPE for non-root users ti consente di specificare individualmente gli utenti che eseguono operazioni su directory specifiche. Ciò ti permette di eseguire i plug-in in cartelle specifiche con ID utente non privilegiati o come root. Questa regola genera una configurazione dell'agente che viene installata automaticamente. Di seguito descriviamo ulteriori configurazioni sull'host.
3. Configurazione dell'esecuzione senza privilegi sull'host
Se hai configurato i pacchetti dell'agente per l'esecuzione senza privilegi, potrebbe essere necessaria una configurazione aggiuntiva sull'host Linux su cui è installato il pacchetto.
Per motivi di sicurezza, un agente configurato per l'esecuzione senza privilegi offre una gamma di funzioni leggermente più ridotta rispetto a un agente eseguito con i permessi di root. Per rendere disponibili le funzionalità mancanti, tu, in qualità di amministratore, devi trovare metodi che siano sia efficaci sia compatibili con le linee guida di sicurezza della tua organizzazione e con le convenzioni della distribuzione Linux utilizzata.
|
Tieni presente che questo capitolo non fornisce una soluzione ottimale per la configurazione fornita con i pacchetti dell'agente o per quella eseguita sull'host. Tutte le soluzioni possibili e ragionevoli devono basarsi sulle distribuzioni utilizzate, sulle linee guida operative della tua organizzazione e sulla manutenibilità. |
3.1. Configurazione disudo
Abbiamo aggiunto una funzione wrapper per lo script dell'agente, che antepone "sudo" ai comandi che generalmente richiedono privilegi di alto livello.
Questo riguarda in Checkmk 2.4.0 mdadm (per leggere lo stato di vari RAID software e unità crittografate), mailq (per leggere la coda delle email dell'MTA postfix) e gli script per il monitoraggio dei siti Checkmk.
Puoi trovare esempi di configurazioni per sudo nella directory di installazione dell'agente, nella sottocartella default/package/agent/checkmk_agent_sudoers_template.
Puoi trasferire le righe necessarie nel tuo /etc/sudoers o copiare l'intero file in /etc/sudoers.d (sconsigliato).
Modifica le voci di conseguenza.
Ad esempio, in alcuni casi non sono necessari i permessi di superutente per leggere la coda delle email e puoi usare l'ID utente con cui viene eseguito l'MTA.
3.2. Esecuzione dei plug-in degli agenti senza privilegi di root
Per l'esecuzione dei plug-in dell'agente, ti consigliamo di garantire l'accesso alle informazioni necessarie tramite permessi sui file, assegnazioni di gruppo o liste di controllo degli accessi. Il seguente elenco mostra i metodi possibili:
Aggiungi l'utente con cui viene eseguito lo script dell'agente a un gruppo che può leggere i dati necessari nel monitoraggio.
Modifica i diritti di accesso o l'assegnazione di gruppo dei file di dispositivo (ad es. tramite regole
udev) in modo che l'utente senza privilegi possa accedervi.
3.3. Esecuzione dei plug-in dell'agente con privilegi di root
Se un plug-in dell'agente richiede i privilegi di root per funzionare, hai le seguenti opzioni:
Se necessario, esegui i plug-in tramite cronjob e reindirizza il loro output in un file di spool. Con intervalli superiori a un minuto tra le esecuzioni, copri anche i plug-in che altrimenti richiederebbero un'esecuzione asincrona.
Se hai già creato pacchetti agente con la regola Plug-ins, local checks and MRPE for non-root users, devi spostare i plug-in che devono essere eseguiti come root nelle directory configurate e applicare la configurazione per
sudo.
4. Installazione tradizionale
L'esecuzione senza privilegi è possibile anche senza un Agent Controller o se l'installazione non può essere eseguita tramite un pacchetto DEB o RPM.
4.1. Installazione senza gestore di pacchetti
Quando utilizzi i pacchetti TGZ forniti in formato .tar.gz, devi assicurarti che i permessi siano concessi correttamente dopo l'installazione.
Usa come guida un'installazione di esempio che hai effettuato su Linux con la gestione dei pacchetti.
|
Aggiungeremo gradualmente ulteriori informazioni a questa sezione. |
4.2. Esecuzione senza Agent Controller
Se l'Agent Controller non può o non deve essere utilizzato, sono possibili sia la chiamata non crittografata tramite (x)inetd sia la chiamata crittografata tramite secure shell.
Sono necessarie piccole modifiche rispetto alla chiamata con permessi di root.
Xinetd
Se l'Agent Controller è disabilitato o incompatibile, viene attivato il file di configurazione per xinetd fornito nella directory di installazione in default/package/config/xinetd-service-template.cfg.
Questo file contiene già l'utente senza privilegi specificato dalla regola dell'agente.
Se stai utilizzando un super-server Internet diverso (ad esempio, l'inetd di OpenBSD), crea la configurazione secondo la sua documentazione.
Puoi trovare degli esempi nell'articolo Monitoraggio di Linux in modalità legacy.
Secure Shell
Anche la chiamata tramite SSH corrisponde alla procedura descritta nell'articolo Monitoraggio di Linux in modalità legacy.
Devi solo adattare il percorso del file di configurazione .ssh/authorized_keys e il nome utente utilizzato all'utente senza privilegi che stai utilizzando.