Kerberos-Architektur-Optionen

Wenn Sie Kerberos mit Amazon verwendenEMR, 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, geben die Sicherheitskonfiguration und die kompatiblen clusterspezifischen Kerberos-Optionen an, wenn Sie den Cluster erstellen, und Sie erstellen HDFS Verzeichnisse für Linux-Benutzer auf dem Cluster, die den Benutzerprinzipalen im entsprechen. KDC Weitere Informationen zu Konfigurationsoptionen und Beispielkonfigurationen für jede Architektur finden Sie unter Konfiguration von Kerberos auf Amazon EMR.

Clusterspezifisch KDC (auf dem primären Knoten) KDC

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

Vorteile

• Amazon EMR hat das volle Eigentum an derKDC.

• 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 Leistung sind minimal, da die Authentifizierung nur für lokale Knoten innerhalb des Clusters KDC verwaltet wird.

• Optional können andere Kerber-Cluster auf den KDC als externe Cluster verweisen. KDC Weitere Informationen finden Sie unter Extern KDC — primärer Knoten 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 Clusteranwendungen zusammenarbeiten müssen, müssen Sie eine realmübergreifende Vertrauensstellung zwischen Clustern einrichten oder einen Cluster als externen KDC Cluster für andere Cluster einrichten. Wenn eine realmübergreifende Vertrauensstellung eingerichtet ist, 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 eine Verbindung zum Cluster herzustellen. SSH

Bereichsübergreifende Vertrauensstellung

In dieser Konfiguration authentifizieren sich Prinzipale (normalerweise Benutzer) aus einem anderen Kerberos-Bereich bei Anwendungskomponenten auf einem Kerberisierten Cluster, der über einen eigenen verfügtEMR. KDC Der Knoten KDC auf dem Primärknoten stellt KDC mithilfe eines realmübergreifenden Prinzipals, der in beiden vorhanden ist, eine Vertrauensbeziehung zu einem anderen Knoten her. KDCs Der Prinzipalname und das Passwort stimmen jeweils KDC exakt überein. Bereichsübergreifende Vertrauensstellungen kommen am häufigsten in Active Directory-Implementierungen vor, wie in der folgenden Abbildung dargestellt. Realmübergreifende Vertrauensstellungen mit einem externen MIT KDC oder einem KDC anderen EMR Amazon-Cluster werden ebenfalls unterstützt.

Vorteile

• Der EMR Cluster, auf dem der installiert KDC ist, behält den vollen Besitz von. KDC

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

• Da jeder Cluster die Authentifizierung für die Knoten im Cluster KDC verwaltet, werden die Auswirkungen der Netzwerklatenz und des Verarbeitungsaufwands für eine große Anzahl von 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. Wenn Cluster A und Cluster B beispielsweise beide eine realmübergreifende Vertrauensstellung mit a einrichtenKDC, vertrauen sie einander nicht grundsätzlich, und ihre Anwendungen können sich nicht gegenseitig authentifizieren, um zusammenzuarbeiten.

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

Extern KDC

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

• Extern — KDC MIT KDC

• Extern KDC — primärer Knoten auf einem anderen Cluster

• Extern KDC — Cluster KDC auf einem anderen Cluster mit realmübergreifender Active Directory-Vertrauensstellung

Extern — KDC MIT KDC

Diese Konfiguration ermöglicht es einem oder mehreren EMR Clustern, Prinzipale zu verwenden, die in einem MIT KDC Server definiert und verwaltet werden.

Vorteile

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

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

• Der primäre Knoten in einem kerberisierten Cluster hat nicht die Leistungsbelastung, die mit der Wartung von verbunden ist. KDC

Überlegungen und Einschränkungen

• Sie müssen auf der EC2 Instanz des primären Knotens jedes Kerberized-Clusters Linux-Benutzer 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 eine Verbindung zu Kerberized-Clustern herzustellen. SSH

• Jeder Knoten in kerberisierten EMR Clustern muss über eine Netzwerkroute zum verfügen. KDC

