Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre le chiffrement en transit

Vous pouvez configurer un cluster EMR pour exécuter des frameworks open source tels qu'Apache Spark, Apache Hive et Presto. Chacun de ces frameworks open source comporte un ensemble de processus exécutés sur les instances d'un cluster. EC2 Chacun de ces processus peut héberger des points de terminaison réseau pour les communications réseau.

Si le chiffrement en transit est activé sur un cluster EMR, les différents points de terminaison du réseau utilisent des mécanismes de chiffrement différents. Consultez les sections suivantes pour en savoir plus sur les points de terminaison du réseau open source spécifiques pris en charge par le chiffrement en transit, les mécanismes de chiffrement associés et la version d'Amazon EMR qui a ajouté cette prise en charge. Chaque application open source peut également avoir des bonnes pratiques et des configurations de framework open source différentes que vous pouvez modifier.

Pour une couverture maximale du chiffrement en transit, nous vous recommandons d'activer à la fois le chiffrement en transit et Kerberos. Si vous activez uniquement le chiffrement en transit, le chiffrement en transit ne sera disponible que pour les points de terminaison du réseau qui prennent en charge le protocole TLS. Kerberos est nécessaire car certains points de terminaison réseau open source utilisent le protocole SASL (Simple Authentication and Security Layer) pour le chiffrement en transit.

Notez que les frameworks open source non pris en charge dans les versions 7.x.x d'Amazon EMR ne sont pas inclus.

Spark

Lorsque vous activez le chiffrement en transit dans les configurations de sécurité, spark.authenticate il est automatiquement configuré true et utilise le chiffrement AES pour les connexions RPC.

À partir d'Amazon EMR 7.3.0, si vous utilisez le chiffrement en transit et l'authentification Kerberos, vous ne pouvez pas utiliser les applications Spark qui dépendent du métastore Hive. Hive 3 résout ce problème dans HIVE-16340. HIVE-44114 résout complètement ce problème lorsque Spark open source peut passer à Hive 3. En attendant, vous pouvez configurer hive.metastore.use.SSL false pour contourner ce problème. Pour plus d'informations, consultez Configuration des applications.

Pour plus d'informations, consultez la section Sécurité de Spark dans la documentation d'Apache Spark.

¹ spark.shuffle.service.port est hébergé sur YARN NodeManager mais n'est utilisé que par Apache Spark.

Problème connu

Sur les clusters activés en transit, spark.yarn.historyServer.address la configuration utilise actuellement le port18080, ce qui empêche l'accès à l'interface utilisateur de l'application Spark à l'aide de l'URL de suivi YARN. Affecte la version : EMR - 7.3.0 à EMR - 7.9.0.

Utilisez la solution de contournement suivante :

Exemple de configuration :

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

FIL Hadoop

Le protocole RPC sécurisé Hadoop est configuré privacy et utilise le chiffrement en transit basé sur le protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité. Si vous ne souhaitez pas de chiffrement en transit pour Hadoop RPC, configurez. hadoop.rpc.protection = authentication Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

Si vos certificats TLS ne répondent pas aux exigences de vérification du nom d'hôte TLS, vous pouvez configurer. hadoop.ssl.hostname.verifier = ALLOW_ALL Nous vous recommandons d'utiliser la configuration par défaut dehadoop.ssl.hostname.verifier = DEFAULT, qui applique la vérification du nom d'hôte TLS.

Pour désactiver le protocole HTTPS pour les points de terminaison de l'application Web YARN, configurezyarn.http.policy = HTTP_ONLY. Ainsi, le trafic vers ces points de terminaison n'est pas chiffré. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

Pour plus d'informations, consultez Hadoop en mode sécurisé dans la documentation Apache Hadoop.

¹ mapreduce.shuffle.port est hébergé sur YARN NodeManager mais n'est utilisé que par Hadoop MapReduce.

² spark.shuffle.service.port est hébergé sur YARN NodeManager mais n'est utilisé que par Apache Spark.

Problème connu

La yarn.log.server.url configuration dans utilise actuellement le protocole HTTP avec le port 19888, ce qui empêche l'accès aux journaux des applications depuis l'interface utilisateur du gestionnaire de ressources. Affecte la version : EMR - 7.3.0 à EMR - 7.8.0.

Utilisez la solution de contournement suivante :

Hadoop HDFS

Le nœud de nom, le nœud de données et le nœud de journal Hadoop prennent tous en charge le protocole TLS par défaut si le chiffrement en transit est activé dans les clusters EMR.

Le protocole RPC sécurisé Hadoop est configuré pour utiliser le chiffrement en transit basé sur le privacy protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité.

Nous vous recommandons de ne pas modifier les ports par défaut utilisés pour les points de terminaison HTTPS.

