Einrichten der Kerberos-Authentifizierung für Hadoop mit Cloudera Manager

In letzter Zeit war ich damit beschäftigt, herauszufinden, wie ich die Active Directory-Authentifizierung mit Hadoop, genauer gesagt mit dem CDH-Stack, integrieren kann. Ich habe ein paar CentOS 6.5-Maschinen, Cloudera Manager 4.8.0 und CDH 4.5.0 verwendet, um die vorgeschlagenen Lösungen zu testen. Aber lassen Sie uns am Anfang beginnen...

Dieser Blog ist Teil der Blogserie Kerberos und Hadoop und erklärt, was Kerberos ist und wie Sie einen Kerberos-Server einrichten können. Der Rest der Serie enthält:

• Kerberos-Grundlagen und Installation eines KDC
• Einrichten von realmübergreifendem Vertrauen zwischen Active Directory und Kerberos KDC

Hadoop verfügt über zwei Authentifizierungsmethoden:

• einfach -- dies ist der Standardwert für HTTP-Web-Konsolen. In diesem Fall müssen die Clients einen Benutzernamen angeben. Benutzer, die HDFS abfragen oder MapReduce-Aufträge einreichen möchten, müssen ihren Linux-Benutzernamen verwenden
• Kerberos -- in diesem Fall verwenden die HTTP-Clients den HTTP Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) oder Delegations-Tokens. Um Kerberos zu verstehen und was Sie tun müssen, um einen Kerberos-Server einzurichten, lesen Sie bitte Kerberos-Grundlagen und die Installation eines KDC

Bei der Aktivierung der Sicherheit mit Hadoop sollte für jeden Benutzer ein Kerberos-Prinzipal konfiguriert werden. Organisationen, die bereits ein Active Directory zur Verwaltung von Benutzerkonten haben, sind nicht scharf darauf, eine weitere Gruppe von Benutzerkonten separat in MIT Kerberos zu verwalten. Die Herausforderung bestand darin, Lösungen zu finden, wie wir Active Directory mit der Sicherheit von Hadoop integrieren können. Ich habe zwei verschiedene Ansätze ausprobiert:

• Verwendung eines Kerberos-Servers
• Integration von Samba mit dem Cloudera Manager (ich arbeite noch an diesem Blog... also schauen Sie später wieder vorbei)

Dies ist der letzte Teil der Blogserie über Kerberos, in dem sich endlich alles zusammenfügt und wir sehen, warum wir uns die ganze Arbeit gemacht haben. Der Rest der Serie enthält:

• was ist Kerberos und wie richtet man einen Kerberos-Server ein: Kerberos-Grundlagen und die Installation eines KDC
• wie Sie das Cross-Realm-Vertrauen zwischen einem Active Directory und dem KDC-Server einrichten: Einrichten von realmübergreifendem Vertrauen zwischen Active Directory und Kerberos KDC
• wie Sie Kerberos mit Cloudera Manager und Hadoop verwenden -- dieser Blog.

Hadoop mit KDC konfigurieren

Die Idee ist, Cloudera Manager und CDH so zu konfigurieren, dass sie mit dem KDC sprechen, das speziell für Hadoop eingerichtet wurde, und dann ein unidirektionales Cross-Realm-Vertrauen zwischen diesem KDC und dem (produktiven) Active Directory oder KDC herzustellen.

Die Kerberos-Integration mit einseitigem Cross-Realm-Trust ist die von Cloudera empfohlene Lösung. Und warum? Denn auch die Hadoop-Dienste müssen Zertifikate verwenden, wenn Kerberos aktiviert ist. Bei einem ausreichend großen Cluster kann die Anzahl der Zertifikatsanfragen und der zum Kerberos-Server hinzugefügten Benutzer ziemlich hoch sein (wir haben einen pro Dienst - z.B. hdfs, mapred usw. - pro Server). Wenn wir kein einseitiges Cross-Realm-Vertrauen konfigurieren würden, würden all diese Benutzer in unserem Active Directory oder KDC-Server der Produktion landen. Der Kerberos-Server für den Hadoop-Cluster könnte alle Hadoop-Benutzer (hauptsächlich Dienste und Hosts) enthalten und sich dann mit dem Produktionsserver verbinden, um die tatsächlichen Benutzer des Clusters zu erhalten. Er würde auch als Schutzschild fungieren, indem er alle Zertifikatsanfragen der Hadoop-Dienste/Hosts abfängt und den Active Directory- oder KDC-Produktionsserver nur dann kontaktiert, wenn ein 'echter' Benutzer eine Verbindung herstellen möchte. Warum Cloudera empfiehlt, ein KDC mit einseitigem Cross-Realm-Trust einzurichten, erfahren Sie auf der Seite Integration von Hadoop-Sicherheit mit Active Directory.