• Jeder Knoten in kerberisierten Clustern belastet den externen Knoten durch die AuthentifizierungKDC, sodass sich die Konfiguration des Clusters auf die Clusterleistung auswirkt. KDC Wenn Sie die Hardware des KDC Servers konfigurieren, sollten Sie die maximale Anzahl von EMR Amazon-Knoten berücksichtigen, die gleichzeitig unterstützt werden sollen.

• Die Clusterleistung hängt von der Netzwerklatenz zwischen Knoten in kerberisierten Clustern und dem ab. KDC

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

Extern KDC — primärer Knoten auf einem anderen Cluster

Diese Konfiguration ist fast identisch mit der obigen externen MIT KDC Implementierung, mit der Ausnahme, dass sie KDC sich auf dem primären Knoten eines EMR Clusters befindet. Weitere Informationen erhalten Sie unter Clusterspezifisch KDC (auf dem primären Knoten) KDC und Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain.

Vorteile

• Die Verwaltung von Principals ist in einem einzigen KDC System zusammengefasst.

• Mehrere Cluster können dasselbe KDC in demselben Kerberos-Bereich verwenden. Weitere Informationen finden Sie unter Anforderungen für die Verwendung mehrerer Cluster mit demselben 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 eine Verbindung zu Kerberized-Clustern herzustellen. SSH

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

• Jeder EMR Amazon-Knoten in kerberisierten Clustern belastet den externen Knoten mit einer AuthentifizierungslastKDC, sodass sich die Konfiguration des Clusters auf die KDC Cluster-Leistung auswirkt. Wenn Sie die Hardware des KDC Servers konfigurieren, sollten Sie die maximale Anzahl von EMR Amazon-Knoten berücksichtigen, die gleichzeitig unterstützt werden sollen.

• Die Cluster-Leistung hängt von der Netzwerklatenz zwischen den Knoten in den Clustern und dem abKDC.

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

Extern KDC — Cluster KDC auf einem anderen Cluster mit realmübergreifender Active Directory-Vertrauensstellung

In dieser Konfiguration erstellen Sie zunächst einen Cluster mit einem dedizierten Cluster, der über eine unidirektionale KDC realmübergreifende Vertrauensstellung mit Active Directory verfügt. Ein detailliertes Tutorial finden Sie unter Tutorial: Konfigurieren einer bereichsübergreifenden Vertrauensstellung mit einer Active-Directory-Domain. Anschließend starten Sie weitere Cluster und verweisen dabei auf den Cluster, dem die Vertrauensstellung zugewiesen wurdeKDC, als externen Cluster. KDC Ein Beispiel finden Sie unter Externer Cluster KDC mit realmübergreifender Active Directory-Vertrauensstellung. Auf diese Weise kann jeder EMR Amazon-Cluster, der das Externe verwendet, KDC um die in einer Microsoft Active Directory-Domäne definierten und verwalteten Prinzipale zu authentifizieren.

Vorteile

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

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

• Mehrere Cluster können dasselbe KDC in demselben 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.

• Nur ein EMR Amazon-Primärknoten ist für die Wartung des verantwortlichKDC, und nur dieser Cluster muss mit Active Directory-Anmeldeinformationen für die realmübergreifende Vertrauensstellung zwischen dem KDC und Active Directory erstellt werden.

Überlegungen und Einschränkungen

• Jeder Knoten in jedem EMR Cluster muss über eine Netzwerkroute zum KDC und zum Active Directory-Domänencontroller verfügen.

• Jeder EMR Amazon-Knoten belastet den externen Knoten mit einer AuthentifizierungslastKDC, sodass sich die Konfiguration des Clusters KDC auf die Cluster-Leistung auswirkt. Wenn Sie die Hardware des KDC Servers konfigurieren, sollten Sie die maximale Anzahl von EMR Amazon-Knoten berücksichtigen, die gleichzeitig unterstützt werden sollen.

• Die Cluster-Leistung hängt von der Netzwerklatenz zwischen den 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 in demselben 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 Cluster haben, stellen Sie sicherKDC, 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 Bereiche nicht überschneiden. CIDR