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.

Grundlegendes zur Verschlüsselung bei der Übertragung

Sie können einen EMR-Cluster so konfigurieren, dass Open-Source-Frameworks wie Apache Spark, Apache Hive und Presto ausgeführt werden. Jedes dieser Open-Source-Frameworks verfügt über eine Reihe von Prozessen, die auf den EC2-Instances eines Clusters ausgeführt werden. Jeder dieser Prozesse kann Netzwerkendpunkte für die Netzwerkkommunikation hosten.

Wenn die Verschlüsselung während der Übertragung auf einem EMR-Cluster aktiviert ist, verwenden verschiedene Netzwerkendpunkte unterschiedliche Verschlüsselungsmechanismen. In den folgenden Abschnitten erfahren Sie mehr über die spezifischen Open-Source-Framework-Netzwerkendpunkte, die mit Verschlüsselung bei der Übertragung unterstützt werden, die zugehörigen Verschlüsselungsmechanismen und welche Amazon EMR-Version die Unterstützung hinzugefügt hat. Jede Open-Source-Anwendung verfügt möglicherweise auch über unterschiedliche bewährte Methoden und Open-Source-Framework-Konfigurationen, die Sie ändern können.

Um die Verschlüsselung während der Übertragung optimal abzudecken, empfehlen wir, sowohl die Verschlüsselung während der Übertragung als auch Kerberos zu aktivieren. Wenn Sie nur die Verschlüsselung bei der Übertragung aktivieren, ist die Verschlüsselung bei der Übertragung nur für die Netzwerkendpunkte verfügbar, die TLS unterstützen. Kerberos ist erforderlich, da einige Open-Source-Framework-Netzwerkendpunkte Simple Authentication and Security Layer (SASL) für die Verschlüsselung bei der Übertragung verwenden.

Beachten Sie, dass Open-Source-Frameworks, die in Amazon EMR 7.x.x-Versionen nicht unterstützt werden, nicht enthalten sind.

Spark

Wenn Sie die Verschlüsselung während der Übertragung in Sicherheitskonfigurationen aktivieren, spark.authenticate wird automatisch auf RPC-Verbindungen gesetzt true und verwendet AES-based Verschlüsselung.

Ab Amazon EMR 7.3.0 können Sie Spark-Anwendungen, die vom Hive-Metastore abhängig sind, nicht mehr verwenden, wenn Sie Verschlüsselung bei der Übertragung und Kerberos-Authentifizierung verwenden. Hive 3 behebt dieses Problem in. HIVE-16340 HIVE-44114behebt dieses Problem vollständig, wenn Open-Source-Spark auf Hive 3 aktualisiert werden kann. In der Zwischenzeit können Sie dies einstellen, hive.metastore.use.SSL um dieses false Problem zu umgehen. Weitere Informationen finden Sie unter Konfigurieren von Anwendungen.

Weitere Informationen finden Sie unter Spark-Sicherheit in der Apache Spark-Dokumentation.

^{1 wird auf YARN} spark.shuffle.service.port gehostet, aber nur von Apache NodeManager Spark verwendet.

Bekanntes Problem

Bei Clustern mit aktiviertem In-Transit verwendet die spark.yarn.historyServer.address Konfiguration derzeit den Port18080, wodurch der Zugriff auf die Benutzeroberfläche der Spark-Anwendung mithilfe der YARN-Tracking-URL verhindert wird. Betrifft die Versionen: EMR — 7.3.0 bis EMR — 7.9.0.

Verwenden Sie die folgende Problemumgehung:

Beispielkonfiguration:

[
                               {
                                 "Classification": "spark-defaults",
                                 "Properties": {
                                     "spark.yarn.historyServer.address": "${hadoopconf-yarn.resourcemanager.hostname}:18480"
                                 }
                               }
  
                               ]

Hadoop YARN

Secure Hadoop RPC ist auf Verschlüsselung während der Übertragung eingestellt privacy und verwendet diese SASL-based . Dies erfordert, dass die Kerberos-Authentifizierung in der Sicherheitskonfiguration aktiviert ist. Wenn Sie keine Verschlüsselung bei der Übertragung für Hadoop RPC wünschen, konfigurieren Sie. hadoop.rpc.protection = authentication Für maximale Sicherheit empfehlen wir, die Standardkonfiguration zu verwenden.

Wenn Ihre TLS-Zertifikate die Anforderungen für die Überprüfung von TLS-Hostnamen nicht erfüllen, können Sie dies konfigurierenhadoop.ssl.hostname.verifier = ALLOW_ALL. Wir empfehlen Ihnen, die Standardkonfiguration von zu verwendenhadoop.ssl.hostname.verifier = DEFAULT, mit der die TLS-Hostnamen-Überprüfung erzwungen wird.