Voraussetzungen

1. Stellen Sie sicher, dass DNS korrekt konfiguriert ist. Wir müssen testen, ob Forward- und Reverse-DNS-Lookup funktionieren. Hinweis: Beim Einrichten eines Test-DNS mit BIND habe ich die folgenden Websites verwendet:
   • So installieren Sie den BIND DNS-Server auf CentOS 6
   • Konfigurieren von Reverse DNS in BIND 9

Um die umgekehrte DNS-Suche zu testen, können Sie verwenden:

$ yum install bind-utils

$ nslookup 172.16.115.194
  Server: 172.16.115.193
  Adresse: 172.16.115.193#53

  194.115.16.172.in-addr.arpa  Name =  host1.meinedomain.nl.

$ Host 172.16.115.194
  194.115.16.172.in-addr.arpa Domainname Zeiger host1.mydomain.nl.

Um die Vorwärtssuche zu testen, können Sie verwenden:

$ nslookup host1.meinedomain.nl
  Server: 172.16.115.193
  Adresse: 172.16.115.193#53

  Name: host1.meinedomain.nl
  Adresse: 172.16.115.194

$ host1.meinedomain.nl
  host1.mydomain.nl hat die Adresse 172.16.115.194

1. Kerberos ist ein zeitabhängiges Protokoll, da seine Authentifizierung teilweise auf den Zeitstempeln der Tickets basiert. Wir müssen NTP (Network Time Protocol) aktivieren, da andernfalls Clients, die versuchen, sich von einem Rechner mit einer ungenauen Uhr aus zu authentifizieren, vom KDC bei Authentifizierungsversuchen aufgrund der Zeitdifferenz abgewiesen werden. Wir gehen also auf allen Rechnern wie folgt vor:

$ yum install ntp
$ service ntpd start
$ chkconfig ntpd ein

Vergewissern Sie sich, dass auf allen Rechnern das Datum und die Uhrzeit korrekt eingestellt sind:

Datum

Wenn dies nicht der Fall ist, müssen Sie möglicherweise die Hardware-Uhr synchronisieren(Wie Sie Ihre Systemzeit konsistent mit der Hardware-Uhr synchronisieren) und/oder Ihre Zeitzone ändern:

$ ln -sf /usr/share/zoneinfo/Europa/Amsterdam /etc/localtime

1. Deaktivieren Sie IPv6 auf allen Rechnern.
2. Vergewissern Sie sich, dass die Firewalls deaktiviert sind oder den erforderlichen Datenverkehr zwischen den Rechnern zulassen.
3. Auf dem Rechner, auf dem Sie den Cloudera Manager ausführen werden, sollten Sie Security-Enhanced Linux (SELinux) deaktivieren. Bearbeiten Sie /etc/sysconfig/selinux (das ist ein Symlink zu /etc/selinux/config) und ändern Sie die SELINUX-Zeile auf deaktiviert.

$ cat /etc/sysconfig/selinux
  # Diese Datei steuert den Status von SELinux auf dem System.
  # SELINUX= kann einen dieser drei Werte annehmen:
  # Erzwingen - Die SELinux-Sicherheitsrichtlinie wird erzwungen.
  # permissiv - SELinux gibt Warnungen aus, anstatt sie zu erzwingen.
  # deaktiviert - SELinux ist vollständig deaktiviert.
  SELINUX=deaktiviert
  # SELINUXTYPE= Typ der verwendeten Richtlinie. Mögliche Werte sind: 
  # targeted - Nur gezielte Netzwerk-Daemons sind geschützt.
  # strict - Vollständiger SELinux-Schutz.
  SELINUXTYPE=gezielt

  # SETLOCALDEFS= Lokale Definitionsänderungen prüfen
    SETLOCALDEFS=0

Neustart.