Le chiffrement des données lors du transfert par blocs HDFS utilise la norme AES 256 et nécessite que le chiffrement au repos soit activé dans la configuration de sécurité.

Pour plus d'informations, consultez Hadoop en mode sécurisé dans la documentation Apache Hadoop.

Hadoop MapReduce

Hadoop MapReduce, le serveur d'historique des tâches et MapReduce Shuffle prennent tous en charge le protocole TLS par défaut lorsque le chiffrement en transit est activé dans les clusters EMR.

Le shuffle MapReduce chiffré Hadoop utilise le protocole TLS.

Nous vous recommandons de ne pas modifier les ports par défaut pour les points de terminaison HTTPS.

Pour plus d'informations, consultez Hadoop en mode sécurisé dans la documentation Apache Hadoop.

¹ mapreduce.shuffle.port est hébergé sur YARN NodeManager mais n'est utilisé que par Hadoop MapReduce.

Presto

Dans les versions 5.6.0 et supérieures d'Amazon EMR, la communication interne entre le coordinateur Presto et les employés utilise le protocole TLS. Amazon EMR définit toutes les configurations requises pour permettre une communication interne sécurisée dans Presto.

Si le connecteur utilise le métastore Hive comme magasin de métadonnées, les communications entre le communicateur et le métastore Hive sont également chiffrées avec le protocole TLS.

Trino

Dans les versions 6.1.0 et supérieures d'Amazon EMR, la communication interne entre le coordinateur Presto et les employés utilise le protocole TLS. Amazon EMR définit toutes les configurations requises pour permettre une communication interne sécurisée dans Trino.

Si le connecteur utilise le métastore Hive comme magasin de métadonnées, les communications entre le communicateur et le métastore Hive sont également chiffrées avec le protocole TLS.

Hive et Tez

Par défaut, le serveur Hive 2, le serveur Hive Metastore, l'interface utilisateur Web Hive LLAP Daemon et le Hive LLAP shuffle prennent tous en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters EMR. Pour plus d'informations sur les configurations Hive, consultez la section Propriétés de configuration.

L'interface utilisateur Tez hébergée sur le serveur Tomcat est également compatible HTTPS lorsque le chiffrement en transit est activé dans le cluster EMR. Cependant, le protocole HTTPS est désactivé pour le service d'interface utilisateur Web Tez AM, de sorte que les utilisateurs AM n'ont pas accès au fichier keystore pour l'écouteur SSL qui s'ouvre. Vous pouvez également activer ce comportement avec les configurations tez.am.tez-ui.webservice.enable.ssl booléennes et. tez.am.tez-ui.webservice.enable.client.auth

Flink

Les points de terminaison REST Apache Flink et les communications internes entre les processus Flink prennent en charge le protocole TLS par défaut lorsque vous activez le chiffrement en transit dans les clusters EMR.

security.ssl.internal.enabledest configuré true et utilise le chiffrement en transit pour les communications internes entre les processus Flink. Si vous ne souhaitez pas que les communications internes soient chiffrées en transit, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

Amazon EMR définit true et utilise le chiffrement en transit security.ssl.rest.enabledpour les points de terminaison REST. En outre, Amazon EMR est également défini sur true historyserver.web.ssl.enabledpour utiliser la communication TLS avec le serveur d'historique Flink. Si vous ne souhaitez pas que les points REST soient chiffrés en transit, désactivez ces configurations. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

Amazon EMR utilise security.ssl.algorithms. pour spécifier la liste des chiffrements utilisant le chiffrement AES. Remplacez cette configuration pour utiliser les chiffrements souhaités.

Pour plus d'informations, consultez la section Configuration SSL dans la documentation de Flink.

HBase

Amazon EMR définit Secure Hadoop RPC sur. privacy HMaster et RegionServer utilisez le chiffrement en transit basé sur le protocole SASL. Cela nécessite que l'authentification Kerberos soit activée dans la configuration de sécurité.

Amazon EMR est défini sur true et utilise le protocole TLS hbase.ssl.enabled pour les points de terminaison de l'interface utilisateur. Si vous ne souhaitez pas utiliser le protocole TLS pour les points de terminaison de l'interface utilisateur, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

Amazon EMR définit hbase.rest.ssl.enabled hbase.thrift.ssl.enabled et utilise le protocole TLS pour les points de terminaison des serveurs REST et Thift, respectivement. Si vous ne souhaitez pas utiliser le protocole TLS pour ces points de terminaison, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut pour une sécurité maximale.

À partir de la version 7.6.0 d'EMR, le protocole TLS est pris en charge sur et sur les terminaux. HMaster RegionServer Amazon EMR définit hbase.server.netty.tls.enabled également et. hbase.client.netty.tls.enabled Si vous ne souhaitez pas utiliser le protocole TLS pour ces points de terminaison, désactivez cette configuration. Nous vous recommandons d'utiliser la configuration par défaut, qui fournit un cryptage et donc une sécurité accrue. Pour en savoir plus, consultez la section Transport Level Security (TLS) dans les communications HBase RPC dans le guide de HBase référence Apache.