Um HTTPS für die Endpunkte der YARN-Webanwendung zu deaktivieren, konfigurieren Sie. yarn.http.policy = HTTP_ONLY Dadurch bleibt der Datenverkehr zu diesen Endpunkten unverschlüsselt. Wir empfehlen, die Standardkonfiguration für maximale Sicherheit zu verwenden.

Weitere Informationen finden Sie unter Hadoop in Secure Mode in der Apache-Hadoop-Dokumentation.

^{1 wird auf} mapreduce.shuffle.port YARN gehostet, aber nur von Hadoop NodeManager verwendet. MapReduce

² spark.shuffle.service.port wird auf YARN gehostet NodeManager , aber nur von Apache Spark verwendet.

Bekanntes Problem

Die yarn.log.server.url Konfiguration in verwendet derzeit HTTP mit Port 19888, wodurch der Zugriff auf Anwendungsprotokolle von der Resource Manager-Benutzeroberfläche aus verhindert wird. Betrifft die Versionen: EMR — 7.3.0 bis EMR — 7.8.0.

Verwenden Sie die folgende Problemumgehung:

Hadoop HDFS

Der Hadoop-Namensknoten, der Datenknoten und der Journalknoten unterstützen standardmäßig TLS, wenn die Verschlüsselung bei der Übertragung in EMR-Clustern aktiviert ist.

Secure Hadoop RPC ist auf auf eingestellt und verwendet Verschlüsselung bei der Übertragung. privacy SASL-based Dies erfordert, dass die Kerberos-Authentifizierung in der Sicherheitskonfiguration aktiviert ist.

Wir empfehlen, die für HTTPS-Endpunkte verwendeten Standardports nicht zu ändern.

Die Datenverschlüsselung bei der HDFS-Blockübertragung verwendet AES 256 und erfordert, dass die Verschlüsselung im Ruhezustand in der Sicherheitskonfiguration aktiviert ist.

Weitere Informationen finden Sie unter Hadoop in Secure Mode in der Apache-Hadoop-Dokumentation.

Hadoop MapReduce

Hadoop MapReduce, Job History Server und MapReduce Shuffle unterstützen standardmäßig TLS, wenn die Verschlüsselung bei der Übertragung in EMR-Clustern aktiviert ist.

Hadoop-verschlüsselter Shuffle verwendet MapReduce TLS.

Wir empfehlen, die Standardports für HTTPS-Endpunkte nicht zu ändern.

Weitere Informationen finden Sie unter Hadoop in Secure Mode in der Apache-Hadoop-Dokumentation.

¹ mapreduce.shuffle.port wird auf YARN gehostet NodeManager , aber nur von Hadoop MapReduce verwendet.

Presto

In den Amazon EMR-Versionen 5.6.0 und höher verwendet die interne Kommunikation zwischen dem Presto-Koordinator und den Mitarbeitern TLS. Amazon EMR richtet alle erforderlichen Konfigurationen ein, um eine sichere interne Kommunikation in Presto zu ermöglichen.

Wenn der Connector den Hive-Metastore als Metadatenspeicher verwendet, wird die Kommunikation zwischen dem Communicator und dem Hive-Metastore ebenfalls mit TLS verschlüsselt.

Trino

In den Amazon EMR-Versionen 6.1.0 und höher verwendet die interne Kommunikation zwischen dem Presto-Koordinator und den Mitarbeitern TLS. Amazon EMR richtet alle erforderlichen Konfigurationen ein, um eine sichere interne Kommunikation in Trino zu ermöglichen. https://trino.io/docs/current/security/internal-communication.html

Wenn der Connector den Hive-Metastore als Metadatenspeicher verwendet, wird die Kommunikation zwischen dem Communicator und dem Hive-Metastore ebenfalls mit TLS verschlüsselt.

Hive und Tez

Standardmäßig unterstützen Hive Server 2, Hive Metastore Server, Hive LLAP Daemon Web UI und Hive LLAP shuffle alle TLS, wenn die Verschlüsselung bei der Übertragung in den EMR-Clustern aktiviert ist. Weitere Informationen zu den Hive-Konfigurationen finden Sie unter Konfigurationseigenschaften. https://cwiki.apache.org/confluence/display/Hive/Configuration+Properties

Die Tez-Benutzeroberfläche, die auf dem Tomcat-Server gehostet wird, ist auch verfügbar, HTTPS-enabled wenn die Verschlüsselung bei der Übertragung im EMR-Cluster aktiviert ist. HTTPS ist jedoch für den Tez AM-Web-UI-Dienst deaktiviert, sodass AM-Benutzer keinen Zugriff auf die Keystore-Datei für den öffnenden SSL-Listener haben. Sie können dieses Verhalten auch mit den booleschen Konfigurationen und aktivieren. tez.am.tez-ui.webservice.enable.ssl tez.am.tez-ui.webservice.enable.client.auth

