Kerberos-Architekturoptionen mit Amazon EMR - Amazon EMR
Cluster-dediziertes KDCBereichsübergreifende VertrauensstellungExternes KDCMehrere Cluster mit demselben KDC

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kerberos-Architekturoptionen mit Amazon EMR

Wenn Sie Kerberos mit Amazon EMR verwenden, können Sie aus den in diesem Abschnitt aufgeführten Architekturen wählen. Unabhängig von der gewählten Architektur konfigurieren Sie Kerberos anhand der gleichen Schritte. Sie erstellen eine Sicherheitskonfiguration, legen die Sicherheitskonfiguration und kompatible Cluster-spezifische Kerberos-Optionen fest, wenn Sie den Cluster erstellen. Zudem erstellen Sie HDFS-Verzeichnisse für Linux-Benutzer auf dem Cluster, der den Benutzerprinzipalen auf dem KDC entspricht. Weitere Informationen zu Konfigurationsoptionen und Beispielkonfigurationen für jede Architektur finden Sie unter Konfiguration von Kerberos in Amazon EMR.

Cluster-spezifisches KDC (KDC auf dem Primärknoten)

Diese Konfiguration ist nur mit Amazon-EMR-Versionen 5.10.0 und höher verfügbar.

Amazon EMRCluster architecture with master node, core nodes, and task node within a Kerberos realm.
Vorteile

  • Amazon EMR ist im vollständigen Besitz des KDC.

  • Das KDC auf dem EMR-Cluster ist unabhängig von zentralisierten KDC-Implementierungen wie Microsoft Active Directory oder AWS Managed Microsoft AD.

  • Die Auswirkungen auf die Performance sind minimal, da das KDC die Authentifizierung nur für lokale Knoten innerhalb des Clusters verwaltet.

  • Optional können andere Kerberos-Cluster auf das KDC als externes KDC verweisen. Weitere Informationen finden Sie unter Externes KDC – Primärknoten auf einem anderen Cluster.

Überlegungen und Einschränkungen

  • Kerberos-Cluster können einander nicht authentifizieren, sodass für die Anwendungen keine Interoperabilität besteht. Wenn Cluster-Anwendungen interagieren müssen, müssen Sie eine bereichsübergreifende Vertrauensstellung zwischen Clustern oder einen Cluster als externes KDC für andere Cluster einrichten. Wenn eine realmübergreifende Vertrauensstellung eingerichtet wird, KDCs müssen sie über unterschiedliche Kerberos-Bereiche verfügen.

  • Sie müssen Linux-Benutzer auf der EC2 Instanz des primären Knotens erstellen, die den KDC-Benutzerprinzipalen entsprechen, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.

  • Benutzerprinzipale müssen eine EC2 private Schlüsseldatei und kinit Anmeldeinformationen verwenden, um über SSH eine Verbindung zum Cluster herzustellen.

Bereichsübergreifende Vertrauensstellung

In dieser Konfiguration werden Prinzipale (in der Regel Benutzer) aus einem anderen Kerberos-Bereich an den Anwendungskomponenten auf einem durch Kerberos geschützten EMR-Cluster authentifiziert, der über ein eigenes KDC verfügt. Der KDC auf dem primären Knoten baut mithilfe eines realmübergreifenden Prinzipals, der in beiden vorhanden ist, eine Vertrauensstellung mit einem anderen KDC auf. KDCs Der Name des Prinzipals und das Passwort stimmen in jedem KDC genau überein. Bereichsübergreifende Vertrauensstellungen kommen am häufigsten in Active Directory-Implementierungen vor, wie in der folgenden Abbildung dargestellt. Bereichsübergreifende Vertrauensstellungen mit einem externen MIT KDC oder einem KDC auf einem anderen Amazon–EMR Cluster werden ebenfalls unterstützt.

Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.
Vorteile

  • Der EMR-Cluster, auf dem das KDC installiert ist, ist im vollständigen Besitz des KDC.

  • Mit Active Directory erstellt Amazon EMR automatisch Linux-Benutzer, die Benutzerprinzipalen aus dem KDC entsprechen. Sie müssen dennoch für jeden Benutzer HDFS-Verzeichnisse erstellen. Darüber hinaus können Benutzerprinzipale in der Active Directory-Domäne mithilfe von kinit Anmeldeinformationen ohne die private Schlüsseldatei auf kerberisierte Cluster zugreifen. EC2 Dies beseitigt die Notwendigkeit, die Datei mit dem privaten Schlüssel für die Cluster-Benutzer freizugeben.

  • Da jedes Cluster-KDC die Authentifizierung für die Knoten im Cluster verwaltet, werden die Auswirkungen der Netzwerklatenz und des Verwaltungsaufwands für eine große Anzahl an Knoten in Clustern minimiert.