1. Installieren Sie Hadoop mit dem Cloudera Manager. In diesem Blog werde ich nicht auf Hardware-Dimensionierung, Kernel-Tuning, Festplatten- und Netzwerkkonfiguration oder die Platzierung und Konfiguration der verschiedenen Hadoop-Dienste eingehen. Ich gehe davon aus, dass Sie bereits einen Hadoop-Cluster eingerichtet haben und erkläre Ihnen, wie Sie die Sicherheit aktivieren, indem Sie die Schritte auf der Cloudera-Website befolgen: Einführung in die Installation des Cloudera Managers.
2. Richten Sie ein Kerberos-KDC ein. Weitere Informationen finden Sie im Blog Kerberos-Grundlagen und die Installation eines KDC.
3. Falls Sie ein realmübergreifendes Vertrauen zwischen einem Active Directory und dem Kerberos KDC einrichten möchten, könnte Sie der Blogbeitrag Einrichten von realmübergreifendem Vertrauen zwischen AD und Kerberos KDC interessieren.

Konfigurieren Sie Cloudera Manager und CDH für die Verwendung von Kerberos

Glücklicherweise hat der Cloudera Manager eine recht gute Dokumentation darüber, was Sie ändern müssen, um Kerberos zu aktivieren. Diese finden Sie auf der Cloudera-Website: Konfigurieren der Hadoop-Sicherheit mit Cloudera Manager Enterprise Edition. Ja... es heißt Enterprise Edition, aber Sie können dies auch mit der Cloudera Standard Edition verwenden, da Kerberos auch in der kostenlosen Version enthalten ist. Da wir das KDC bereits installiert haben und wir angegeben haben, dass wir die Installation von Hadoop mit Cloudera Manager als Voraussetzung betrachten, können wir mit Schritt 4 beginnen.

HINWEIS: Wenn Sie den Cloudera Manager nicht für die Implementierung der Hadoop-Sicherheit verwenden, müssen Sie die Kerberos-Prinzipale und Keytabs auf jedem Host-Rechner in Ihrem Cluster manuell erstellen und einsetzen.

Hier finden Sie eine Zusammenfassung der Schritte, die Sie bei der Verwendung des Cloudera Managers ausführen müssen:

1. Da der Cloudera Manager das Java JDK bereits für uns installiert hat, müssen wir als erstes die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File installieren. In unserem Cluster haben wir JDK 1.6.0_32, also müssen wir die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6HINWEIS: Für Java 7 müssen Sie die auf der Cloudera-Website angegebenen JCE-Dateien herunterladen und die JCE auf allen Rechnern installieren, die im Cluster eine Rolle spielen (Datanode, Namenode, Client usw.).

#Ermitteln Sie die Java-Version, damit wir wissen, wo wir die Policy-Dateien ändern müssen.
$ java -version
  java version  "1.6.0_32"
# Wo sind die Policy-Dateien?
$ locate local_policy.jar
 
/usr/java/jdk1.6.0_31/jre/lib/security/local_policy.jar
 
/usr/java/jdk1.6.0_32/jre/lib/security/local_policy.jar
$ unzip jce_policy-6.zip
$  cd  jce
$ cp US_export_policy.jar /usr/java/jdk1.6.0_32/jre/lib/security/
$ cp local_policy.jar /usr/java/jdk1.6.0_32/jre/lib/security/
        #Überschreiben, wenn Sie dazu aufgefordert werden

1. Installieren Sie auf allen Rechnern krb5-workstation

$ yum install krb5-workstation

Stellen Sie sicher, dass die Eigenschaftsdatei krb5.conf auf allen Rechnern gleich ist.

1. Erstellen Sie einen Kerberos-Prinzipal und eine keytab-Datei für Cloudera Manager Server

  $  cd  ~
  $ kadmin -p tunde/admin
  kadmin: addprinc -randkey cloudera-scm/admin@GDD.NL
  kadmin: xst -k cmf.keytab cloudera-scm/admin@GDD.NL
  kadmin:  Ausgang

HINWEIS: Die Keytab-Datei des Cloudera Manager Servers muss cmf.keytab heißen, da dieser Name in Cloudera Manager fest programmiert ist.

1. Kopieren Sie die Keytab und passen Sie die Berechtigungen an (Diese Schritte müssen auf dem Cloudera Manager Server durchgeführt werden. Wenn Sie die Keytab auf einem anderen Rechner erstellt haben, müssen Sie diese Keytab kopieren oder das Prinzipal cloudera-scm/admin löschen und auf dem Cloudera Manager Server neu erstellen).

