fbpx

Pracując ze środowiskiem Hadoop na pewno masz do czynienia z takim wynalazkiem jak Kerberos. No chyba, że jest to środowisko testowe i Kerberosa po prostu tam nie ma. Zakładając, że każda szanująca się firma zadba o odpowiedni poziom bezpieczeństwa i Kerberos znajdzie się jako element stacku to na pewno zderzysz się z częścią problemów. Niektóre alerty niestety są nieoczywiste.

W poniższym wpisie przedstawię kilka typowych komunikatów błędów, na które możesz natrafić. W krótki sposób postaram się dodać komentarz co możesz w tej sytuacji zrobić, aby rozwiązać dany problem. Jeżeli masz jeszcze jakieś inne doświadczenia to zachęcam do dodania informacji w komentarzu🙂

No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt

W stack trace błąd będzie się zaczynać mniej więcej tak:

javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

Możliwe problemy:

  • Niezalogowany user z użyciem kinit. Ja to potocznie mówię, że trzeba się „skinitować” na usera
    klist -kt twoj-user.keytab, następnie
    kinit -kt twoj-user.keytab principal@domain.local
  • Zalogowany user za pomocą kinit ma ticket, który stracił swoją ważność. W tej sytuacji możesz powtórzyć operację „skinitowania się”
  • Nie masz zainstalowanego rozszerzenia Java Cryptography Extension (JCE)
  • Principal może nie istnieć w realmie, którego używasz

Clock skew too great

Wycinek ze stack trace:

GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))  
. . . Caused by: javax.security.auth.login.LoginException: Clock skew too great GSSException: No valid credentials provided (Mechanism level: Clock skew too great (37) - PROCESS_TGS 
kinit: krb5_get_init_creds: time skew (343) larger than max (300)

Taki błąd w zasadzie dla mnie oznacza jedno – problem z synchronizacją czasu na maszynie. Takie rzeczy zdarzają się najczęściej w środowiskach wirtualnych. W sytuacji, w której zatrzymujemy maszynę i wznawiamy jej działanie, ale również na fizycznych maszynach.
Upewnij się, że demony NTP wskazują na ten sam serwer NTP, który jest osiągalny przez klaster Hadoop. Dodatkowym elementem, o którym musisz pamiętać jest zachowanie spójności strefy czasowej na wszystkich maszynach.

GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63) – No service creds)

Rzadko spotykany błąd, ale jednak. Pierwszy raz spotkałem się z nim podczas konfiguracji distcp z wykorzystaniem cross-realm. Rozwiązaniem jest dopisanie do krb5.conf linii, która wymusi wykorzystywanie UDP zamiast TCP.

[libdefaults]
udp_preference_limit = 1

Receive timed out

Wycinek ze stack trace:

Caused by: java.net.SocketTimeoutException: Receive timed out   at java.net.PlainDatagramSocketImpl.receive0(Native Method)   at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:146)   at java.net.DatagramSocket.receive(DatagramSocket.java:816)   at sun.security.krb5.internal.UDPClient.receive(NetClient.java:207)   at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:390)   at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:343)   at java.security.AccessController.doPrivileged(Native Method)   at sun.security.krb5.KdcComm.send(KdcComm.java:327)   at sun.security.krb5.KdcComm.send(KdcComm.java:219)   at sun.security.krb5.KdcComm.send(KdcComm.java:191)   at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:319)   at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:364)   at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:735)

To oznacza, że socket UDP czeka na odpowiedź z KDC i finalnie jej nie otrzymało. Jakie mogą być tego powody?

  • Niepoprawny hostname KDC w konfiguracji
  • Niepoprawny adres IP wskazujący na KDC
  • Blokowanie pakietów UDP na poziomie firewalla (po stronie klienta lub serwera)

javax.security.auth.login.LoginException: connect timed out

Z kolei ten błąd pojawi się, gdy skonfigurowany jest domyślny protokół TCP do komunikacji. W tej sytuacji problemy mogą być podobne:

  • Niepoprawny hostname KDC w konfiguracji
  • Niepoprawny adres IP wskazujący na KDC
  • Firewall blokujący ruch pakietów TCP

kinit: Client not found in Kerberos database while getting initial credentials

Ten komunikat dotyczy bezpośrednio problemów związanych z użytkownikiem. Możliwe przyczyny:

  • Użytkownik nie istnieje w bazie
  • Próbujesz podłączyć się do innego KDC niż myślisz😄
  • Korzystasz nie z tego użytkownika🙂

Wiele problemów da się rozwiązać w szybki sposób. Kerberos może być przyjaznym rozwiązaniem w połączeniem z Hadoop pod warunkiem, że wiemy jak się z nim obchodzić. W innej sytuacji prawdopodobnie spędzimy wiele godzin na rozwiązaniu różnej maści problemów.

Author