Flink

Apache Flink REST-Endpunkte und die interne Kommunikation zwischen Flink-Prozessen unterstützen standardmäßig TLS, wenn Sie die Verschlüsselung bei der Übertragung in EMR-Clustern aktivieren.

security.ssl.internal.enabledist auf Verschlüsselung während der Übertragung eingestellt true und verwendet diese für die interne Kommunikation zwischen den Flink-Prozessen. Wenn Sie keine Verschlüsselung während der Übertragung für die interne Kommunikation wünschen, deaktivieren Sie diese Konfiguration. Wir empfehlen Ihnen, die Standardkonfiguration für maximale Sicherheit zu verwenden.

Amazon EMR setzt security.ssl.rest.enabled auf true und verwendet die Verschlüsselung während der Übertragung für die REST-Endpunkte. Darüber hinaus setzt Amazon EMR auch historyserver.web.ssl.enabled auf True, um die TLS-Kommunikation mit dem Flink-Verlaufsserver zu verwenden. Wenn Sie keine Verschlüsselung während der Übertragung für die REST-Punkte wünschen, deaktivieren Sie diese Konfigurationen. Wir empfehlen Ihnen, die Standardkonfiguration für maximale Sicherheit zu verwenden.

Amazon EMR verwendet security.ssl.algorithms., um die Liste der Chiffren anzugeben, die Verschlüsselung verwenden. AES-based Überschreiben Sie diese Konfiguration, um die gewünschten Chiffren zu verwenden.

Weitere Informationen finden Sie unter SSL-Setup in der Flink-Dokumentation.

HBase

Amazon EMR setzt Secure Hadoop RPC auf. privacy HMaster und RegionServer verwende Verschlüsselung bei der Übertragung. SASL-based Dies setzt voraus, dass die Kerberos-Authentifizierung in der Sicherheitskonfiguration aktiviert ist.

Amazon EMR setzt den Wert hbase.ssl.enabled auf true und verwendet TLS für UI-Endpunkte. Wenn Sie TLS nicht für UI-Endpunkte verwenden möchten, deaktivieren Sie diese Konfiguration. Wir empfehlen, die Standardkonfiguration für maximale Sicherheit zu verwenden.

Amazon EMR legt TLS für die REST hbase.rest.ssl.enabled hbase.thrift.ssl.enabled - bzw. Thirft-Serverendpunkte fest und verwendet es. Wenn Sie TLS für diese Endpunkte nicht verwenden möchten, deaktivieren Sie diese Konfiguration. Wir empfehlen, die Standardkonfiguration für maximale Sicherheit zu verwenden.

Ab EMR 7.6.0 wird TLS auf HMaster und Endpunkten unterstützt. RegionServer Amazon EMR legt auch und fest. hbase.server.netty.tls.enabled hbase.client.netty.tls.enabled Wenn Sie TLS für diese Endpunkte nicht verwenden möchten, deaktivieren Sie diese Konfiguration. Wir empfehlen Ihnen, die Standardkonfiguration zu verwenden, die Verschlüsselung und damit höhere Sicherheit bietet. Weitere Informationen finden Sie unter Transport Level Security (TLS) in der HBase-RPC-Kommunikation im Apache HBase-Referenzhandbuch.

Phoenix

Wenn Sie die Verschlüsselung während der Übertragung in Ihrem EMR-Cluster aktiviert haben, unterstützt Phoenix Query Server die TLS-Eigenschaftphoenix.queryserver.tls.enabled, die standardmäßig auf gesetzt ist. true

Weitere Informationen finden Sie unter Konfigurationen in Bezug auf HTTPS in der Phoenix Query Server-Dokumentation.

Oozie

OOZIE-3673ist auf Amazon EMR verfügbar, wenn Sie Oozie auf Amazon EMR 7.3.0 und höher ausführen. Wenn Sie benutzerdefinierte SSL- oder TLS-Protokolle konfigurieren müssen, wenn Sie eine E-Mail-Aktion ausführen, können Sie die Eigenschaft oozie.email.smtp.ssl.protocols in der Datei festlegen. oozie-site.xml Wenn Sie die Verschlüsselung bei der Übertragung aktiviert haben, verwendet Amazon EMR standardmäßig das TLS v1.3-Protokoll.

OOZIE-3677und OOZIE-3674 sind auch auf Amazon EMR verfügbar, wenn Sie Oozie auf Amazon EMR 7.3.0 und höher ausführen. Auf diese Weise können Sie die Eigenschaften und in angeben. keyStoreType trustStoreType oozie-site.xml OOZIE-3674 fügt den Parameter --insecure dem Oozie-Client hinzu, sodass er Zertifikatsfehler ignorieren kann.