$ mv ~/cmf.keytab /etc/cloudera-scm-server/
$ chown cloudera-scm:cloudera-scm /etc/cloudera-scm-server/cmf.keytab
$ chmod  600 
/etc/cloudera-scm-server/cmf.keytab

Fügen Sie den Cloudera Manager Server-Prinzipal (cloudera-scm/admin@GDD.NL) in eine Textdatei mit dem Namen cmf.principal ein und speichern Sie die Datei cmf.principal im Verzeichnis /etc/cloudera-scm-server/ auf dem Hostrechner, auf dem Sie den Cloudera Manager Server ausführen.

$ cat /etc/cloudera-scm-server/cmf.principal
  cloudera-scm/admin@GDD.NL
$ chown cloudera-scm:cloudera-scm /etc/cloudera-scm-server/cmf.principal
$ chmod  600 
/etc/cloudera-scm-server/cmf.principal

1. Die folgenden Schritte müssen über die Cloudera Manager Admin Console (http://Cloudera_Manager_server_IP:7180) durchgeführt werden
   1. Alle Dienste anhalten
   2. Gehen Sie zu Administration -> Einstellungen -> Sicherheit -> Kerberos Security Realm und passen Sie den Wert an den Standard-Sicherheitsbereich an, den Sie in krb5.conf angegeben haben. In unserem Fall ist dies GDD.NL. Speichern Sie die Änderungen.HINWEIS: Hadoop ist derzeit nicht in der Lage, einen anderen als den standardmäßigen Realm zu verwenden. Der Kerberos-Standard-Realm wird in der Eigenschaft libdefaults in der Datei /etc/krb5.conf auf jedem Rechner des Clusters konfiguriert.
   3. Aktivieren Sie die HDFS-Sicherheit, indem Sie zu HDFS-Dienst -> Konfiguration -> Ansicht und Bearbeitung navigieren.
      1. Suchen Sie nach der Eigenschaft Hadoop Secure Authentication und wählen Sie die Option kerberos
      2. Suchen Sie nach der Eigenschaft Hadoop Secure Authorization und aktivieren Sie das Kontrollkästchen
      3. Suchen Sie nach der Eigenschaft Datanode Transceiver Port und geben Sie eine privilegierte Portnummer an (unter 1024). Cloudera empfiehlt 1004.
      4. Suchen Sie nach der Eigenschaft Datanode HTTP Web UI Port und geben Sie eine privilegierte Portnummer an (unter 1024). Cloudera empfiehlt 1006.
      5. Änderungen speichern
   4. Um die Zookeeper-Sicherheit zu aktivieren, navigieren Sie zu Zookeeper Service -> Configuration -> View and Edit und suchen Sie nach der Eigenschaft Enable Zookeeper Security und aktivieren Sie das Kontrollkästchen. Speichern Sie die Änderungen.
   5. Wenn Sie HBase verwenden möchten, müssen Sie auch die Eigenschaft HBase Secure Authentication auf Kerberos setzen und die Eigenschaft HBase Secure Authorization aktivieren. (Da ich HBase nicht auf dem sicheren Cluster installieren musste, habe ich diese Eigenschaften nicht getestet.)Nachdem Sie die Sicherheit für einen der Dienste im Cloudera Manager aktiviert haben, wird automatisch ein Befehl namens Generate Credentials ausgelöst. Sie können die generierten Anmeldeinformationen sehen oder neue Anmeldeinformationen generieren, indem Sie zu Administration -> Kerberos navigieren. Hier sollten Sie mehrere Credentials in der Form serviceName/FullyQualifiedDomainName@Realm sehen. Zum Beispiel für den Dienst hdfs und für den Fall, dass wir zwei Hosts haben (host1.mydomain.nl und host2.mydomain.nl), hätten wir: hdfs/host1.mydomain.nl@GDD.NL undhdfs/host2.mydomain.nl@GDD.NL.NOTE: Nicht alle Dienste laufen auf allen Hosts, daher sollten Sie nicht erwarten, dass ein hue-Berechtigungsnachweis für jeden Host generiert wird. Sie haben nur eine hue-Anmeldung für den Host, auf dem hue läuft.
   6. Aktivieren Sie die Hue-Sicherheit, indem Sie zu Hue-Dienst -> Instanzen navigieren und auf die Schaltfläche Hinzufügen klicken. Weisen Sie die Kerberos Ticket Renewer Rolleninstanz demselben Host zu wie den Hue Server.
   7. Starten Sie den HDFS-Dienst.
   8. Client-Konfiguration bereitstellen
   9. Um Benutzerverzeichnisse auf HDFS erstellen zu können, benötigen Sie Zugriff auf das HDFS-Superuser-Konto. Um auf dieses Konto zugreifen zu können, müssen Sie einen Kerberos-Prinzipal erstellen, dessen erste Komponente hdfs ist.

  $ kadmin -p tunde/admin
  kadmin: addprinc hdfs@GDD.NL
    #Sie werden nach einem Passwort gefragt
  kadmin:  Ausgang
  #erhalten Sie ein Ticket für den hdfs-Benutzer
  $ kinit hdfs@GDD.NL

1. Erstellen Sie Kerberos-Principals für alle Benutzer, die Zugriff auf den Cluster benötigen

   $ kadmin -p tunde/admin
   kadmin: addprinc testUser@GDD.NL
   #Sie werden nach einem Passwort gefragt
   kadmin:  Ausgang
   

2. Stellen Sie sicher, dass alle Host-Rechner im Cluster über ein Unix-Benutzerkonto (mit der Benutzerkennung >= 1000) verfügen, dessen Name mit dem ersten Bestandteil des Hauptnamens dieses Benutzers übereinstimmt. Das Unix-Konto testUser sollte beispielsweise auf jedem Rechner existieren, wenn der Hauptname des Benutzers testUser@GDD.NL lautet.

HINWEIS: Die Benutzerkonten müssen eine Benutzer-ID haben, die größer als oder gleich 1000 ist. Und warum? Denn Hadoop versucht zu verhindern, dass Benutzer wie mapred, hdfs und andere Benutzer, die Unix-Superuser sind, Aufträge einreichen. In Hadoop gibt es eine Einstellung, min.user.id, die standardmäßig auf 1000 eingestellt ist. Das Problem ist, dass CentOS das Benutzerkonto bei 500 startet. Das heißt, wenn Sie einen Benutzer mit "useradd user" anlegen, wird die uid nicht über 1000 liegen. Sie können versuchen, den Wert von min.user.id in taskcontroller.cfg auf 500 zu ändern, aber dann müssen Sie wahrscheinlich herausfinden, wie Sie dies über den Cloudera Manager tun können. Meine Lösung war, die Benutzer einfach mit einer bestimmten Benutzer-ID anzulegen. Sie können dies mit "useradd correctUser -u NR" tun, wobei NR > 1000 Wenn es in Ihrem Cluster Benutzerkonten gibt, deren Benutzer-ID kleiner ist als der für die Eigenschaft min.user.id angegebene Wert, gibt der TaskTracker den Fehlercode 255 zurück.

1. Erstellen Sie für jedes Benutzerkonto ein Unterverzeichnis unter /user auf HDFS

   $ kinit -p hdfs
   $ hadoop fs -mkdir /user/testUser
   $ hadoop fs -chown testUser /user/testUser
   

2. Testen Sie die HDFS Kerberos-Einrichtung:

   $ kdestroy
   $ kinit -p testBenutzer
   $  echo "Dies ist ein Test" >  ~/test.txt
   $ hadoop fs -put ~/test.txt /user/testUser
   $ hadoop fs -ls
   Gefunden  1  Artikel
   -rw-r--r--  3  testBenutzer Supergruppe  15  2014-02-05 12:39 test.txt
   # Testen Sie nun, dass Sie ohne gültiges Ticket nicht auf HDFS zugreifen können
   $ kdestroy
   $ hadoop fs -get /benutzer/testBenutzer/test.txt
   14/02/05 12:40:03 ERROR security.UserGroupInformation: PriviledgedActionException as:cloudera  (auth:KERBEROS)  Ursache:javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]
   14/02/05 12:40:03 WARN ipc.Client: Exception aufgetreten  während  Verbindung zum Server : javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]
   14/02/05 12:40:03 ERROR security.UserGroupInformation: PriviledgedActionException as:cloudera  (auth:KERBEROS)  Ursache:java.io.IOException: javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]
   