Phoenix

Si vous avez activé le chiffrement en transit dans votre cluster EMR, Phoenix Query Server prend en charge la phoenix.queryserver.tls.enabled propriété TLS, qui est définie sur par défaut. true

Pour en savoir plus, consultez la section Configurations relatives au protocole HTTPS dans la documentation de Phoenix Query Server.

Oozie

OOZIE-3673 est disponible sur Amazon EMR si vous exécutez Oozie sur Amazon EMR 7.3.0 ou version ultérieure. Si vous devez configurer des protocoles SSL ou TLS personnalisés lorsque vous exécutez une action par e-mail, vous pouvez définir la propriété oozie.email.smtp.ssl.protocols dans le oozie-site.xml fichier. Par défaut, si vous avez activé le chiffrement en transit, Amazon EMR utilise le protocole TLS v1.3.

OOZIE-3677 et OOZIE-3674 sont également disponibles sur Amazon EMR si vous exécutez Oozie sur Amazon EMR 7.3.0 ou version ultérieure. Cela vous permet de spécifier les propriétés keyStoreType et trustStoreType dansoozie-site.xml. OOZIE-3674 ajoute le paramètre au client Oozie --insecure afin qu'il puisse ignorer les erreurs de certificat.

Oozie applique la vérification du nom d'hôte TLS, ce qui signifie que tout certificat que vous utilisez pour le chiffrement en transit doit répondre aux exigences de vérification du nom d'hôte. Si le certificat ne répond pas aux critères, le cluster risque de se bloquer au oozie share lib update moment où Amazon EMR approvisionne le cluster. Nous vous recommandons de mettre à jour vos certificats pour vous assurer qu'ils sont conformes à la vérification du nom d'hôte. Toutefois, si vous ne pouvez pas mettre à jour les certificats, vous pouvez désactiver le protocole SSL pour Oozie en définissant la oozie.https.enabled propriété sur false dans la configuration du cluster.

Hue

Par défaut, Hue prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations Hue, voir Configurer Hue avec HTTPS/SSL.

Livy

Par défaut, Livy prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations de Livy, voir Activation du protocole HTTPS avec Apache Livy.

À partir d'Amazon EMR 7.3.0, si vous utilisez le chiffrement en transit et l'authentification Kerberos, vous ne pouvez pas utiliser le serveur Livy pour les applications Spark qui dépendent du métastore Hive. Ce problème est résolu dans HIVE-16340 et entièrement résolu dans SPARK-44114 lorsque l'application open source Spark peut passer à Hive 3. En attendant, vous pouvez contourner ce problème si vous configurez hive.metastore.use.SSL surfalse. Pour plus d'informations, consultez Configuration des applications.

Pour plus d'informations, consultez la section Activation du protocole HTTPS avec Apache Livy.

JupyterEnterpriseGateway

Par défaut, Jupyter Enterprise Gateway prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations sur les configurations de Jupyter Enterprise Gateway, consultez la section Sécurisation du serveur Enterprise Gateway.

JupyterHub

Par défaut, JupyterHub prend en charge le protocole TLS lorsque le chiffrement en transit est activé dans les clusters Amazon EMR. Pour plus d'informations, consultez la section Activation du cryptage SSL dans la JupyterHub documentation. Il n'est pas recommandé de désactiver le chiffrement.

Zeppelin

Par défaut, Zeppelin prend en charge le protocole TLS lorsque vous activez le chiffrement en transit dans votre cluster EMR. Pour plus d'informations sur les configurations Zeppelin, consultez la section Configuration SSL dans la documentation Zeppelin.

Zookeeper

Amazon EMR se configure serverCnxnFactory pour activer le protocole TLS org.apache.zookeeper.server.NettyServerCnxnFactory pour le quorum de Zookeeper et les communications avec les clients.

secureClientPortindique le port qui écoute les connexions TLS. Si le client ne prend pas en charge les connexions TLS à Zookeeper, les clients peuvent se connecter au port non sécurisé 2181 spécifié dans. clientPort Vous pouvez annuler ou désactiver ces deux ports.

Amazon EMR définit les deux paramètres sslQuorum et sur admin.forceHttps true pour activer la communication TLS pour le quorum et le serveur d'administration. Si vous ne souhaitez pas que le quorum et le serveur d'administration soient chiffrés en transit, vous pouvez désactiver ces configurations. Nous vous recommandons d'utiliser les configurations par défaut pour une sécurité maximale.

Pour plus d'informations, consultez la section Options de chiffrement, d'authentification et d'autorisation dans la documentation de Zookeeper.