Überlegungen und Einschränkungen

  • Wenn Sie eine Vertrauensstellung mit einem Active-Directory-Bereich einrichten, müssen Sie beim Erstellen des Clusters Active Directory-Benutzername und -Passwort mit Berechtigungen zum Hinzufügen von Prinzipalen zur Domain angeben.

  • Bereichsübergreifende Vertrauensstellungen können nicht zwischen Kerberos-Bereichen mit demselben Namen eingerichtet werden.

  • Bereichsübergreifende Vertrauensstellungen müssen explizit eingerichtet werden. Beispiel: Wenn Cluster A und Cluster B eine bereichsübergreifende Vertrauensstellung mit einem KDC einrichten, vertrauen diese einander nicht inhärent und ihre Anwendungen können einander nicht authentifizieren, um miteinander zu interagieren.

  • KDCs müssen unabhängig verwaltet und koordiniert werden, sodass die Anmeldeinformationen der Benutzerprinzipale exakt übereinstimmen.

Externes KDC

Konfigurationen mit einem externen KDC werden mit Amazon EMR 5.20.0 und höher unterstützt.

Externes KDC – MIT KDC

Diese Konfiguration ermöglicht mindestens einem EMR-Cluster die Verwendung von Prinzipalen, die in einem MIT KDC-Server definiert und verwaltet werden.

Amazon EMRCluster architecture with Kerberos realm, showing master, core, and task nodes.
Vorteile

  • Die Verwaltung von Prinzipalen ist in einem einzigen KDC zusammengefasst.

  • Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC.

  • Der Primärknoten auf einem durch Kerberos geschützten Cluster hat nicht die Performance-Einbußen zu verzeichnen wie der Unterhalt des KDC.

Überlegungen und Einschränkungen

  • Sie müssen Linux-Benutzer auf der EC2 Instanz des primären Knotens jedes Kerberized-Clusters erstellen, die den KDC-Benutzerprinzipalen entsprechen, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.

  • Benutzerprinzipale müssen eine EC2 private Schlüsseldatei und kinit Anmeldeinformationen verwenden, um über SSH eine Verbindung zu Kerberized-Clustern herzustellen.

  • Jeder Knoten in durch Kerberos geschützten EMR-Clustern muss über eine Netzwerkroute zum KDC verfügen.

  • Jeder -Knoten in durch Kerberos geschützten Clustern platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.

  • Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in durch Kerberos geschützten Clustern und dem KDC ab.

  • Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.

Externes KDC – Primärknoten auf einem anderen Cluster

Diese Konfiguration ist nahezu identisch mit der oben erwähnten externen MIT KDC-Implementierung, mit der Ausnahme, dass sich das KDC auf dem Primärknoten eines EMR-Clusters befindet. Weitere Informationen erhalten Sie unter Cluster-spezifisches KDC (KDC auf dem Primärknoten) und Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain.

Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.
Vorteile
Überlegungen und Einschränkungen

  • Sie müssen Linux-Benutzer auf der EC2 Instanz des primären Knotens jedes Kerberized-Clusters erstellen, die den KDC-Benutzerprinzipalen entsprechen, zusammen mit den HDFS-Verzeichnissen für jeden Benutzer.

  • Benutzerprinzipale müssen eine EC2 private Schlüsseldatei und kinit Anmeldeinformationen verwenden, um über SSH eine Verbindung zu Kerberized-Clustern herzustellen.

  • Jeder Knoten in jedem EMR-Cluster muss über eine Netzwerkroute zum KDC verfügen.

  • Jeder Amazon-EMR-Knoten in durch Kerberos geschützten Clustern platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.

  • Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in den Clustern und dem KDC ab.

  • Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.