Ohne ein gültiges Kerberos-Ticket können Sie also nicht auf HDFS zugreifen.

HINWEIS: Wenn Sie wirklich sicher sein wollen, dass HDFS ordnungsgemäß funktioniert, können Sie eine größere Datei kopieren (die Dateigröße sollte größer sein als die Blockgröße, die standardmäßig 128 MB beträgt) und dann überprüfen, ob die Blöcke ordnungsgemäß repliziert werden. Sie können die Blocknummer auf der Namenode Web UI sehen, wo Sie zu der Datei navigieren können, die Sie gerade kopiert haben. Anschließend können Sie auf der Kommandozeile den Befehl "hadoop fsck -files -blocks -locations" verwenden, um zu sehen, wo sich die Blöcke befinden. Achten Sie darauf, dass Sie einen Pfad angeben, der nicht zu viele Dateien enthält, da die Ausgabe sonst schwer zu verfolgen ist. Sie können auch den Befehl "hadoop dfsadmin -report" verwenden, der eine ähnliche Ausgabe wie fsck liefert, allerdings auf Basis der einzelnen Knoten. Eine Übersicht über die Hadoop-Befehle finden Sie auf der Seite Commands Manual.

1. Starten und testen Sie den MapReduce-Dienst
2. Einen Testauftrag ausführen

   #Anmelden als testUser
   $ locate hadoop-examples.jar
   /usr/lib/hadoop-0.20-mapreduce/hadoop-examples.jar
   $ kinit $
   $ hadoop jar /usr/lib/hadoop-0.20-mapreduce/hadoop-examples.jar wordcount /user/testUser/test.txt out
   #Ihr Auftrag sollte ausgeführt werden.
   $ hadoop fs -cat out/part-r-00000
   

