Configurazione di Kerberos con Zabbix

Panoramica

L'autenticazione Kerberos può essere utilizzata nel monitoraggio web e negli item HTTP in Zabbix.

Questa pagina descrive un esempio di configurazione di Kerberos per il server Zabbix, in modo da eseguire il monitoraggio web di www.example.com con un principal Kerberos per il processo Zabbix su Debian/Ubuntu.

Configurazione

1. Installare KDC e le utilità client:

sudo apt update
sudo apt install krb5-kdc krb5-admin-server krb5-user

Durante la configurazione del pacchetto, rispondere alle richieste, ad esempio:

Realm Kerberos predefinito versione 5: EXAMPLE.COM
Server Kerberos per il proprio realm: localhost (o il proprio FQDN)
Server amministrativo per il proprio realm Kerberos: localhost (o il proprio FQDN)

2. Mappare un hostname descrittivo (facoltativo, per i test locali).

Modificare /etc/hosts e aggiungere una voce per il proprio DC e webserver se non si dispone di DNS:

sudo vi /etc/hosts

Esempio di riga da aggiungere:

192.168.1.100  dc01.example.com dc01

3. Configurare il client Kerberos e il realm KDC:

sudo vi /etc/krb5.conf

Impostazioni di esempio:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

[realms]
    EXAMPLE.COM = {
        kdc = dc01.example.com
        admin_server = dc01.example.com
    }

[domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM

Se si prevede di utilizzare .localdomain o altri nomi non pubblici, aggiungere mappature esplicite dominio→realm affinché la mappatura hostname→realm funzioni. Le discrepanze in questa configurazione causano errori Server not found in Kerberos database.

4. Inizializzare il database Kerberos (una sola volta, sull'host KDC). Impostare una password master sicura quando richiesto:

sudo krb5_newrealm

5. Creare il principal HTTP/host.fqdn@REALM utilizzando l'hostname esatto che verrà usato dai client; preferire le lettere minuscole (ad esempio, HTTP/[email protected]). Una differenza tra maiuscole/minuscole o nel nome causa l'errore Server not found in Kerberos database.

sudo kadmin.local

All'interno di kadmin.local:

addprinc [email protected]     # principal amministrativo
addprinc -randkey HTTP/[email protected]
ktadd -k /etc/apache2/http.keytab HTTP/[email protected]
quit

Spostare il keytab sull'host web (oppure mantenerlo localmente se si tratta della stessa macchina) e impostare autorizzazioni utilizzabili da Apache:

chown www-data:www-data /etc/apache2/http.keytab
chmod 600 /etc/apache2/http.keytab
# verifica
sudo -u www-data -k /etc/apache2/http.keytab

6. Installare e abilitare il modulo GSSAPI di Apache:

sudo apt install libapache2-mod-auth-gssapi
sudo a2enmod auth_gssapi
sudo a2enmod headers
sudo systemctl restart apache2

Non tutte le versioni di mod_auth_gssapi supportano ogni direttiva Gssapi*. Se Apache restituisce l'errore Invalid command 'GssapiCredStore', rimuovere la direttiva non supportata oppure aggiornare il modulo.

7. Configurare un VirtualHost (adattare DocumentRoot / il percorso alla propria interfaccia Zabbix):

sudo vi /etc/apache2/sites-available/zabbix.conf

All'interno di zabbix.conf:

<VirtualHost *:80>
    ServerName dc01.example.com
    DocumentRoot /usr/share/zabbix/ui
    <Directory /usr/share/zabbix/ui>
        Options FollowSymLinks
        AllowOverride None
        Require all granted
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore keytab:/etc/apache2/http.keytab
        GssapiLocalName On
        Require valid-user
    </Directory>
    RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
    RequestHeader unset Authorization
</VirtualHost>

Riavviare Apache:

sudo systemctl restart apache2

8. Abilitare/avviare i servizi KDC e verificare le porte in ascolto (host KDC):

sudo systemctl enable --now krb5-kdc krb5-admin-server
ss -tnlp | grep :80    # oppure: sudo netstat -tnlp | grep :80

9. Ottenere un TGT per i test (eseguire come l'utente che utilizzerà il ticket).

Nell'elenco dei ticket dovrebbe essere visualizzato krbtgt/[email protected]. Eseguire kinit come lo stesso utente del sistema operativo che necessita del ticket (ad esempio, zabbix per i controlli web oppure www-data/Apache per i test SSO interattivi nel browser). I ticket assegnati a un altro utente del sistema operativo non saranno visibili, a meno che non vengano modificati KRB5CCNAME e le autorizzazioni.

kinit [email protected]
klist

10. Testare lo scambio SPNEGO con curl (da un client con un TGT valido). Un 200 OK (o un reindirizzamento all'applicazione) indica che SPNEGO è riuscito:

curl -v --negotiate -u : http://dc01.example.com/

11. Facoltativamente, se l'interfaccia Zabbix deve accettare accessi autenticati tramite HTTP, abilitare l'autenticazione HTTP nel frontend Zabbix.

Nel file di configurazione del frontend (zabbix.conf.php) impostare:

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

Quindi configurare l'autenticazione HTTP nell'interfaccia web.

12. Configurazione del browser (Firefox viene utilizzato come esempio): impostare network.negotiate-auth.trusted-uris sugli host che eseguono Negotiate (dc01.example.com), in modo che il browser invii automaticamente i token Kerberos.

All'interno di about:config:

network.negotiate-auth.trusted-uris = dc01.example.com

Visitando ora http://dc01.example.com, si dovrebbe accedere direttamente a Zabbix senza visualizzare il modulo.

13. Mantenere aggiornati chiavi e ticket. La durata predefinita di un ticket Kerberos è di circa 10 ore. Aggiungere un timer cron/systemd per evitare le scadenze:

#per il servizio web
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#per l'utente di monitoraggio
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Controlli di manutenzione:

  • klist -k /etc/apache2/http.keytab — verificare che il principal del servizio sia presente nel keytab.
  • sudo tail -f /var/log/apache2/error.log — monitorare gli errori GSSAPI (gss_acquire_cred[_from]() failed to get server creds indica un problema con il keytab/le autorizzazioni oppure un principal mancante).
  • Se curl --negotiate restituisce 401/403, spesso ciò indica un principal errato, l'assenza di un ticket, una mancata corrispondenza dell'header host o un problema con le autorizzazioni del file system; controllare i log e le mappature del dominio in /etc/krb5.conf.

Note sulla sicurezza e sui permessi dei file

I file keytab devono essere leggibili solo dall'account che ne ha bisogno. Esempi di permessi: 0400 con proprietario zabbix:zabbix per un keytab dell'utente zabbix, oppure 0440 e root:www-data per un keytab di Apache.

Evitare di memorizzare password in chiaro a lunga durata sul host. Quando possibile, utilizzare keytab o principal di macchina aggiunti al dominio.

Quando si eseguono test o script che impostano KRB5CCNAME o copiano keytab, ricontrollare proprietà e permessi dopo l'operazione: il rifiuto delle credenziali da parte di un webserver è spesso dovuto a un problema di permessi dei file.