Externes KDC – Cluster-KDC mit anderer bereichsübergreifender Active-Directory-Vertrauensstellung

Bei dieser Konfiguration erstellen Sie zunächst einen Cluster mit einem Cluster-spezifischen KDC, das eine unidirektionale bereichsübergreifende Vertrauensstellung mit Active Directory aufweist. Ein detailliertes Tutorial finden Sie unter Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain. Anschließend starten Sie zusätzliche Cluster, die auf das Cluster-KDC verweisen, das die Vertrauensstellung als externes KDC besitzt. Ein Beispiel finden Sie unter Externes Cluster-KDC mit bereichsübergreifender Active-Directory-Vertrauensstellung. Auf diese Weise können Sie jedem Amazon-EMR-Cluster, der das externe KDC verwendet, die Authentifizierung von Prinzipalen erlauben, die in einer Domain von Microsoft Active Directory definiert und verwaltet werden.

Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.
Vorteile

  • Die Verwaltung von Prinzipalen ist in der Active-Directory-Domain zusammengefasst.

  • Amazon EMR tritt dem Active-Directory-Bereich bei. Dadurch müssen keine Linux-Benutzer mehr erstellt werden, die Active-Directory-Benutzern entsprechen. Sie müssen dennoch für jeden Benutzer HDFS-Verzeichnisse erstellen.

  • Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC.

  • Benutzerprinzipale in der Active Directory-Domäne können mithilfe von kinit Anmeldeinformationen ohne die private Schlüsseldatei auf kerberisierte Cluster zugreifen. EC2 Dies beseitigt die Notwendigkeit, die Datei mit dem privaten Schlüssel für die Cluster-Benutzer freizugeben.

  • Da nur ein einziger Amazon-EMR-Primärknoten für die KDC-Verwaltung verantwortlich ist, muss nur dieser Cluster mit Active-Directory-Anmeldeinformationen erstellt werden, um die bereichsübergreifende Vertrauensstellung zwischen dem KDC und Active Directory herzustellen.

Überlegungen und Einschränkungen

  • Jeder Knoten in jedem EMR-Cluster muss über eine Netzwerkroute zum KDC und den Active-Directory-Domain-Controller verfügen.

  • Jeder Amazon-EMR-Knoten platziert auf dem externen KDC eine Authentifizierungshürde, sodass die Konfiguration des KDC sich auf die Cluster-Performance auswirkt. Berücksichtigen Sie bei der Konfiguration der Hardware des KDC-Servers die maximale Anzahl der Amazon-EMR-Knoten, die gleichzeitig unterstützt werden können.

  • Die Cluster-Performance hängt von der Netzwerklatenz zwischen Knoten in den Clustern und dem KDC-Server ab.

  • Die Fehlerbehebung kann sich aufgrund von Abhängigkeiten untereinander schwieriger gestalten.

Anforderungen für die Verwendung mehrerer Cluster mit demselben KDC

Mehrere Cluster können dasselbe KDC im selben Kerberos-Bereich verwenden. Wenn die Cluster jedoch gleichzeitig ausgeführt werden, schlagen die Cluster möglicherweise fehl, wenn sie ServicePrincipal Kerberos-Namen verwenden, die zu Konflikten führen.

Wenn Sie mehrere gleichzeitige Cluster mit demselben externen KDC haben, stellen Sie sicher, dass die Cluster unterschiedliche Kerberos-Bereiche verwenden. Wenn die Cluster denselben Kerberos-Bereich verwenden müssen, stellen Sie sicher, dass sich die Cluster in unterschiedlichen Subnetzen befinden und dass sich ihre CIDR-Bereiche nicht überschneiden.