13 Konfigurowanie Kerberos 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 pakietów odpowiedz na pytania, np.:

Default Kerberos version 5 realm: EXAMPLE.COM
Kerberos servers for your realm: localhost (or your FQDN)
Administrative server for your Kerberos realm: localhost (or your FQDN)

2. Zamapuj przyjazną nazwę hosta (opcjonalnie, do testów lokalnych).

Edytuj /etc/hosts i dodaj wpis dla swojego DC i serwera WWW, 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 działało mapowanie hostname→realm. Niezgodności w tym miejscu powodują błędy Server not found in Kerberos database.

4. Zainicjalizuj bazę danych Kerberos (jednorazowo, na hoście KDC). Ustaw bezpieczne hasło główne, gdy zostaniesz o to poproszony:

sudo krb5_newrealm

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

sudo kadmin.local

Wewnątrz kadmin.local:

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

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

chown www-data:www-data /etc/apache2/http.keytab
chmod 600 /etc/apache2/http.keytab
# verify
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 się błędem Invalid command 'GssapiCredStore', usuń nieobsługiwaną dyrektywę albo zaktualizuj moduł.

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

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

Wewnątrz 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łuchujące porty (host KDC):

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

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

Powinieneś zobaczyć krbtgt/[email protected] na liście biletów. Uruchom kinit jako ten sam użytkownik systemu operacyjnego, który potrzebuje biletu (np. zabbix dla testów webowych lub www-data/Apache dla interaktywnych testów SSO w przeglądarce). Bilety wydane innemu użytkownikowi systemowemu nie będą widoczne, chyba że zostanie dostosowany KRB5CCNAME i uprawnienia.

kinit [email protected]
klist

10. Przetestuj wymianę SPNEGO za pomocą curl (z klienta z prawidłowym TGT). 200 OK (lub przekierowanie do aplikacji) oznacza, że SPNEGO zakończyło się powodzeniem:

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

11. Opcjonalnie, jeśli interfejs Zabbix ma akceptować logowanie uwierzytelnione przez HTTP, włącz uwierzytelnianie HTTP w frontendzie Zabbix (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

W interfejsie WWW przejdź do Users > Authentication i otwórz kartę HTTP settings. Zaznacz pole Enable HTTP authentication i kliknij Ok w oknie dialogowym. Wybierz "HTTP login form" z listy rozwijanej Default login form. Zdecyduj, czy Case-sensitive login pasuje do zasad Twojego katalogu. Kliknij przycisk Update, aby zakończyć.

12. Konfiguracja przeglądarki (Firefox jako przykład): ustaw network.negotiate-auth.trusted-uris na hosta(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

Po wejściu na http://dc01.example.com powinieneś zostać od razu zalogowany do Zabbix bez formularza.

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

#for the web service
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#for the monitoring user
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Kontrole porządkowe:

  • klist -k /etc/apache2/http.keytab — sprawdź, czy principal usługi jest obecny 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 albo brakujący principal).
  • curl --negotiate zwracające 401/403 często oznacza nieprawidłowy principal, brak biletu, niezgodność nagłówka hosta albo 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.