Oozie erzwingt die TLS-Hostnamen-Verifizierung, was bedeutet, dass jedes Zertifikat, das Sie für die Verschlüsselung während der Übertragung verwenden, die Anforderungen an die Hostnamen-Verifizierung erfüllen muss. Wenn das Zertifikat die Kriterien nicht erfüllt, steckt der Cluster möglicherweise in der oozie share lib update Phase fest, in der Amazon EMR den Cluster bereitstellt. Wir empfehlen Ihnen, Ihre Zertifikate zu aktualisieren, um sicherzustellen, dass sie der Hostnamen-Verifizierung entsprechen. Wenn du die Zertifikate jedoch nicht aktualisieren kannst, kannst du SSL für Oozie deaktivieren, indem du die oozie.https.enabled Eigenschaft auf false in der Cluster-Konfiguration setzt.

Hue

Standardmäßig unterstützt Hue TLS, wenn die Verschlüsselung bei der Übertragung in Amazon EMR-Clustern aktiviert ist. Weitere Informationen zu Hue-Konfigurationen finden Sie unter Konfigurieren von Hue mit HTTPS/SSL.

Livy

Standardmäßig unterstützt Livy TLS, wenn die Verschlüsselung während der Übertragung in Amazon EMR-Clustern aktiviert ist. Weitere Informationen zu Livy-Konfigurationen finden Sie unter HTTPS mit Apache Livy aktivieren.

Ab Amazon EMR 7.3.0 können Sie den Livy-Server nicht mehr für Spark-Anwendungen verwenden, die vom Hive-Metastore abhängig sind, wenn Sie Verschlüsselung bei der Übertragung und Kerberos-Authentifizierung verwenden. Dieses Problem wurde behoben HIVE-16340 und vollständig behoben, SPARK-44114 wenn die Open-Source-Spark-Anwendung auf Hive 3 aktualisiert werden kann. In der Zwischenzeit können Sie dieses Problem umgehen, wenn Sie dies einstellenhive.metastore.use.SSL. false Weitere Informationen finden Sie unter Konfigurieren von Anwendungen.

Weitere Informationen finden Sie unter HTTPS mit Apache Livy https://docs.aws.amazon.com/emr/latest/ReleaseGuide/enabling-https.html aktivieren.

JupyterEnterpriseGateway

Standardmäßig unterstützt Jupyter Enterprise Gateway TLS, wenn die Verschlüsselung während der Übertragung in Amazon EMR-Clustern aktiviert ist. Weitere Informationen zu den Jupyter Enterprise Gateway-Konfigurationen finden Sie unter Securing Enterprise Gateway Server. https://jupyter-enterprise-gateway.readthedocs.io/en/v1.2.0/getting-started-security.html#securing-enterprise-gateway-server

JupyterHub

JupyterHub Unterstützt standardmäßig TLS, wenn die Verschlüsselung während der Übertragung in Amazon EMR-Clustern aktiviert ist. Weitere Informationen finden Sie in der Dokumentation unter Aktivieren der JupyterHub SSL-Verschlüsselung. Es wird nicht empfohlen, die Verschlüsselung zu deaktivieren.

Zeppelin

Standardmäßig unterstützt Zeppelin TLS, wenn Sie die Verschlüsselung bei der Übertragung in Ihrem EMR-Cluster aktivieren. Weitere Informationen zu den Zeppelin-Konfigurationen finden Sie unter SSL-Konfiguration in der Zeppelin-Dokumentation.

Zookeeper

Amazon EMR setzt serverCnxnFactory auf, org.apache.zookeeper.server.NettyServerCnxnFactory um TLS für das Zookeeper-Quorum und die Client-Kommunikation zu aktivieren.

secureClientPortgibt den Port an, der TLS-Verbindungen abhört. Wenn der Client keine TLS-Verbindungen zu Zookeeper unterstützt, können Clients eine Verbindung zu dem unsicheren Port 2181 herstellen, der unter angegeben ist. clientPort Sie können diese beiden Ports außer Kraft setzen oder deaktivieren.

Amazon EMR legt sslQuorum sowohl als auch auf festadmin.forceHttps, true um die TLS-Kommunikation für den Quorum- und den Admin-Server zu aktivieren. Wenn Sie keine Verschlüsselung während der Übertragung für das Quorum und den Admin-Server wünschen, können Sie diese Konfigurationen deaktivieren. Für maximale Sicherheit empfehlen wir, die Standardkonfigurationen zu verwenden.

Weitere Informationen finden Sie unter Verschlüsselung, Authentifizierung, Autorisierungsoptionen in der Zookeeper-Dokumentation.