Engineering

So sichern Sie Ihre Elasticsearch-Cluster mit Kerberos

Von
Yogesh Gaikwad
•
Josh Bressers

Der wilde dreiköpfige Wachhund, der Ihre Daten vor unbefugtem Zugriff schützt

Seit Elasticsearch 6.4 können Platinum-Abonnenten die Authentifizierung mittels Kerberos-Protokoll nutzen. Dies ist der erste Schritt hin zu einem vollständig kerberisierten Elastic Stack. Kerberos ist eine ausgereifte Technologie, die die sichere Authentifizierung in verteilten Systemen ermöglicht. Mit Kerberos erhält der Benutzer nach einmaliger Eingabe von Benutzernamen und Passwort Zugriff auf eine Reihe von Diensten (Single Sign-on). In diesem Artikel erfahren Sie, wie Sie Elasticsearch so konfigurieren können, dass der HTTP-Datenverkehr durch die Kerberos-Authentifizierung geschützt wird.

Deployment-Überblick

Sehen wir uns ein einfaches Szenario an, in dem eine fiktive Benutzerin namens Alice einen Elasticsearch-Cluster mit einem einzigen Knoten betreibt. Alice hat bereits ein Kerberos-Realm namens demo.local und sie möchte die Kerberos-Authentifizierung nutzen, um den Elasticsearch-Cluster zu sichern. Der Kerberos-Authentifizierungsserver ist autorisiert, einen Benutzer, Host oder Dienst innerhalb des Realm zu authentifizieren. Die in diesem Artikel verwendeten Befehle beziehen sich auf die MIT-Kerberos-Implementierung. Weitere Informationen finden Sie in der MIT-Kerberos-Dokumentation.

In diesem einfachen Szenario gibt es drei Host-Maschinen:

– Host-1 (kdc.demo.local): Dies ist das Kerberos Key Distribution Center (KDC), das üblicherweise die Aufgaben des Authentifizierungsservers und des Servers für die Ticketausgabe (Ticket Granting Server) übernimmt. – Host-2 (es.demo.local): Dies ist der Ort des Elasticsearch-Clusters mit einem Knoten. – Host-3 (client.demo.local): Dies ist der Ort des Elasticsearch-Clients.

SimpleESKerberosDeployment

Die Kerberos-Authentifizierung besteht aus den folgenden Schritten:

  1. Alice (alice@DEMO.LOCAL) meldet sich mit ihrem Benutzernamen und ihrem Passwort bei der Client-Maschine (client.demo.local) an.
  2. Die Client-Maschine fordert vom KDC-Server (kdc.demo.local) ein Ticket Granting Ticket (TGT) an.
  3. Der Client greift auf den Elasticsearch-Service https://es.demo.local:9200 zu, der eine Antwort mit dem HTTP-Statuscode Unauthorized(401) zurückgibt und den Header WWW-Authenticate: Negotiate hinzufügt.
  4. Der Client fordert vom Ticket Granting Server (TGS) ein Sitzungsticket für den Elasticsearch-Dienstprinzipal HTTP/es.demo.local@DEMO.LOCAL an. Der Name des Elasticsearch-Dienstprinzipals wird aus der URL abgeleitet, mit der auf den Dienst zugegriffen wird.
  5. Der Client legt Elasticsearch dieses Ticket zur Authentifizierung vor.
  6. Elasticsearch prüft die Gültigkeit des Kerberos-Tickets und gewährt bei gültigem Ticket Zugriff.

Konfigurieren des Kerberos-Realm

Um mit dem Elasticsearch Kerberos-Realm arbeiten zu können, muss die vorhandene Kerberos-Infrastruktur bestimmte Voraussetzungen erfüllen:

– Die Uhren aller teilnehmenden Maschinen in der Domain laufen synchron. – Für alle teilnehmenden Maschinen gibt es eine funktionierende DNS-Domain. – Ein KDC-Server ist eingerichtet. – Es sind Client-Knoten mit Kerberos-Bibliotheken und -Konfigurationsdateien wie kinit und klist installiert.

Wenn Sie die entsprechende Kerberos-Infrastruktur installiert haben, benötigen wir jetzt die folgenden Informationen:

– Kerberos-Konfigurationsdateikrb5.conf: Diese Datei enthält die nötigen Angaben zu Ihrer Kerberos-Umgebung, wie Standard-Realm, KDC-Server und Domain-Realm-Mappings. Auf Linux-Systemen befindet sich diese Datei üblicherweise im Verzeichnis /etc. Für die JVM-Systemeigenschaft java.security.krb5.conf sollte der vollständige Pfad dieser Konfigurationsdatei festgelegt werden. Die JVM lädt diese Konfiguration und nutzt sie bei Bedarf, um erforderliche Informationen zu finden. – Elasticsearch-HTTP-Dienstkeytab: Eine Schlüsseltabelle (Key Table oder „Keytab“) ist eine Datei, in der Paare aus Prinzipalen und Verschlüsselungsschlüsseln gespeichert sind. Dies ist die Keytab, die vom Elasticsearch-HTTP-Dienst zum Validieren der von Clients eingehenden Tickets verwendet wird. Die Dienstprinzipalnamen haben in der Regel das Format HTTP/es.demo.local@DEMO.LOCAL, wobei HTTP die Dienstklasse, es.demo.local der vollqualifizierte Domain-Name für den Elasticsearch-Host und DEMO.LOCAL der Kerberos-Realm ist. Diese Datei muss im Elasticsearch-Konfigurationsverzeichnis abgelegt werden. Die Datei enthält die Anmeldeinformationen. Sichern Sie sie, indem Sie dem Benutzer, der Elasticsearch ausführt, lediglich Leserechte für die Datei gewähren. Die Keytab-Datei für Ihren Dienst erhalten Sie vom Kerberos-Systemadministrator.