3. Starten Sie den Rest der Dienste (Hive, Oozie, Zookeeper, Hue, Impala,...)

HINWEIS: Da ich das Impala-Paket erst später zum Cluster hinzugefügt habe, musste ich das Impala konfigurieren, mit dem sich Hue verbinden kann. Dies können Sie tun, indem Sie im Cloudera Manager die Konfiguration des Hue-Dienstes aufrufen und die Eigenschaften des Hue-Sicherheitsventils suchen. Hier sollten Sie Informationen über Ihren Impala Daemon Host hinzufügen. Sie sollten die folgenden Zeilen hinzufügen:

[impala]
server_host=server_port=21000

Ersetzen Sie Ihren tatsächlichen Hostnamen für . Sie können einen beliebigen Ihrer Impala Daemon-Hosts auswählen. Speichern Sie anschließend die Änderungen und starten Sie den Hue-Dienst neu.

Fehlersuche

1. Die Client-Konfiguration wurde nicht bereitgestelltFehler:

$ hadoop fs -ls
ls: Autorisierung  (hadoop.security.authorization)  aktiviert ist, aber die Authentifizierung  (hadoop.security.authentication)  ist als einfach konfiguriert. Bitte konfigurieren Sie eine andere Methode wie Kerberos oder Digest. 

Das bedeutet, dass Sie vergessen haben, die Client-Konfiguration bereitzustellen, so dass die vom Client verwendete Hadoop-Konfiguration immer noch die einfache Authentifizierung verwendet, Kerberos aber auf dem Cluster aktiviert ist. Gehen Sie zur Seite Cloudera Manager und stellen Sie die Client-Konfiguration bereit.

1. Kein Kerberos-Ticket für den Benutzer verfügbarError:

$ hadoop fs -ls
14/02/05 12:05:47 ERROR security.UserGroupInformation: PriviledgedActionException as:cloudera  (auth:KERBEROS)  Ursache:javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]
14/02/05 12:05:47 WARN ipc.Client: Exception aufgetreten  während  Verbindung zum Server : javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]
14/02/05 12:05:47 ERROR security.UserGroupInformation: PriviledgedActionException as:cloudera  (auth:KERBEROS)  Ursache:java.io.IOException: javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Keine gültigen Anmeldeinformationen angegeben  (Ebene des Mechanismus: Kerberos tgt konnte nicht gefunden werden)]

Sie versuchen, auf HDFS zuzugreifen, aber Ihr Benutzer hat kein Kerberos-Ticket oder Ihr Ticket ist abgelaufen. Verwenden Sie kinit, um ein neues Ticket zu erhalten.

1. Hue Kerberos-Ticket kann nicht erneuert werdenInden Protokollen von Hue für den Kerberos Ticket Renewer sehen Sie einen Fehler:

