Das Thema Security nimmt in der heutigen Zeit stetig an Bedeutung zu. Auch im Cloudera-Cluster-Umfeld gibt es Mechanismen und Features, welche dazu beitragen können, die Kommunikation innerhalb und außerhalb des Clusters abzusichern.

Die Basis bilden dabei die Authentisierung, die Authentifizierung und die Autorisierung. Heißt also, dass vom User zuerst der Nachweis einer Identität erbracht werden muss (Authentisierung). Das kann z.B. mithilfe eines Benutzernamens & Passworts geschehen. Danach erfolgt durch die Authentifikation die Verifizierung der Identität des Users, um festzustellen und zu bestätigen, dass diese auch echt ist (Authentifizierung). Nachdem die Identität bestätigt ist, können dem User Rechte zugeteilt werden (Autorisierung).

In einem Cloudera-Cluster können Authentisierung und Authentifizierung mithilfe von Kerberos umgesetzt werden. Das ist einmal bezogen auf die User, die mit dem Cluster interagieren, und einmal auf die Dienste des Clusters selbst. Die Autorisierung wird durch den jeweiligen Dienst umgesetzt. Es kann aber zum Beispiel Sentry verwendet werden, um zentral für verschiedene Dienste die Rechte der unterschiedlichen User zu verwalten [1].

Weiterführende Informationen zu den Grundlagen von Kerberos können in früheren ORDIX news Artikeln nachgelesen werden (1) (2) (3). Ein Überblick über einige Security-Mechanismen im Hadoop-Bereich bietet ein ORDIX news Artikel gelistet in (4). 

Einleitung - Cloudera-Cluster kerberisiert

Dieser Blogartikel beschreibt, wie ein Cloudera-Cluster kerberisiert werden kann, wenn als Kerberos-KDC die Implementierung des Microsoft Active Directory verwendet wird.

Dabei wird angenommen, dass der Cloudera Cluster schon fertig eingerichtet ist und im Cluster mit der Kerberisierung begonnen werden kann. Zusätzlich wird das Thema Microsoft Active Directory aus Cluster-Sicht beschrieben und somit auf eine detaillierte Beschreibung der dortigen Umsetzung verzichtet.

Zuerst wird beschrieben, was im Microsoft Active Directory alles benötigt wird, damit der Cloudera Cluster mit seinen Diensten Kerberos verwenden kann. Danach werden die Voraussetzungen auf der Linux-Ebene aufgelistet. Zum Schluss wird beschrieben, wie die Kerberisierung über den Cloudera Manager vorgenommen werden kann.

Voraussetzungen in der Microsoft Active Directory

Im Active Directory müssen verschiedene Voraussetzungen erfüllt sein, damit die Kerberisierung erfolgen kann.

Zuerst muss eine OU festgelegt werden, in der später User-Objekte durch den Cloudera Manager angelegt werden können. Es wird empfohlen, eine separate OU zu nutzen, welche nur für diesen Zweck erstellt wurde. Bsp:

OU=CDH,OU=PLATFORM,OU=SERVICE,DC=AD,DC=ORDIX,DC=DE

Dann muss ein User bereitgestellt werden, welcher in dieser OU User-Objekte anlegen darf, also dort Schreibrechte(!) hat. Dieser wird später vom Cloudera Manager für das Anlegen der User-Objekte verwendet. Diese User-Objekte repräsentieren die einzelnen Komponenten auf den einzelnen Hosts. Das heißt, dass eine größere Anzahl an Objekten angelegt werden kann. Die Anzahl ist dabei abhängig von der Anzahl der registrierten Hosts und der Anzahl an verwendeten Diensten und installierten Instanzen.

Des Weiteren muss die Kerberos Ticket Lifetime und die Kerberos Renewal Lifetime größer 0 sein. Als Beispiel sollen hier 10 Stunden für die Ticket Lifetime und 7 Tage für die Renewal Lifetime dienen. Die maximalen Werte sind dem AD zu entnehmen.

Bei der Kerberos Ticket Lifetime handelt es ich um die Zeitspanne, in der das Ticket maximal gültig ist. In diesem Beispiel könnte das Ticket also maximal 7 Tage verwendet werden. Danach muss ein neues angefordert werden.

Kerberos Renewal Lifetime ist die Zeitspanne, nach deren Ablauf das Ticket erneuert werden muss. Damit ist keine Anforderung eines neuen Tickets gemeint, sondern eine Verlängerung der Verwendbarkeit des bestehenden Tickets. In diesem Beispiel wären es 10 Stunden, was bedeutet, dass spätestens alle 10 Stunden das Ticket erneuert werden muss, damit es weiterverwendet werden kann. Dabei können in Summe die vorher festgelegten 7 Tage nicht überschritten werden.

Voraussetzungen auf Linux-Ebene

Auf der Betriebssystem-Ebene müssen verschiedene Pakete installiert werden [2]:

​Distribution​	​Paket​
​RHEL 6/7 ​	​Auf dem Utility-Host: openldap-clients Auf allen Cluster-Hosts: krb5-workstation krb5-libs ​
​SLES​	​Auf dem Utility-Host: openldap2-client Auf allen Cluster-Hosts: krb5-client ​
​Ubuntu​	​Auf dem Utility-Host: ldap-utils Auf allen Cluster-Hosts: krb5-user ​

Dabei wird unterschieden zwischen Cluster-Hosts und Utility-Hosts. Mit Cluster-Hosts sind alle Hosts gemeint, die dem Cluster zugeordnet sind. Mit Utility-Host ist der Host gemeint, auf dem der Cloudera Manager ausgeführt wird. Die unterschiedlichen Host-Rollen werden in der Cloudera Dokumentation ausführlich beschrieben [3].

Exemplarisch für die Pakete von RHEL 6/7 hier kurz erläutert:

Das Paket openldap-clients beinhaltet Kommandozeilenwerkzeuge, um mit einem LDAP-Server zu kommunizieren.

Das Paket krb5-workstations beinhaltet die grundlegenden Kommandozeilenwerkzeuge, um mit dem KDC zu interagieren.

Das Paket krb5-libs beinhaltet Shared-Libs, welche für Kerberos 5 benötigt werden.

Durchführung der Kerberisierung

Die Kerberisierung wird, wie initial schon angemerkt, über den Cloudera Manager durchgeführt. Dabei muss der angemeldete User über volle Administrationsrechte verfügen.

Im Cloudera Manager auf "Administration" -> "Security" klicken.

Danach den Button „Enable Kerberos" betätigen.

Seite Setup KDC:

​Parameter	​Wert
​KDC-Type	​Active Directory
​Kerberos-Verschlüsselungstypen	​aes256-cts, aes128-cts
​Kerberos Security Realm	​AD.ORDIX.DE
​KDC Server Host	​adserver.ordix.de
​KDC Admin Server Host	​adserver.ordix.de
​Domain Names	​ordix.de
​Active Directory Suffix	​OU=CDH, OU=PLATFORM, OU=SERVICE, DC=AD, DC=ORDIX, DC=DE
​Active Directory Delete Accounts on Credential Regeneration	​Aktivieren
​Active Directory Set Encryption Types	​Aktivieren
​Active Directory Password Properties	​So lassen, wenn nicht anders gefordert.
​Active Directory Account Properties	​So lassen, wenn nicht anders gefordert.
​Active Directory Account Prefix	​cloudera -cluster-1

Nach dem Ausfüllen auf „Continue" klicken.

Seite Manage krb5.conf:

Sofern diese vom CM verwaltet werden soll, dies aktivieren und entsprechende Konfiguration hinterlegen.

Ansonsten muss dafür gesorgt werden, dass die Datei /etc/krb5.conf auf jedem Host immer auf dem neusten und gleichen Stand ist.

Danach auf „Continue" klicken.

Seite Setup KDC Account:

Einfügen des erstellten Accounts aus dem Active Directory.

Dabei muss der Principal + Realm eingetragen werden.

Bsp: cloudera-user-gen@AD.ORDIX.DE

Und dazu dann das passende Passwort eintragen.

Danach auf „Continue" klicken.

Der Cloudera Manager fängt nun an die Konfiguration umzusetzen und den Cluster so zu konfigurieren, dass er Kerberos verwenden und mit dem KDC des Active Directory kommunizieren kann.

Nach der erfolgreichen Umsetzung erfolgt die Kommunikation im Cluster wie in Abbildung 1 betrachtet werden kann.

Der grundlegende Vorgang ist damit abgeschlossen.

Interaktion mit einem kerberisierten Cluster

Da der Cluster nun kerberisiert ist, muss der User ein Ticket besitzen, bevor er auf die einzelnen Dienste zugreifen kann. Als Beispiel kann die Ausgabe eines „hdfsdfs -ls /" betrachtet werden, wenn kein Ticket im Besitz des Users ist:

In diesem Fall muss also vorher mittels des „kinit" Befehls für den User ein Ticket geholt werden. Ohne diese Maßnahme der Authentifizierung ist kein Zugriff mehr möglich.

Die Kontrolle, ob der User ein Ticket besitzt, kann über das Kommando „klist" geprüft werden.

Für selbst entwickelte Software muss darauf geachtet werden, dass diese die Interaktion mit einem kerberisierten Cluster unterstützt. Sofern dies nicht der Fall ist, muss sie angepasst werden.

Ausblick

Nachdem der Cluster erfolgreich kerberisiert wurde, kann z.B. die Autorisierung mit Sentry umgesetzt werden. Des Weiteren ist es möglich die User über SSSD an die Server anzubinden [4]. Dieser Dienst kann so konfiguriert werden, dass er die User aus dem AD im Linux-OS verfügbar macht und diese verwendet werden können, als wären es lokale User (Login, Rechtemanagement etc.). Der Vorteil ist, dass dadurch beim Login via SSH des Users auf den entsprechenden Servern direkt ein Ticket geholt werden kann. Somit muss sich der User nur begrenzt mit dieser Thematik auseinandersetzen, solange die entsprechenden Gültigkeitszeiten innerhalb der SSH-Session nicht überschritten werden.