Konfigurowanie Kerberosa z Zabbix

Przegląd

Uwierzytelnianie Kerberos może być używane w monitorowaniu WWW oraz w pozycjach HTTP w Zabbix.

Ta strona opisuje przykład konfiguracji Kerberos dla serwera Zabbix, aby wykonywać monitorowanie WWW www.example.com z użyciem principal Kerberos dla procesu Zabbix w Debian/Ubuntu.

Konfiguracja

1. Zainstaluj KDC i narzędzia klienta:

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

Podczas konfiguracji pakietu odpowiedz na pytania, na przykład:

Domyślna domena Kerberos w wersji 5: EXAMPLE.COM
Serwery Kerberos dla domeny: localhost (lub FQDN)
Serwer administracyjny dla domeny Kerberos: localhost (lub FQDN)

2. Zmapuj przyjazną nazwę hosta (opcjonalnie, na potrzeby testów lokalnych).

Edytuj plik /etc/hosts i dodaj wpis dotyczący kontrolera domeny oraz serwera WWW, jeśli nie masz DNS:

sudo vi /etc/hosts

Przykładowy wpis:

192.168.1.100  dc01.example.com dc01

3. Skonfiguruj klienta Kerberos i domenę KDC:

sudo vi /etc/krb5.conf

Przykładowe ustawienia:

[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

Jeśli planujesz używać .localdomain lub innych nazw niepublicznych, dodaj jawne mapowania domena→realm, aby mapowanie nazwa hosta→realm działało. Niezgodności w tym miejscu powodują błędy Server not found in Kerberos database.

4. Zainicjuj bazę danych Kerberos (jednorazowo, na hoście KDC). Po wyświetleniu monitu ustaw bezpieczne hasło główne:

sudo krb5_newrealm

5. Utwórz principal HTTP/host.fqdn@REALM, używając dokładnej nazwy hosta, której będą używać klienci; preferowane są małe litery (np. HTTP/[email protected]). Niezgodność wielkości liter lub nazwy powoduje błąd Server not found in Kerberos database.

sudo kadmin.local

W kadmin.local:

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

Przenieś keytab na hosta WWW (lub pozostaw go lokalnie, jeśli jest to ta sama maszyna) i ustaw uprawnienia umożliwiające korzystanie z niego przez Apache:

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

6. Zainstaluj i włącz moduł Apache GSSAPI:

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

Nie wszystkie wersje mod_auth_gssapi obsługują każdą dyrektywę Gssapi*. Jeśli Apache zakończy działanie z błędem Invalid command 'GssapiCredStore', usuń nieobsługiwaną dyrektywę lub zaktualizuj moduł.

7. Skonfiguruj VirtualHost (dostosuj DocumentRoot / ścieżkę do interfejsu Zabbix):

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

W pliku 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>

Uruchom ponownie Apache:

sudo systemctl restart apache2

8. Włącz/uruchom usługi KDC i sprawdź nasłuchiwanie na portach (host KDC):

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

9. Uzyskaj TGT do testów (uruchom jako użytkownik, który będzie używać biletu).

Na liście biletów powinien być widoczny krbtgt/[email protected]. Uruchom kinit jako ten sam użytkownik systemu operacyjnego, który potrzebuje biletu (np. zabbix na potrzeby kontroli WWW lub www-data/Apache na potrzeby interaktywnych testów SSO w przeglądarce). Bilety wystawione dla innego użytkownika systemu operacyjnego nie będą widoczne, chyba że zostaną dostosowane KRB5CCNAME i uprawnienia.

kinit [email protected]
klist

10. Przetestuj wymianę SPNEGO za pomocą curl (z klienta z prawidłowym TGT). Kod 200 OK (lub przekierowanie do aplikacji) oznacza pomyślne zakończenie SPNEGO:

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

11. Opcjonalnie, jeśli interfejs Zabbix powinien akceptować logowania uwierzytelniane przez HTTP, włącz uwierzytelnianie HTTP w frontendzie Zabbix.

W pliku konfiguracyjnym frontendu (zabbix.conf.php) ustaw:

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

Następnie skonfiguruj uwierzytelnianie HTTP w interfejsie WWW.

12. Konfiguracja przeglądarki (jako przykład użyto Firefoksa): ustaw network.negotiate-auth.trusted-uris na hosta (hosty) wykonującego Negotiate (dc01.example.com), aby przeglądarka automatycznie wysyłała tokeny Kerberos.

W about:config:

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

Teraz przejście do http://dc01.example.com powinno spowodować bezpośrednie zalogowanie do Zabbix, bez wyświetlania formularza.

13. Dbaj o aktualność kluczy i biletów. Domyślny czas życia biletu Kerberos wynosi około 10 godzin. Dodaj zadanie cron lub timer systemd, aby uniknąć wygaśnięcia:

# dla usługi WWW
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
# dla użytkownika monitoringu
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Kontrole porządkowe:

  • klist -k /etc/apache2/http.keytab - sprawdź, czy principal usługi znajduje się w keytab.
  • sudo tail -f /var/log/apache2/error.log - obserwuj błędy GSSAPI (gss_acquire_cred[_from]() failed to get server creds oznacza problem z keytabem/uprawnieniami lub brakujący principal).
  • curl --negotiate zwracający 401/403 często oznacza nieprawidłowy principal, brak biletu, niezgodność nagłówka hosta lub problem z uprawnieniami systemu plików; sprawdź logi oraz mapowania domen w /etc/krb5.conf.

Uwagi dotyczące bezpieczeństwa i uprawnień do plików

Pliki keytab muszą być dostępne do odczytu wyłącznie dla konta, które ich potrzebuje. Przykładowe uprawnienia: 0400 z właścicielem zabbix:zabbix w przypadku keytab użytkownika zabbix albo 0440 z właścicielem root:www-data w przypadku keytab Apache.

Unikaj przechowywania na hoście haseł w postaci jawnego tekstu, które zachowują ważność przez długi czas. W miarę możliwości używaj keytabów lub principalów maszyn dołączonych do domeny.

Podczas uruchamiania testów lub skryptów, które ustawiają KRB5CCNAME albo kopiują keytaby, po zakończeniu operacji ponownie sprawdź właściciela i uprawnienia — odrzucanie poświadczeń przez serwer WWW jest często spowodowane problemem z uprawnieniami do pliku.