Wenn wir diese beiden Dateien zur Hand haben, können wir als Nächstes den Kerberos-Realm in Elasticsearch konfigurieren.

1. JVM-Optionen konfigurieren

Als Erstes müssen wir die Datei mit den JVM-Optionen (jvm.options) bearbeiten, um die JVM-Systemeigenschaft für die Kerberos-Konfigurationsdatei zu konfigurieren:

# Kerberos configuration
-Djava.security.krb5.conf=/etc/krb5.conf

2. Elasticsearch für Kerberos konfigurieren

Als Nächstes müssen wir in der Datei elasticsearch.yml einen Kerberos-Realm hinzufügen:

# Kerberos realm
xpack.security.authc.realms.kerb1:
type: kerberos
    order: 1
    keytab.path: es.keytab

Damit wird der Kerberos-Realm (kerb1) des Typs kerberos mit der Realm-Ordnung 1 konfiguriert und festgelegt, dass der Keytab-Pfad (keytab.path) auf die Elasticsearch-Keytab-Datei (es.keytab) im Konfigurationsverzeichnis verweist. Weitere Informationen können Sie dem Artikel zum Konfigurieren des Kerberos-Realm entnehmen.

3. Elasticsearch neu starten

Nach dem Konfigurieren muss der Elasticsearch-Knoten neu gestartet werden.

4. Kerberos-Benutzer und Rollen einander zuordnen

Kerberos ist ein Authentifizierungsprotokoll, das keine Autorisierungsdetails bereitstellt. Zu Autorisierungszwecken können wir die Rollen-Mapping-API verwenden und Benutzern Rollen zuordnen. Mit dem folgenden Code erstellen wir ein Rollen-Mapping namens kerbrolemapping, bei dem der Benutzerin alice@DEMO.LOCAL die Rolle monitoring_user zugewiesen wird:

$ curl -u elastic -H "Content-Type: application/json" -XPOST http://es.demo.local:9200/_xpack/security/role_mapping/kerbrolemapping -d 

{
    "roles" : [ "monitoring_user" ],
    "enabled": true,
    "rules" : {
    "field" : { "username" : "alice@DEMO.LOCAL" }
    }
}

Wenn Sie mehr über das Rollen-Mapping erfahren möchten, lesen Sie den Artikel zum Zuordnen von Benutzern und Gruppen zu Rollen.

Voilà, es funktioniert!

Wenn wir prüfen wollen, ob die Authentifizierung auf der Client-Maschine funktioniert, können wir uns mithilfe des Befehls kinit ein TGT besorgen:

$ kinit alice@DEMO.LOCAL  
Password for alice@DEMO.LOCAL:  
$ klist  
Ticket cache: KEYRING:persistent:1000:krb_ccache_NvNtNgS  
Default principal: alice@DEMO.LOCAL  

Valid starting      Expires             Service principal
31/08/18 02:20:07   01/09/18 02:20:04   krbtgt/DEMO.LOCAL@DEMO.LOCAL

Then invoke curl with the negotiate parameter so that Kerberos authentication over HTTP can be performed:

$ curl --negotiate -u : -XGET http://es.demo.local:9200/

und siehe da:

{
    "name" : "Lw7K29R",
    "cluster_name" : "elasticsearch",
    "cluster_uuid" : "qd3iafXORLy0VCfVD_Hp9w",
    "version" : {
    "number" : "6.4.0",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "595516e",
    "build_date" : "2018-08-17T23:18:47.308994Z",
    "build_snapshot" : true,
    "lucene_version" : "7.4.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
    },
    "tagline" : "You Know, for Search"
}

Fazit

Wie wir gesehen haben, ist es recht einfach, ein Kerberos-Realm zu konfigurieren, sobald man Zugriff auf die Dienstprinzipal-Keytab und die Kerberos-Konfigurationsdatei hat. Für Elasticsearch werden nur ein paar Zeilen Kerberos-Realm-Konfiguration benötigt. Dass Kerberos in Elasticsearch unterstützt wird, ist nur der Anfang und wir werden mit der Zeit immer mehr Elastic Stack-Komponenten mit Kerberos-Unterstützung ausstatten. Dranbleiben lohnt sich!