KönnteSie müssen das Kerberos-Ticket nicht erneuern, um das Problem mit Kerberos 1.8.1 zu umgehen. Bitte überprüfen Sie, ob das Ticket für ' hue/host1.meinedomain.nl' ist immer noch erneuerbar:
  $ kinit -f -c /tmp/hue_krb5_ccache
Wenn die 'erneuern  bis' ist das gleiche Datum wie das 'gültig ab', kann das Ticket nicht erneuert werden. Bitte überprüfen Sie Ihre KDC-Konfiguration und die Ticketverlängerungsrichtlinie (maxrenewlife) für das ' hue/host1.meinedomain.nl' und `krbtgt'  Direktoren

Dieser Fehler bedeutet, dass Ihre Tickets nicht erneuerbar sind. Verwenden Sie kadmin, um das hue-Zertifikat erneuerbar zu machen. Schnelle Lösung:

$ kinit tunde/admin
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable krbtgt/GDD.NL
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable hue/host1.mydomain.nl

Wir müssen den krbtgt-Principal für unseren Realm aktualisieren, da das KDC keine Tickets mit einer längeren Lebensdauer als der des krbtgt-Principals ausgeben kann.

Siehe Erklärung unter Kerberos-Grundlagen und Installation eines KDC

1. Cloudera hat keine keytab oder das KDC ist in /etc/krb5.conf nicht korrekt konfiguriert. WennSie versuchen, die keytabs mit Cloudera Manager zu generieren, erhalten Sie die Fehlermeldung:

/usr/share/cmf/bin/gen_credentials.sh schlug fehl mit  Ausgang  Code  1  und Produktion von Export  PATH=/usr/kerberos/bin:/usr/kerberos/sbin:/usr/lib/mit/sbin:/usr/sbin:/sbin:/usr/sbin:/bin:/usr/bin
+  PATH=/usr/kerberos/bin:/usr/kerberos/sbin:/usr/lib/mit/sbin:/usr/sbin:/sbin:/usr/sbin:/bin:/usr/bin
+  CMF_REALM=GDD.NL
+  KEYTAB_OUT=/var/run/cloudera-scm-server/cmf1349528239326605533.keytab
+  PRINZ=HTTP/host1.mydomain.nl@GDD.NL
+  KADMIN='kadmin -k -t /etc/cloudera-scm-server/cmf.keytab -p cloudera-scm/admin@GDD.NL -r GDD.NL'
+ kadmin -k -t /etc/cloudera-scm-server/cmf.keytab -p cloudera-scm/admin@GDD.NL -r GDD.NL -q  'addprinc -randkey HTTP/host1.mydomain.nl@GDD.NL'
Könnte't open log file /var/log/kadmind.log: Berechtigung verweigert
kadmin: Client nicht in Kerberos-Datenbank gefunden  während  Initialisierung der kadmin Schnittstelle

Überprüfen Sie, ob cloudera-scm über ein gültiges Zertifikat verfügt (es kann sein, dass Sie die KDB neu erstellt haben, während Sie ein Problem behoben haben, und dabei vergessen haben, den Benutzer cloudera-scm anzulegen und die Keytab zu generieren), oder es kann sein, dass Sie in der Datei /etc/krb5.conf nicht den richtigen Hostnamen konfiguriert haben, so dass der Cloudera Manager den KDC nicht finden kann.

1. JCE nicht installiert Fehler im Protokoll des Nameservers:

INFO org.apache.hadoop.ipc.Server: IPC Server Listener auf 8022: readAndProcess hat die Ausnahme javax.security.sasl.SaslException ausgelöst: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Nicht spezifizierter Fehler auf GSS-API-Ebene  (Ebene des Mechanismus: Verschlüsselung  Typ  AES256 CTS-Modus mit HMAC SHA1-96 wird nicht unterstützt/aktiviert)]  vom Client 127.0.0.1. Anzahl der gelesenen Bytes: 0 
javax.security.sasl.SaslException: GSS initiate fehlgeschlagen  [Verursacht durch GSSException: Nicht spezifizierter Fehler auf GSS-API-Ebene  (Ebene des Mechanismus: Verschlüsselung  Typ  AES256 CTS-Modus mit HMAC SHA1-96 wird nicht unterstützt/aktiviert)]
  at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:159)

Die Lösung ist die Installation der Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File, wie im Abschnitt JCE beschrieben.

1. Falsch konfigurierte Verschlüsselung bei der Einrichtung von realmübergreifendem Vertrauen Als wir versuchten, einen Verzeichniseintrag mit zu erhalten:

hadoop fs -ls

erhielten wir eine Fehlermeldung, die wir nicht verstehen konnten (leider habe ich vergessen, eine Auflistung davon zu erstellen...sorry). Um die Fehlerdetails zu sehen, haben wir die Protokollierungsstufe eingestellt:

$  exportieren HADOOP_OPTS="-Dsun.security.krb5.debug=true"
$ hadoop fs -ls

>>>KRBError:
  sTime ist Di Feb  07  16:16:36 CET  2014  1389107796000
  suSec ist 681067
  Fehlercode ist 14
  Fehlermeldung ist KDC hat keine Unterstützung  für  Verschlüsselung  Typ
  Das Reich ist WIN_GDD.NL
  sname ist krbtgt/GDD.NL
  msgType ist 30
>>>  Berechtigungsnachweise acquireServiceCreds: no tgt;  Rückwärts suchen
>>>  Berechtigungsnachweise acquireServiceCreds: no tgt;  kann keinen Kredit bekommen
KrbException: Die Erstellung des Credentials ist fehlgeschlagen.  (63)  - Kein Dienstausweis
  at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:279)
  at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:557)
  at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:594)
  at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:230)
  at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
  at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:175)
  at org.apache.hadoop.security.SaslRpcClient.saslConnect(SaslRpcClient.java:137)
  at org.apache.hadoop.ipc.Client$Connection.setupSaslConnection(Client.java:446)
  at org.apache.hadoop.ipc.Client$Connection.access$1300(Client.java:241)
  at org.apache.hadoop.ipc.Client$Connenverbindung$2.laufen(Client.java:612)
  at org.apache.hadoop.ipc.Client$Connenanschluss$2.laufen(Client.java:609)
  at java.security.AccessController.doPrivileged(Einheimische Methode)
  at javax.security.auth.Subject.doAs(Betreff.java:396)
  at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)
  at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:608)
  at org.apache.hadoop.ipc.Client$Connection.access$2000(Client.java:241)
  at org.apache.hadoop.ipc.Client.getConnection(Client.java:1278)
  at org.apache.hadoop.ipc.Client.call(Client.java:1196)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)
  bei $Proxy9.getFileInfo(Unbekannte Quelle)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Einheimische Methode)
  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Methode.java:597)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)
  bei $Proxy9.getFileInfo(Unbekannte Quelle)

Es stellte sich heraus, dass ich nur DES-Verschlüsselung eingestellt hatte. Ich habe den krbtgt/GDD.NL@WIN_GDD.NL Prinzipal auf dem Kerberos KDC gelöscht.

Ich habe die

ksetup /SetEncTypeAttr GDD.NL AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-MD5 DES-CBC-MD5 DES-CBC-CRC

auf dem Active Directory-Host.

Und dann den Principal auf dem Kerberos-Server neu erstellt

kadmin: addprinc -e  "aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal"  krbtgt/GDD.NL@WIN_GDD.NL

Fazit

Es ist möglich, Kerberos und AD in den Cloudera Manager zu integrieren. Zunächst mag es beängstigend und kompliziert erscheinen, aber nachdem Sie es einmal herausgefunden haben, werden Sie feststellen, dass es gar nicht so schwer ist.

Ich würde Ihnen dringend raten, ein Tool für die automatische Bereitstellung zu verwenden, wie Ansible, Chef oder Puppet. Ich habe Ihnen die Schritte gezeigt, die Sie mit Bash-Befehlen ausführen müssen. Wenn Sie aber einen Cluster mit 6 Knoten haben, möchten Sie bereits in der Lage sein, die Bereitstellung von einem zentralen Rechner aus vorzunehmen und auf die übrigen Rechner zu verteilen. Es stellt auch sicher, dass Sie weniger Fehler machen... oder zumindest auf allen Rechnern denselben Fehler haben :).

Im nächsten Blog werde ich beschreiben, wie wir Samba und SSSD konfigurieren, um einen Domänencontroller zu erstellen und den Kerberos KDC-Server zu ersetzen. Natürlich erfordert diese Lösung auch eine gewisse Konfiguration, damit der Cloudera Manager die Zertifikate korrekt generieren kann.