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 klienckie:

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

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

Domyślny realm Kerberos w wersji 5: EXAMPLE.COM
Serwery Kerberos dla Twojego realm: localhost (lub FQDN)
Serwer administracyjny dla Twojego realm 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 webservera, jeśli nie masz DNS:

sudo vi /etc/hosts

Przykładowy wiersz, który możesz dodać:

192.168.1.100  dc01.example.com dc01

3. Skonfiguruj klienta Kerberos i realm 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 hostname→realm działało. Niezgodności w tym miejscu powodują błędy Server not found in Kerberos database.

4. Zainicjalizuj 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 host webservera (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 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 webowych 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 dostosujesz 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 frontend Zabbix.

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

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

Następnie skonfiguruj uwierzytelnianie HTTP w interfejsie webowym.

12. Konfiguracja przeglądarki (jako przykład użyto Firefoksa): ustaw network.negotiate-auth.trusted-uris na host(y) wykonujące 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/biletów. Domyślny czas życia biletu Kerberos wynosi około 10 godzin. Dodaj zadanie cron/timer systemd, aby uniknąć wygaśnięcia:

# dla usługi webowej
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 — monitoruj błędy GSSAPI (gss_acquire_cred[_from]() failed to get server creds oznacza problem z keytab/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 dla pliku keytab użytkownika zabbix lub 0440 i root:www-data dla pliku keytab Apache.

Unikaj przechowywania na hoście długotrwałych haseł w postaci zwykłego tekstu. Tam, gdzie to możliwe, używaj plików keytab lub principali maszyn przyłączonych do domeny.

Podczas uruchamiania testów lub skryptów, które ustawiają KRB5CCNAME lub kopiują pliki keytab, po zakończeniu operacji dokładnie sprawdź właściciela i uprawnienia — odrzucanie poświadczeń przez serwer WWW często wynika z problemu z uprawnieniami do plików.