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.
# Authentification auprès des nœuds de cluster Amazon EMR
Des clients SSH peuvent utiliser une paire de clés Amazon EC2 pour authentifier des instances de cluster. Avec les versions 5.10.0 et supérieures d'Amazon EMR, vous pouvez également configurer Kerberos pour authentifier les utilisateurs et les connexions SSH auprès du nœud primaire. Et avec les versions 5.12.0 et supérieures d'Amazon EMR, vous pouvez vous authentifier avec LDAP.
**Topics**
+ [
# Utiliser une paire de clés EC2 pour les informations d'identification SSH pour Amazon EMR
](emr-plan-access-ssh.md)
+ [
# Utilisation de Kerberos pour l'authentification avec Amazon EMR
](emr-kerberos.md)
+ [
# Utilisation de serveurs Active Directory ou LDAP pour l'authentification avec Amazon EMR
](ldap.md)
# Utiliser une paire de clés EC2 pour les informations d'identification SSH pour Amazon EMR
Les nœuds de cluster Amazon EMR s'exécutent sur des instances Amazon EC2. Vous pouvez vous connecter aux nœuds de cluster de la même manière qu'aux instances Amazon EC2. Vous pouvez utiliser Amazon EC2 pour créer une paire de clés ou vous pouvez en importer une. Lorsque vous créez un cluster, vous pouvez spécifier la paire de clés Amazon EC2 qui sera utilisée pour les connexions SSH à toutes les instances de cluster. Vous pouvez également créer un cluster sans paire de clés. Ceci est généralement effectué avec des clusters transitoires qui sont lancés, exécutent des étapes, puis sont mis hors service automatiquement.
Le client SSH que vous utilisez pour vous connecter au cluster a besoin du fichier de clé privée associé à cette paire de clés. Il s'agit d'un fichier .pem pour les clients SSH qui utilisent Linux, Unix et macOS. Vous devez définir les autorisations de telle sorte que seul le propriétaire des clés soit autorisé à accéder au fichier. Il s'agit d'un fichier .ppk pour les clients SSH qui utilisent Windows et le fichier .ppk est généralement créé à partir du fichier .pem.
+ Pour plus d'informations sur la création d'une paire de clés Amazon EC2, consultez les paires de [clés Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le guide de l'utilisateur Amazon *EC2*.
+ *Pour obtenir des instructions sur l'utilisation de Pu TTYgen pour créer un fichier .ppk à partir d'un fichier .pem, consultez la section [Conversion de votre clé privée à l'aide de Pu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) dans le guide de l'TTYgenutilisateur Amazon EC2.*
+ Pour plus d'informations sur la définition des autorisations des fichiers .pem et sur la manière de se connecter au nœud principal d'un cluster EMR à l'aide de différentes méthodes, notamment depuis `ssh` Linux ou macOS, PuTTY depuis Windows ou AWS CLI depuis n'importe quel système d'exploitation compatible, consultez. [Connectez-vous au nœud principal du cluster Amazon EMR à l'aide de SSH](emr-connect-master-node-ssh.md)
# Utilisation de Kerberos pour l'authentification avec Amazon EMR
Les versions 5.10.0 et supérieures d'Amazon EMR prennent en charge Kerberos. Kerberos est un protocole d'authentification réseau qui utilise la cryptographie à clé secrète pour fournir une authentification forte afin que les mots de passe ou autres informations d'identification ne soient pas envoyés sur le réseau dans un format non chiffré.
Dans Kerberos, les services et utilisateurs qui ont besoin de s'authentifier sont appelés *mandataires*. Les mandataires existent au sein d'un *domaine* Kerberos. Dans ce domaine, un serveur Kerberos connu comme le *centre de distribution de clés (KDC)* fournit aux mandataires les moyens de s'authentifier. Le KDC effectue cette opération en émettant des *tickets* d'authentification. Il gère une base de données des principaux au sein de son domaine, leurs mots de passe, ainsi que d'autres informations administratives sur chaque principal. Un KDC peut également accepter les informations d'authentification provenant de mandataires d'autres domaines, ce qui est connu sous le nom d'*approbation inter-domaines*. De plus, un cluster EMR peut utiliser un KDC externe pour authentifier les mandataires.
Un scénario courant pour établir une approbation inter-domaines ou pour utiliser un KDC externe consiste à authentifier les utilisateurs d'un domaine Active Directory. Cela permet aux utilisateurs d'accéder à un cluster EMR à l'aide de leur compte de domaine lorsqu'ils utilisent SSH pour se connecter à un cluster ou utiliser les applications de big data.
Lorsque vous utilisez l'authentification Kerberos, Amazon EMR configure Kerberos pour les applications, les composants et les sous-systèmes qu'il installe sur le cluster afin qu'ils puissent s'authentifier les uns les autres.
**Important**
Amazon EMR n'est pas pris AWS Directory Service for Microsoft Active Directory en charge dans le cadre d'une confiance interdomaines ou en tant que KDC externe.
Avant de configurer Kerberos à l'aide d'Amazon EMR, nous vous recommandons de vous familiariser avec les concepts Kerberos, les services qui s'exécutent sur un KDC et les outils d'administration des services Kerberos. Pour plus d'informations, consultez la [Documentation MIT Kerberos](http://web.mit.edu/kerberos/krb5-latest/doc/) qui est publiée par le [Consortium Kerberos](http://kerberos.org/).
**Topics**
+ [
# Applications prises en charge avec Amazon EMR
](emr-kerberos-principals.md)
+ [
# Options d'architecture Kerberos avec Amazon EMR
](emr-kerberos-options.md)
+ [
# Configuration de Kerberos sur Amazon EMR
](emr-kerberos-configure.md)
+ [
# Utilisation de SSH pour se connecter à des clusters Kerberisés avec Amazon EMR
](emr-kerberos-connect-ssh.md)
+ [
# Tutoriel : Configuration d'un KDC dédié au cluster avec Amazon EMR
](emr-kerberos-cluster-kdc.md)
+ [
# Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory
](emr-kerberos-cross-realm.md)
# Applications prises en charge avec Amazon EMR
Dans un cluster EMR, les principaux Kerberos sont les services applicatifs et les sous-systèmes de Big Data qui s'exécutent sur tous les nœuds de cluster. Amazon EMR peut configurer les applications et les composants répertoriés ci-dessous pour utiliser Kerberos. Chaque application a un principal utilisateur Kerberos qui lui est associé.
Amazon EMR ne prend pas en charge les approbations inter-domaines avec AWS Directory Service for Microsoft Active Directory.
Amazon EMR configure uniquement les fonctionnalités d'authentification Kerberos en open source pour les applications et les composants répertoriés ci-dessous. Toutes les autres applications installées ne sont pas activées pour Kerberos, ce qui peut entraîner une incapacité à communiquer avec les composants activés pour Kerberos et provoquer des erreurs d'applications. Les applications et composants qui ne sont pas activés pour Kerberos ne peuvent pas s'authentifier. Les applications et les composants pris en charge peuvent varier selon les différentes versions d'Amazon EMR.
L'interface utilisateur Livy est la seule interface utilisateur web hébergée sur le cluster qui est activée pour Kerberos.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ N'activez pas Hive avec l'authentification LDAP. Cela peut entraîner des problèmes de communication avec Kerberos YARN.
+ **Hue**
+ L'authentification utilisateur Hue n'est pas définie automatiquement et peut être configurée à l'aide de l'API de configuration.
+ Le serveur Hue est activé pour Kerberos. Le serveur frontal Hue (interface utilisateur) n'est pas configuré pour l'authentification. L'authentification LDAP peut être configurée pour l'interface utilisateur Hue.
+ **Livy**
+ L'emprunt d'identité Livy pour les clusters activés pour Kerberos est pris en charge dans les versions 5.22.0 et ultérieures d'Amazon EMR.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto prend en charge l'authentification Kerberos dans les versions 6.9.0 et supérieures d'Amazon EMR.
+ Pour utiliser l'authentification Kerberos pour Presto, vous devez activer le [chiffrement en transit](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino prend en charge l'authentification Kerberos dans les versions 6.11.0 et ultérieures d'Amazon EMR.
+ Pour utiliser l'authentification Kerberos pour Trino, vous devez activer le [chiffrement en transit](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ Zeppelin est uniquement configuré pour utiliser Kerberos avec l'interpréteur Spark. Il n'est pas configuré pour les autres interpréteurs.
+ L'emprunt d'identité de l'utilisateur n'est pas pris en charge pour les interpréteurs Zeppelin activés pour Kerberos autres que Spark.
+ **Zookeeper**
+ Le client Zookeeper n'est pas pris en charge.
# Options d'architecture Kerberos avec Amazon EMR
Lorsque vous utilisez Kerberos avec Amazon EMR, vous pouvez choisir parmi les architectures répertoriées dans cette section. Quelle que soit l'architecture que vous choisissez, vous devez configurer Kerberos à l'aide des mêmes étapes. Vous créez une configuration de sécurité, vous spécifiez la configuration de sécurité et des options Kerberos propres au cluster compatibles lorsque vous créez le cluster, et vous créez des annuaires HDFS pour des utilisateurs Linux sur le cluster qui correspondent aux mandataires d'utilisateurs dans le KDC. Pour plus d'informations sur les options de configuration et les exemples de configurations pour chaque architecture, consultez [Configuration de Kerberos sur Amazon EMR](emr-kerberos-configure.md).
## KDC dédié du cluster (KDC sur le nœud primaire)
Cette configuration est disponible avec les versions 5.10.0 et supérieures d'Amazon EMR.
![\[Amazon EMRcluster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Avantages**
+ Amazon EMR possède la propriété totale du KDC.
+ Le KDC sur le cluster EMR est indépendant des implémentations KDC centralisées telles que Microsoft Active Directory ou AWS Managed Microsoft AD.
+ L'impact de performance est minime, car le KDC gère l'authentification uniquement pour les nœuds locaux au sein du cluster.
+ Le cas échéant, d'autres clusters Kerberos peuvent faire référence au KDC comme KDC externe. Pour de plus amples informations, veuillez consulter [KDC externe – Nœud primaire sur un cluster différent](#emr-kerberos-extkdc-cluster-summary).
**Considérations et restrictions**
+ Les clusters activés pour Kerberos ne peuvent pas s'authentifier les uns aux autres. Par conséquent, les applications ne peuvent pas interagir. Si vos applications de cluster ont besoin d'interagir, vous devez établir une approbation inter-domaines entre les clusters ou configurer un cluster comme le KDC externe pour d'autres clusters. Si une confiance entre domaines est établie, il KDCs doit y avoir différents domaines Kerberos.
+ Vous devez créer des utilisateurs Linux sur l'instance EC2 du nœud primaire qui correspondent aux mandataires d'utilisateur KDC, ainsi que les annuaires HDFS pour chaque utilisateur.
+ Les mandataires de l'utilisateur doivent utiliser un fichier de clé privée EC2 et les informations d'identification `kinit` pour se connecter au cluster à l'aide de SSH.
## Relation d'approbation inter-domaines
Dans cette configuration, des mandataires (généralement des utilisateurs) provenant d'un autre domaine Kerberos authentifient auprès de composants d'application sur un cluster EMR activé pour Kerberos, qui a son propre KDC. Le KDC du nœud principal établit une relation de confiance avec un autre KDC en utilisant un *principe inter-domaines* qui existe dans les deux. KDCs Le nom et le mot de passe du principal correspondent exactement dans chaque KDC. Les relations d'approbation inter-domaines sont plus communes avec les implémentations Active Directory, comme illustré dans le schéma suivant. Les relations d'approbation inter-domaines avec un KDC MIT externe ou un KDC sur un autre cluster Amazon EMR sont également prises en charge.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Avantages**
+ Le cluster EMR sur lequel le KDC est installé conserve le contrôle total du KDC.
+ Avec Active Directory, Amazon EMR crée automatiquement des utilisateurs Linux qui correspondent aux principaux de l'utilisateur provenant du KDC. Vous devez toujours créer des annuaires HDFS pour chaque utilisateur. En outre, les mandataires d'utilisateur dans le domaine Active Directory peuvent accéder aux clusters Kerberos à l'aide des informations d'identification `kinit`, sans le fichier de clé privée EC2. Cela élimine la nécessité de partager le fichier de clé privée entre les utilisateurs de cluster.
+ Étant donné que chaque cluster KDC gère l'authentification pour les nœuds du cluster, les effets de la latence du réseau et la surcharge de traitement pour un grand nombre de nœuds dans les clusters est réduit.
**Considérations et restrictions**
+ Si vous établissez une approbation avec un domaine Active Directory, vous devez fournir un nom d'utilisateur et un mot de passe Active Directory avec des autorisations pour joindre des mandataires au domaine lorsque vous créez le cluster.
+ Les relations d'approbation inter-domaines ne peuvent pas être établies entre domaines Kerberos portant le même nom.
+ Les relations d'approbation inter-domaines doivent être explicitement créées. Par exemple, si les clusters A et B établissent tous deux une relation d'approbation inter-domaines avec un KDC, ils n'ont pas intrinsèquement confiance l'un à l'autre et leurs applications ne peuvent pas s'authentifier pour l'interopérabilité.
+ KDCs doivent être gérés de manière indépendante et coordonnée afin que les informations d'identification des principaux utilisateurs correspondent exactement.
## KDC externe
Les configurations avec un KDC externe sont prises en charge avec les versions d'Amazon EMR 5.20.0 et ultérieures.
+ [KDC externe – MIT KDC](#emr-kerberos-extkdc-mit-summary)
+ [KDC externe – Nœud primaire sur un cluster différent](#emr-kerberos-extkdc-cluster-summary)
+ [KDC externe – cluster KDC sur un autre cluster avec une relation d'approbation inter-domaines Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC externe – MIT KDC
Cette configuration permet à un ou plusieurs clusters EMR d'utiliser les mandataires définis et maintenus dans un serveur KDC MIT.
![\[Amazon EMRcluster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Avantages**
+ La gestion des mandataires est regroupée dans un seul KDC.
+ Plusieurs clusters peuvent utiliser le même KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter [Conditions requises pour l'utilisation de plusieurs clusters avec le même KDC](#emr-kerberos-multi-kdc).
+ Le nœud primaire sur un cluster activé pour Kerberos ne dispose pas des fardeaux de performances associés à l'entretien du KDC.
**Considérations et restrictions**
+ Vous devez créer des utilisateurs Linux sur l'instance EC2 du nœud primaire de chaque cluster Kerberos qui correspondent aux mandataires d'utilisateur KDC, ainsi que les annuaires HDFS pour chaque utilisateur.
+ Les mandataires de l'utilisateur doivent utiliser un fichier de clé privée EC2 et les informations d'identification `kinit` pour se connecter au cluster Kerberos à l'aide de SSH.
+ Chaque nœud activé pour les clusters EMR Kerberos doit avoir un chemin réseau vers le KDC.
+ Chaque nœud des clusters activés pour Kerberos passe une charge d'authentification sur le KDC externe et, par conséquent, la configuration du KDC affecte les performances du cluster. Lorsque vous configurez le matériel du serveur KDC, tenez compte du nombre maximal de nœuds Amazon EMR qu'il faut simultanément prendre en charge.
+ Les performances du cluster dépendent de la latence de réseau entre les nœuds dans les clusters et le KDC activés pour Kerberos.
+ La résolution de problèmes peut être plus difficile en raison d'interdépendances.
### KDC externe – Nœud primaire sur un cluster différent
Cette configuration est presque identique à l'implémentation KDC MIT externe ci-dessus, sauf que le KDC est sur le nœud primaire d'un cluster EMR. Pour plus d’informations, consultez [KDC dédié du cluster (KDC sur le nœud primaire)](#emr-kerberos-localkdc-summary) et [Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory](emr-kerberos-cross-realm.md).
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Avantages**
+ La gestion des mandataires est regroupée dans un seul KDC.
+ Plusieurs clusters peuvent utiliser le même KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter [Conditions requises pour l'utilisation de plusieurs clusters avec le même KDC](#emr-kerberos-multi-kdc).
**Considérations et restrictions**
+ Vous devez créer des utilisateurs Linux sur l'instance EC2 du nœud primaire de chaque cluster Kerberos qui correspondent aux mandataires d'utilisateur KDC, ainsi que les annuaires HDFS pour chaque utilisateur.
+ Les mandataires de l'utilisateur doivent utiliser un fichier de clé privée EC2 et les informations d'identification `kinit` pour se connecter au cluster Kerberos à l'aide de SSH.
+ Chaque nœud dans chaque cluster EMR doit disposer d'un chemin réseau vers le KDC.
+ Chaque nœud Amazon EMR des clusters activés pour Kerberos passe une charge d'authentification sur le KDC externe et, par conséquent, la configuration du KDC affecte les performances du cluster. Lorsque vous configurez le matériel du serveur KDC, tenez compte du nombre maximal de nœuds Amazon EMR qu'il faut simultanément prendre en charge.
+ Les performances du cluster dépendent de la latence de réseau entre les nœuds dans les clusters et le KDC.
+ La résolution de problèmes peut être plus difficile en raison d'interdépendances.
### KDC externe – cluster KDC sur un autre cluster avec une relation d'approbation inter-domaines Active Directory
Dans cette configuration, vous devez d'abord créer un cluster avec un KDC dédié au cluster qui dispose d'une relation d'approbation inter-domaines unidirectionnelle avec Active Directory. Pour voir un didacticiel détaillé, consultez [Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory](emr-kerberos-cross-realm.md). Vous pouvez ensuite lancer d'autres clusters faisant référence au cluster KDC qui a la confiance comme KDC externe. Pour obtenir un exemple, consultez [KDC de cluster externe avec approbation inter-domaines Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). Cela permet à chaque cluster Amazon EMR qui utilise le KDC externe d'authentifier les mandataires définis et maintenus dans un domaine Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Avantages**
+ La gestion des mandataires est regroupée dans le domaine Active Directory.
+ Amazon EMR se joint au domaine Active Directory, ce qui élimine le besoin de créer des utilisateurs Linux qui correspondent aux utilisateurs Active Directory. Vous devez toujours créer des annuaires HDFS pour chaque utilisateur.
+ Plusieurs clusters peuvent utiliser le même KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter [Conditions requises pour l'utilisation de plusieurs clusters avec le même KDC](#emr-kerberos-multi-kdc).
+ Les mandataires d'utilisateur dans le domaine Active Directory peuvent accéder aux clusters Kerberos à l'aide des informations d'identification `kinit`, sans le fichier de clé privée EC2. Cela élimine la nécessité de partager le fichier de clé privée entre les utilisateurs de cluster.
+ Un seul nœud primaire Amazon EMR a la charge de maintenir le KDC, et seul ce cluster doit être créé avec des informations d'identification Active Directory pour l'approbation inter-domaines entre le KDC et Active Directory.
**Considérations et restrictions**
+ Chaque nœud de chaque cluster EMR doit disposer d'un chemin réseau pour le KDC et le contrôleur de domaine Active Directory.
+ Chaque nœud Amazon EMR passe une charge d'authentification sur le KDC externe et, par conséquent, la configuration du KDC affecte les performances du cluster. Lorsque vous configurez le matériel du serveur KDC, tenez compte du nombre maximal de nœuds Amazon EMR qu'il faut simultanément prendre en charge.
+ Les performances du cluster dépendent de la latence de réseau entre les nœuds dans les clusters et le serveur KDC.
+ La résolution de problèmes peut être plus difficile en raison d'interdépendances.
## Conditions requises pour l'utilisation de plusieurs clusters avec le même KDC
Plusieurs clusters peuvent utiliser le même KDC dans le même domaine Kerberos. Toutefois, si les clusters s'exécutent simultanément, ils risquent d'échouer s'ils utilisent des ServicePrincipal noms Kerberos en conflit.
Si vous avez plusieurs clusters simultanés avec le même KDC externe, assurez-vous que les clusters utilisent des domaines Kerberos différents. Si les clusters doivent utiliser le même domaine Kerberos, assurez-vous que les clusters se trouvent dans des sous-réseaux différents et que leurs plages d'adresses CIDR ne se chevauchent pas.
# Configuration de Kerberos sur Amazon EMR
Cette section fournit des détails de configuration et des exemples pour configurer Kerberos avec des architectures courantes. Quelle que soit l'architecture que vous choisissez, les configurations de base sont identiques et effectuées en trois étapes. Si vous utilisez un KDC externe ou si vous configurez une approbation inter-domaines, vous devez vous assurer que tous les nœuds d'un cluster disposent d'un routage de réseau vers le KDC externe, y compris la configuration des groupes de sécurité pertinents pour autoriser le trafic Kerberos entrant et sortant.
## Étape 1 : Créer une configuration de sécurité avec des propriétés Kerberos
La configuration de sécurité spécifie les détails sur le KDC Kerberos et autorise la réutilisation de la configuration de Kerberos chaque fois que vous créez un cluster. Vous pouvez créer une configuration de sécurité à l'aide de la console Amazon EMR, de l'API EMR ou de l' AWS CLI API EMR. La configuration de sécurité peut également contenir d'autres options de sécurité, telles que le chiffrement. Pour plus d'informations sur la création de configurations de sécurité et la spécification d'une configuration de sécurité lorsque vous créez un cluster, consultez [Utiliser les configurations de sécurité pour configurer la sécurité du cluster Amazon EMR](emr-security-configurations.md). Pour plus d'informations sur les propriétés Kerberos dans une configuration de sécurité, consultez [Paramètres Kerberos pour les configurations de sécurité](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Étape 2 : Créer un cluster et spécifier les attributs Kerberos propres au cluster
Lorsque vous créez un cluster, spécifiez une configuration de sécurité Kerberos ainsi que des options Kerberos spécifiques au cluster. Lorsque vous utilisez la console Amazon EMR, seules les options Kerberos compatibles avec la configuration de sécurité spécifiée sont disponibles. Lorsque vous utilisez l'API AWS CLI ou Amazon EMR, assurez-vous de spécifier des options Kerberos compatibles avec la configuration de sécurité spécifiée. Par exemple, si vous spécifiez un mot de passe de principal pour une approbation inter-domaines lorsque vous créez un cluster à l'aide de l'interface de ligne de commande, et la configuration de sécurité spécifiée n'est pas configurée avec les paramètres d'approbation inter-domaines, une erreur se produit. Pour de plus amples informations, veuillez consulter [Paramètres de Kerberos pour les clusters](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Étape 3 : Configurer le nœud primaire de cluster
Selon les exigences de votre architecture et l'implémentation, une configuration supplémentaire sur le cluster peut être requise. Vous pouvez effectuer cette opération après l'avoir créée ou en utilisant les étapes ou les actions d'amorçage pendant le processus de création.
Pour chaque utilisateur authentifié par Kerberos qui se connecte au cluster à l'aide de SSH, vous devez vous assurer que les comptes Linux qui correspondent à l'utilisateur Kerberos sont créés. Si les principaux sont fournis par un contrôleur de domaine Active Directory, soit comme KDC externe ou par le biais d'une approbation inter-domaines, Amazon EMR crée automatiquement des comptes Linux. Si Active Directory n'est pas utilisé, vous devez créer des mandataires pour chaque utilisateur qui correspondent à leur utilisateur Linux. Pour de plus amples informations, veuillez consulter [Configuration d'un cluster Amazon EMR pour les utilisateurs HDFS authentifiés par Kerberos et les connexions SSH](emr-kerberos-configuration-users.md).
Chaque utilisateur doit également disposer d'un répertoire d'utilisateurs HDFS qui leur appartient et que vous devez créer. En outre, SSH doit être configuré avec la GSSAPI activée afin d'autoriser les connexions à partir des utilisateurs authentifiés par Kerberos. GSSAPI doit être activée sur le nœud primaire et l'application SSH cliente doit être configurée pour utiliser la GSSAPI. Pour de plus amples informations, veuillez consulter [Configuration d'un cluster Amazon EMR pour les utilisateurs HDFS authentifiés par Kerberos et les connexions SSH](emr-kerberos-configuration-users.md).
# Configuration de sécurité et paramètres de cluster pour Kerberos sur Amazon EMR
Lorsque vous créez un cluster activé pour Kerberos, vous spécifiez la configuration de sécurité avec des attributs Kerberos qui sont propres au cluster. Vous ne pouvez pas spécifier un ensemble sans l'autre, sinon une erreur se produit.
Cette rubrique fournit une vue d'ensemble des paramètres de configuration disponibles pour Kerberos lorsque vous créez une configuration de sécurité et un cluster. De plus, les exemples de l'interface de ligne de commande pour créer des clusters et des configurations de sécurité compatibles sont fournis pour les architectures courantes.
## Paramètres Kerberos pour les configurations de sécurité
Vous pouvez créer une configuration de sécurité qui spécifie les attributs Kerberos à l'aide de la console Amazon EMR, de l'API EMR AWS CLI ou de l'API EMR. La configuration de sécurité peut également contenir d'autres options de sécurité, telles que le chiffrement. Pour de plus amples informations, veuillez consulter [Créez une configuration de sécurité à l'aide de la console Amazon EMR ou du AWS CLI](emr-create-security-configuration.md).
Utilisez les références suivantes pour comprendre les paramètres de configuration de sécurité disponibles pour l'architecture Kerberos que vous choisissez. Les paramètres de la console Amazon EMR sont affichés. Pour les options d'interface de ligne de commande correspondantes, consultez [Spécification des paramètres Kerberos à l'aide du AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) ou [Exemples de configuration](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Paramètres de Kerberos pour les clusters
Vous pouvez spécifier les paramètres Kerberos lorsque vous créez un cluster à l'aide de la console Amazon EMR, de l'API EMR AWS CLI ou de l'API EMR.
Utilisez les références suivantes pour comprendre les paramètres de configuration de cluster disponibles pour l'architecture Kerberos que vous choisissez. Les paramètres de la console Amazon EMR sont affichés. Pour les options d'interface de ligne de commande correspondantes, consultez [Exemples de configuration](emr-kerberos-config-examples.md).
| Paramètre | Description |
| --- | --- |
| Domaine | Nom du domaine Kerberos du cluster. La convention Kerberos consiste à définir un nom identique à celui du domaine, mais en majuscules. Par exemple, pour le domaine `ec2.internal`, on utilise `EC2.INTERNAL` comme nom de domaine. |
| Mot de passe administrateur du KDC | Mot de passe utilisé dans le cluster pour `kadmin` ou `kadmin.local`. Ce sont des interfaces de ligne de commande pour le système d'administration Kerberos V5, qui assure la gestion des principaux Kerberos, des stratégies de mot de passe et des fichiers keytab du cluster. |
| Mot de passe du principal de l'approbation inter-domaines (facultatif) | Obligatoire en cas d'établissement d'une approbation inter-domaines. Mot de passe du principal de l'approbation inter-domaines, qui doit être identique dans tous les domaines. Utilisez un mot de passe fort. |
| Utilisateur de jonction du domaine Active Directory (facultatif) | Obligatoire lors de l'utilisation d'Active Directory dans une approbation inter-domaines. Il s'agit du nom de connexion d'utilisateur d'un compte Active Directory avec l'autorisation d'ajouter des ordinateurs au domaine. Amazon EMR utilise cette identité pour joindre le cluster au domaine. Pour de plus amples informations, veuillez consulter [Étape 3 : Ajouter des comptes au domaine pour le cluster EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Mot de passe de jonction du domaine Active Directory (facultatif) | Le mot de passe de l'utilisateur de jonction de domaine Active Directory. Pour de plus amples informations, veuillez consulter [Étape 3 : Ajouter des comptes au domaine pour le cluster EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Exemples de configuration
Les exemples suivants illustrent les configurations de sécurité et les configurations de cluster pour les scénarios courants. AWS CLI les commandes sont affichées par souci de concision.
## KDC local
Les commandes suivantes créent un cluster avec un KDC dédié au cluster qui s'exécute sur le nœud primaire. Une configuration supplémentaire du cluster est requise. Pour de plus amples informations, veuillez consulter [Configuration d'un cluster Amazon EMR pour les utilisateurs HDFS authentifiés par Kerberos et les connexions SSH](emr-kerberos-configuration-users.md).
**Créer une configuration de sécurité**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Créer un cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## KDC dédié au cluster avec approbation inter-domaines Active Directory
Les commandes suivantes créent un cluster avec un KDC dédié au cluster qui s'exécute sur le nœud primaire avec une approbation inter-domaines à un domaine Active Directory. Une configuration supplémentaire sur le cluster et dans Active Directory est requise. Pour de plus amples informations, veuillez consulter [Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory](emr-kerberos-cross-realm.md).
**Créer une configuration de sécurité**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**Créer un cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## KDC externe sur un cluster différent
Les commandes suivantes créent un cluster qui fait référence à un KDC dédié au cluster sur le nœud primaire d'un cluster différent pour authentifier les mandataires. Une configuration supplémentaire du cluster est requise. Pour de plus amples informations, veuillez consulter [Configuration d'un cluster Amazon EMR pour les utilisateurs HDFS authentifiés par Kerberos et les connexions SSH](emr-kerberos-configuration-users.md).
**Créer une configuration de sécurité**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Créer un cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## KDC de cluster externe avec approbation inter-domaines Active Directory
Les commandes suivantes créent un cluster sans KDC. Le cluster fait référence à un KDC dédié au cluster s'exécutant sur le nœud primaire d'un cluster différent pour authentifier les mandataires. Ce KDC dispose d'une approbation inter-domaines avec un contrôleur de domaine Active Directory. Une configuration supplémentaire est requise sur le nœud primaire avec le KDC. Pour de plus amples informations, veuillez consulter [Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory](emr-kerberos-cross-realm.md).
**Créer une configuration de sécurité**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**Créer un cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Configuration d'un cluster Amazon EMR pour les utilisateurs HDFS authentifiés par Kerberos et les connexions SSH
Amazon EMR crée des clients d'utilisateur authentifiés via Kerberos pour les applications qui s'exécutent sur le cluster. Par exemple, l'utilisateur `hadoop`, l'utilisateur `spark` et d'autres encore. Vous pouvez également ajouter des utilisateurs qui sont authentifiés pour les processus de cluster en utilisant Kerberos. Les utilisateurs authentifiés peuvent alors se connecter au cluster avec leurs informations d'identification Kerberos et utiliser des applications. Les configurations suivantes sont requises pour qu'un utilisateur puisse s'authentifier auprès du cluster :
+ Un compte Linux correspondant au principal Kerberos dans le KDC doit exister sur le cluster. Amazon EMR le fait automatiquement dans les architectures qui s'intègrent à Active Directory.
+ Vous devez créer un répertoire d'utilisateurs HDFS sur le nœud primaire pour chaque utilisateur et donner à l'utilisateur les autorisations pour le répertoire.
+ Vous devez configurer le service SSH afin que la GSSAPI soit activée sur le nœud primaire. De plus, les utilisateurs doivent disposer d'un client SSH avec la GSSAPI activée.
## Ajout d'utilisateurs Linux et de mandataires Kerberos au nœud primaire
Si vous n'utilisez pas Active Directory, vous devez créer des comptes Linux sur le nœud primaire du cluster et ajouter des mandataires au KDC pour ces utilisateurs Linux. Cela comprend un principal dans le KDC pour le nœud primaire. En plus des principaux d'utilisateurs, le KDC qui s'exécute sur le nœud primaire nécessite un mandataire pour l'hôte local.
Lorsque votre architecture inclut l'intégration d'Active Directory, les utilisateurs et mandataires Linux sur le KDC local sont créés automatiquement, le cas échéant. Vous pouvez ignorer cette étape. Pour plus d’informations, consultez [Relation d'approbation inter-domaines](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) et [KDC externe – cluster KDC sur un autre cluster avec une relation d'approbation inter-domaines Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**Important**
Le KDC, ainsi que la base de données des principaux, sont perdus lorsque le nœud primaire est résilié, car ce dernier utilise un stockage éphémère. Si vous créez des utilisateurs pour les connexions SSH, nous vous recommandons d'établir une confiance interdomaines avec un KDC externe configuré pour la haute disponibilité. Par ailleurs, si vous créez des utilisateurs pour les connexions SSH à l'aide de comptes Linux, automatisez le processus de création de compte à l'aide d'actions et de scripts d'amorçage afin de pouvoir le répéter lors de la création d'un nouveau cluster.
La soumission d'une étape au cluster après l'avoir créée ou lorsque vous créez le cluster est la solution la plus simple pour ajouter des utilisateurs et des mandataires KDC. Sinon, vous pouvez vous connecter au nœud primaire à l'aide d'une paire de clés EC2 en tant qu'utilisateur `hadoop` par défaut pour exécuter les commandes. Pour de plus amples informations, veuillez consulter [Connectez-vous au nœud principal du cluster Amazon EMR à l'aide de SSH](emr-connect-master-node-ssh.md).
L'exemple suivant envoie un script bash `configureCluster.sh` à un cluster qui existe déjà, en faisant référence à son ID de cluster. Le script est enregistré dans Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
L'exemple suivant illustre le contenu du script `configureCluster.sh`. Le script gère également la création des annuaires d'utilisateurs HDFS et l'activation de GSSAPI pour SSH, qui sont abordés dans les sections suivantes.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## Ajout de répertoires HDFC d'utilisateurs
Pour autoriser vos utilisateurs à se connecter au cluster afin d'exécuter des travaux Hadoop, vous devez ajouter des annuaires d'utilisateurs HDFS pour leurs comptes Linux et accorder à chaque utilisateur la propriété de son annuaire.
La soumission d'une étape au cluster après l'avoir créée ou lorsque vous créez le cluster est la solution la plus simple pour créer des annuaires HDFS. Sinon, vous pourriez vous connecter au nœud primaire à l'aide d'une paire de clés EC2 en tant qu'utilisateur `hadoop` par défaut pour exécuter les commandes. Pour de plus amples informations, veuillez consulter [Connectez-vous au nœud principal du cluster Amazon EMR à l'aide de SSH](emr-connect-master-node-ssh.md).
L'exemple suivant envoie un script bash `AddHDFSUsers.sh` à un cluster qui existe déjà, en faisant référence à son ID de cluster. Le script est enregistré dans Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
L'exemple suivant illustre le contenu du script `AddHDFSUsers.sh`.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## Activation de GSSAPI pour SSH
Afin de permettre aux utilisateurs authentifiés par Kerberos de se connecter au nœud primaire à l'aide de SSH, le service SSH doit disposer de l'authentification GSSAPI activée. Pour activer la GSSAPI, exécutez les commandes suivantes à partir de la ligne de commande du nœud primaire ou utilisez une étape pour l'exécuter en tant que script. Une fois que vous avez reconfiguré SSH, vous devez redémarrer le service.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# Utilisation de SSH pour se connecter à des clusters Kerberisés avec Amazon EMR
Cette section illustre les étapes pour qu'un utilisateur authentifié par Kerberos se connecte au nœud primaire d'un cluster EMR.
Chaque ordinateur qui est utilisé pour une connexion SSH doit avoir le client SSH et les applications client Kerberos installés. Il est probable que les ordinateurs Linux comportent ces éléments par défaut. Par exemple, OpenSSH est installé sur la plupart des systèmes d'exploitation Linux, Unix et macOS. Vous pouvez vérifier un client SSH en tapant **ssh** dans la ligne de commande. Si votre ordinateur ne reconnaît pas la commande, installez un client SSH pour vous connecter au nœud primaire. Le projet OpenSSH offre une implémentation gratuite de la suite entière des outils SSH. Pour plus d'informations, consultez le site Web [OpenSSH](http://www.openssh.org/). Les utilisateurs Windows peuvent utiliser des applications telles que [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) en tant que client SSH.
Pour plus d'informations sur vos connexions SSH, consultez [Connexion à un cluster Amazon EMR](emr-connect-master-node.md).
SSH utilise GSSAPI pour authentifier les clients Kerberos et vous devez activer l'authentification GSSAPI pour le service SSH sur le nœud primaire du cluster. Pour de plus amples informations, veuillez consulter [Activation de GSSAPI pour SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Les clients SSH doivent également utiliser GSSAPI.
Dans les exemples suivants, pour *MasterPublicDNS* utiliser la valeur qui apparaît pour **Master public DNS** dans l'onglet **Résumé** du volet des détails du cluster, par exemple,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Conditions préalables pour krb5.conf (non Active Directory)
Lorsque vous utilisez une configuration sans l'intégration d'Active Directory, en plus du client SSH et des applications clientes Kerberos, chaque ordinateur client doit avoir une copie du fichier `/etc/krb5.conf` correspondant au fichier `/etc/krb5.conf` sur le nœud primaire du cluster.
**Pour copier le fichier krb5.conf**
1. Utilisez SSH pour vous connecter au nœud primaire à l'aide d'une paire de clés EC2 et de l'utilisateur `hadoop` par défaut. Par exemple, `hadoop@MasterPublicDNS`. Pour obtenir des instructions complètes, consultez [Connexion à un cluster Amazon EMR](emr-connect-master-node.md).
1. Dans le nœud primaire, copiez le contenu du fichier `/etc/krb5.conf`. Pour de plus amples informations, veuillez consulter [Connexion à un cluster Amazon EMR](emr-connect-master-node.md).
1. Sur chaque ordinateur client qui sera utilisé pour se connecter au cluster, créez un fichier `/etc/krb5.conf` identique à partir de la copie que vous avez créée à l'étape précédente.
## Utilisation de Kinit et SSH
Chaque fois qu'un utilisateur se connecte à partir d'un ordinateur client à l'aide des informations d'identification Kerberos, l'utilisateur doit d'abord renouveler un ticket Kerberos pour leurs utilisateurs sur l'ordinateur client. En outre, le client SSH doit être configuré pour utiliser l'authentification GSSAPI.
**Utilisation de SSH pour se connecter aux clusters EMR Kerberos**
1. Utilisez `kinit` pour renouveler vos tickets Kerberos, comme illustré dans l'exemple suivant
```
kinit user1
```
1. Utilisez un client `ssh` en même temps que le principal que vous avez créé dans le KDC dédié au cluster ou dans le nom d'utilisateur Active Directory. Assurez-vous que l'authentification GSSAPI est activée, telle qu'illustrée dans les exemples suivants.
**Exemple : utilisateurs Linux**
L'option `-K `spécifie l'authentification GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Exemple : utilisateurs Windows (PuTTY)**
Assurez-vous que l'authentification GSSAPI est activée pour la session, telle qu'illustrée :
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutoriel : Configuration d'un KDC dédié au cluster avec Amazon EMR
Cette rubrique vous guide dans la création d'un cluster avec un centre de* diffusion d'une clé (KDC)* dédié au cluster, dans l'ajout manuel de comptes Linux à tous les nœuds du cluster, dans l'ajout de principaux Kerberos au KDC sur le nœud primaire et dans la vérification de l'installation d'un client Kerberos sur les ordinateurs clients.
Pour plus d'informations sur la prise en charge de Kerberos et de KDC par Amazon EMR, ainsi que des liens vers la documentation MIT Kerberos, consultez [Utilisation de Kerberos pour l'authentification avec Amazon EMR](emr-kerberos.md).
## Étape 1 : Créer le cluster activé pour Kerberos
1. Créez une configuration de sécurité qui active Kerberos. L'exemple suivant illustre une `create-security-configuration` commande utilisant le AWS CLI qui spécifie la configuration de sécurité sous la forme d'une structure JSON intégrée. Vous pouvez également référencer un fichier enregistré localement.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Créez un cluster qui fait référence à la configuration de sécurité, établit les attributs Kerberos du cluster et ajoute des comptes Linux à l'aide d'une action d'amorçage. L'exemple suivant illustre l'utilisation d'une commande `create-cluster ` à partir de l' AWS CLI. La commande fait référence à la configuration de sécurité que vous avez créée ci-dessus, `MyKerberosConfig`. Elle fait également référence à un script simple, `createlinuxusers.sh`, sous forme d'action d'amorçage, que vous créez et chargez dans Amazon S3 avant la création du cluster.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
Le code suivant illustre le contenu du script `createlinuxusers.sh` qui ajoute user1, user2 et user3 à chaque nœud du cluster. Dans l'étape suivante, vous ajoutez ces utilisateurs en tant que principaux KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Étape 2 : Ajouter des principaux au KDC, créer des répertoires d'utilisateurs HDFS et configurer SSH
Le KDC qui s'exécute sur le nœud primaire requiert que vous ajoutiez un principal pour l'hôte local et pour chaque utilisateur que vous créez sur le cluster. Vous pouvez également créer des annuaires HDFS pour chaque utilisateur qui a besoin de se connecter au cluster et d'exécuter des travaux Hadoop. De même, configurez le service SSH pour activer l'authentification GSSAPI, qui est obligatoire pour Kerberos. Une fois que vous avez activé GSSAPI, redémarrez le service SSH.
La manière la plus simple d'effectuer ces tâches est d'envoyer une étape au cluster. L'exemple suivant envoie un script bash `configurekdc.sh` au cluster que vous avez créé dans l'étape précédente, en faisant référence à son ID de cluster. Le script est enregistré dans Amazon S3. Sinon, vous pouvez vous connecter au nœud primaire à l'aide d'une paire de clés EC2 pour exécuter les commandes ou envoyer l'étape lors de la création du cluster.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
Le code suivant illustre le contenu du script `configurekdc.sh`.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Les utilisateurs que vous avez ajoutés doivent maintenant être en mesure de se connecter au cluster à l'aide de SSH. Pour de plus amples informations, veuillez consulter [Utilisation de SSH pour se connecter à des clusters Kerberisés avec Amazon EMR](emr-kerberos-connect-ssh.md).
# Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory
Lorsque vous configurez une approbation inter-domaines, vous autorisez des principaux (généralement des utilisateurs) provenant d'un autre domaine Kerberos à s'authentifier auprès de composants d'application sur le cluster EMR. Le *centre de distribution de clés (KDC)* dédié au cluster établit une relation de confiance avec un autre KDC en utilisant un principe *inter-domaines* qui existe dans les deux. KDCs Le nom et le mot de passe du principal correspondent exactement.
Une approbation inter-domaines nécessite que les KDC puissent s'atteindre mutuellement via le réseau et résoudre leurs noms de domaine mutuels. Les étapes permettant d'établir une relation d'approbation inter-domaines avec un contrôleur de domaine Microsoft AD s'exécutant en tant qu'instance EC2 sont fournies ci-dessous, ainsi qu'un exemple de configuration de réseau qui fournit la connectivité et la résolution du nom de domaine requises. Toute configuration réseau autorisant le trafic réseau requis entre les deux KDCs est acceptable.
Le cas échéant, une fois l'approbation inter-domaines établie avec Active Directory à l'aide d'un KDC sur un cluster, vous pouvez créer un autre cluster à l'aide d'une autre configuration de sécurité pour référencer le KDC sur le premier cluster comme KDC externe. Pour un exemple de configuration de sécurité et d'installation de cluster, consultez [KDC de cluster externe avec approbation inter-domaines Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Pour plus d'informations sur la prise en charge de Kerberos et de KDC par Amazon EMR, ainsi que des liens vers la documentation MIT Kerberos, consultez [Utilisation de Kerberos pour l'authentification avec Amazon EMR](emr-kerberos.md).
**Important**
Amazon EMR ne prend pas en charge les approbations entre domaines avec. AWS Directory Service for Microsoft Active Directory
[Étape 1 : Configuration du VPC et du sous-réseau](#emr-kerberos-ad-network)
[Étape 2 : Lancer et installer le contrôleur de domaine Active Directory](#emr-kerberos-ad-dc)
[Étape 3 : Ajouter des comptes au domaine pour le cluster EMR](#emr-kerberos-ad-users)
[Étape 4 : Configurer une approbation entrante sur le contrôleur de domaine Active Directory](#emr-kerberos-ad-configure-trust)
[Étape 5 : Utiliser un groupe d'options DHCP pour spécifier le contrôleur de domaine Active Directory en tant que serveur DNS de VPC](#emr-kerberos-ad-DHCP)
[Étape 6 : Lancer un cluster EMR activé pour Kerberos](#emr-kerberos-ad-cluster)
[Étape 7 : Créer des utilisateurs HDFS et définir des autorisations sur le cluster pour les comptes Active Directory](#emr-kerberos-ad-hadoopuser)
## Étape 1 : Configuration du VPC et du sous-réseau
Les étapes suivantes montrent la création d'un VPC et d'un sous-réseau afin que le KDC dédié au cluster puisse atteindre le contrôleur de domaine Active Directory et résoudre son nom de domaine. Au cours de ces étapes, la résolution du nom de domaine est fournie en faisant référence au contrôleur de domaine Active Directory en tant que serveur de noms de domaine dans le jeu d'options DHCP. Pour de plus amples informations, veuillez consulter [Étape 5 : Utiliser un groupe d'options DHCP pour spécifier le contrôleur de domaine Active Directory en tant que serveur DNS de VPC](#emr-kerberos-ad-DHCP).
Le KDC et le contrôleur de domaine Active Directory doivent être en mesure de résoudre leurs noms de domaine respectifs. Ceci permet à Amazon EMR d'associer des ordinateurs au domaine et de configurer automatiquement les comptes Linux et les paramètres SSH correspondants sur les instances de cluster.
Si Amazon EMR ne peut pas résoudre le nom de domaine, vous pouvez référencer l'approbation à l'aide de l'adresse IP du contrôleur de domaine Active Directory. Cependant, vous devez ajouter manuellement les comptes Linux, ajouter les principaux correspondants au KDC dédié au cluster et configurer SSH.
**Pour configurer le VPC et le sous-réseau**
1. Créez un Amazon VPC avec un seul sous-réseau public. Pour plus d'informations, consultez [Étape 1 : Créer le VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) dans le *Guide de démarrage Amazon VPC*.
**Important**
Lorsque vous utilisez un contrôleur de domaine Microsoft Active Directory, choisissez un bloc CIDR pour le cluster EMR afin que IPv4 toutes les adresses comportent moins de neuf caractères (par exemple, 10.0.0.0/16). Cela est dû au fait que les noms DNS des ordinateurs du cluster sont utilisés lorsque les ordinateurs rejoignent le répertoire Active Directory. AWS attribue des [noms d'hôte DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) en fonction de l' IPv4 adresse, de telle sorte que des adresses IP plus longues peuvent entraîner des noms DNS de plus de 15 caractères. Active Directory a une limite de 15 caractères pour l'enregistrement des noms d'ordinateurs joints et tronque les noms plus longs, ce qui peut provoquer des erreurs imprévisibles.
1. Supprimez le jeu d'options DHCP par défaut attribué au VPC. Pour plus d'informations, consultez [Modification d'un VPC pour qu'il n'utilise pas d'options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Par la suite, vous ajoutez un nouveau jeu d'options qui spécifie le contrôleur de domaine Active Directory en tant que serveur DNS.
1. Vérifiez que la prise en charge de DNS est activée pour le VPC, c'est-à-dire que les noms d'hôte DNS et la résolution DNS sont activés. Ils sont activés par défaut. Pour plus d'informations, consultez [Mise à jour de la prise en charge de DNS de votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Vérifiez que votre VPC dispose d'une passerelle Internet attachée (c'est le cas par défaut). Pour de plus amples informations, veuillez consulter [Création et attachement d'une passerelle Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**Note**
Une passerelle Internet est utilisée dans cet exemple, car vous établissez un nouveau contrôleur de domaine pour le VPC. Il peut cependant arriver qu'aucune passerelle Internet ne soit requise pour votre application. La seule exigence est que le KDC dédié au cluster puisse accéder au contrôleur de domaine Active Directory.
1. Créez une table de routage personnalisée, ajoutez une route qui mène à la passerelle Internet, puis attachez-la à votre sous-réseau. Pour plus d'informations, consultez [Création d'une table de routage personnalisée](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Lorsque vous lancez l'instance EC2 pour le contrôleur de domaine, celle-ci doit avoir une IPv4 adresse publique statique pour que vous puissiez vous y connecter via RDP. La méthode la plus simple consiste à configurer votre sous-réseau pour attribuer automatiquement des adresses publiques IPv4 . Ce n'est pas le paramètre par défaut lorsqu'un sous-réseau est créé. Pour plus d'informations, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Vous avez aussi la possibilité d'attribuer l'adresse lorsque vous lancez l'instance. Pour plus d'informations, consultez [Attribuer une IPv4 adresse publique lors du lancement de l'instance](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Lorsque vous avez terminé, notez votre VPC et votre sous-réseau. IDs Vous les utiliserez ultérieurement lorsque vous lancerez le contrôleur de domaine Active Directory et le cluster.
## Étape 2 : Lancer et installer le contrôleur de domaine Active Directory
1. Lancez une instance EC2 à partir de l'AMI de base de Microsoft Windows Server 2016. Nous vous recommandons le type d'instance m4.xlarge ou plus. Pour plus d'informations, consultez la section [Lancement d'une AWS Marketplace instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) dans le guide de l'*utilisateur Amazon EC2*.
1. Notez l'ID de groupe du groupe de sécurité associé à l'instance EC2. Vous en avez besoin pour [Étape 6 : Lancer un cluster EMR activé pour Kerberos](#emr-kerberos-ad-cluster). Nous utilisons*sg-012xrlmdomain345*. Vous pouvez aussi spécifier différents groupes de sécurité pour le cluster EMR et cette instance qui autorise le trafic entre eux. Pour plus d'informations, veuillez consulter la section [Amazon EC2 security groups for Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) (français non garanti) dans le *Guide de l'utilisateur Amazon EC2*.
1. Connectez-vous à l'instance EC2 à l'aide de RDP. Pour plus d'informations, consultez la section [Connexion à votre instance Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) dans le guide de l'*utilisateur Amazon EC2*.
1. Démarrez le **Gestionnaire de serveurs** pour installer et configurer le rôle des services de domaine Active Directory sur le serveur. Configurez le serveur comme contrôleur de domaine et attribuez un nom de domaine (l'exemple que nous utilisons ici est `ad.domain.com`). Notez le nom de domaine, car vous en aurez besoin plus tard lorsque vous créerez la configuration de sécurité et le cluster EMR. Si vous configurez Active Directory pour la première fois, vous pouvez suivre les instructions indiquées dans [Comment configurer Active Directory (AD) dans Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
L'instance redémarre une fois que vous avez terminé.
## Étape 3 : Ajouter des comptes au domaine pour le cluster EMR
RDP sur le contrôleur de domaine Active Directory pour créer des comptes dans les utilisateurs et ordinateurs Active Directory pour chaque utilisateur de cluster. Pour plus d'informations, consultez la section [Création d'un compte d'utilisateur dans Utilisateurs et ordinateurs Active Directory](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) sur le site *Microsoft Learn*. Notez le **nom de connexion** de chaque utilisateur. Vous en aurez besoin ultérieurement lorsque vous configurez le cluster.
En outre, créez un compte avec des privilèges suffisants pour joindre des ordinateurs au domaine. Vous spécifiez ce compte lorsque vous créez un cluster. Amazon EMR l'utilise pour joindre les instances de cluster au domaine. Vous spécifiez ce compte et son mot de passe [Étape 6 : Lancer un cluster EMR activé pour Kerberos](#emr-kerberos-ad-cluster). Pour déléguer des privilèges de jointure d'ordinateur au compte, nous vous recommandons de créer un groupe avec des privilèges de jointure, puis d'affecter l'utilisateur au groupe. Pour plus d'informations, consultez [Délégation des privilèges de jonction d'annuaire](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) dans le *Guide d'administration AWS Directory Service *.
## Étape 4 : Configurer une approbation entrante sur le contrôleur de domaine Active Directory
L'exemple des commandes ci-dessous permet de créer une relation d'approbation dans Active Directory, qui est une approbation de domaine unidirectionnelle, entrante et non transitive avec le KDC dédié au cluster. L'exemple que nous utilisons pour le domaine du cluster est `EC2.INTERNAL`. Remplacez le *KDC-FQDN* par le nom **DNS public** indiqué pour le nœud principal Amazon EMR hébergeant le KDC. Le paramètre `passwordt` spécifie le **mot de passe du principal inter-domaines**, que vous spécifiez en même temps que le **domaine** du cluster lorsque vous créez un cluster. Le nom de domaine est dérivé du nom de domaine par défaut dans `us-east-1` pour le cluster. Le `Domain` est le domaine Active Directory dans lequel vous créez la stratégie d'approbation qui est en minuscules par convention. L'exemple utilise `ad.domain.com`
Ouvrez l'invite de commande Windows avec des privilèges d'administrateur et entrez les commandes suivantes pour créer la relation d'approbation sur le contrôleur de domaine Active Directory :
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## Étape 5 : Utiliser un groupe d'options DHCP pour spécifier le contrôleur de domaine Active Directory en tant que serveur DNS de VPC
Maintenant que le contrôleur de domaine Active Directory est configuré, vous devez configurer le VPC afin de l'utiliser comme serveur de nom de domaine pour la résolution des noms au sein de votre VPC. Pour ce faire, attachez un jeu d'options DHCP. Indiquez le **nom de domaine** comme nom de domaine de votre cluster (par exemple, `ec2.internal` si votre cluster se trouve dans la région us-est-1 ou `region.compute.internal` pour les autres régions). Pour les **serveurs de noms de domaine**, vous devez spécifier l'adresse IP du contrôleur de domaine Active Directory (qui doit être accessible depuis le cluster) comme première entrée, suivie du **AmazonProvidedDNS** (par exemple ***xx.xx.xx.xx*, AmazonProvided DNS**). Pour plus d'informations, consultez [Modification des jeux d'options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Étape 6 : Lancer un cluster EMR activé pour Kerberos
1. Dans Amazon EMR, créez une configuration de sécurité qui spécifie le contrôleur de domaine Active Directory que vous avez créé dans les étapes précédentes. Un exemple de commande est présenté ci-dessous. Remplacez le domaine, `ad.domain.com`, par le nom du domaine que vous avez spécifié dans [Étape 2 : Lancer et installer le contrôleur de domaine Active Directory](#emr-kerberos-ad-dc).
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. Créez le cluster avec les attributs suivants :
+ Utilisez l’option `--security-configuration` pour spécifier la configuration de sécurité que vous avez créée. Nous utilisons *MyKerberosConfig* dans l'exemple.
+ Utilisez la propriété `SubnetId` de l'`--ec2-attributes option` pour spécifier le sous-réseau que vous avez créé dans [Étape 1 : Configuration du VPC et du sous-réseau](#emr-kerberos-ad-network). Nous utilisons *step1-subnet* dans l'exemple.
+ Utilisez `AdditionalMasterSecurityGroups` et `AdditionalSlaveSecurityGroups` de l'option `--ec2-attributes` pour spécifier que le groupe de sécurité associé au contrôleur de domaine AD de [Étape 2 : Lancer et installer le contrôleur de domaine Active Directory](#emr-kerberos-ad-dc) est associé au nœud primaire du cluster, ainsi qu'aux nœuds principaux et de tâches. Nous utilisons *sg-012xrlmdomain345* dans l'exemple.
Utilisez `--kerberos-attributes` pour spécifier les attributs Kerberos suivants spécifiques au cluster :
+ Le domaine du cluster que vous avez spécifié lors de la configuration du contrôleur de domaine Active Directory.
+ Le mot de passe du principal d'approbation inter-domaines que vous avez spécifié sous la forme `passwordt` dans [Étape 4 : Configurer une approbation entrante sur le contrôleur de domaine Active Directory](#emr-kerberos-ad-configure-trust).
+ Un `KdcAdminPassword`, que vous pouvez utiliser pour gérer le KDC dédié au cluster.
+ Le nom de connexion et le mot de passe utilisateur du compte Active Directory avec des privilèges de jointure d'ordinateur que vous avez créé dans [Étape 3 : Ajouter des comptes au domaine pour le cluster EMR](#emr-kerberos-ad-users).
L'exemple suivant lance un cluster activé pour Kerberos.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## Étape 7 : Créer des utilisateurs HDFS et définir des autorisations sur le cluster pour les comptes Active Directory
Lors de la mise en place d'une relation d'approbation avec Active Directory, Amazon EMR crée des utilisateurs Linux sur le cluster pour chaque compte Active Directory. Par exemple, le nom de connexion utilisateur `LiJuan` dans Active Directory dispose d'un compte Linux `lijuan`. Les noms d'utilisateurs Active Directory peuvent contenir des lettres majuscules, mais Linux ne prend pas en charge la casse Active Directory.
Pour autoriser vos utilisateurs à se connecter au cluster afin d'exécuter des travaux Hadoop, vous devez ajouter des annuaires d'utilisateurs HDFS pour leurs comptes Linux et accorder à chaque utilisateur la propriété de son annuaire. Pour ce faire, nous vous recommandons d'exécuter un script enregistré dans Amazon S3 sous la forme d'une étape de cluster. Sinon, vous pouvez exécuter les commandes dans le script ci-dessous à partir de l'interface de ligne de commande sur le nœud primaire. Utilisez la paire de clés EC2 que vous avez spécifiée lors de la création du cluster pour vous connecter au nœud primaire via SSH en tant qu'utilisateur Hadoop. Pour de plus amples informations, veuillez consulter [Utiliser une paire de clés EC2 pour les informations d'identification SSH pour Amazon EMR](emr-plan-access-ssh.md).
Exécutez la commande suivante pour ajouter une étape au cluster qui exécute un script,*AddHDFSUsers.sh*.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Le contenu du fichier *AddHDFSUsers.sh* est le suivant.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Groupes Active Directory mappés aux groupes Hadoop
Amazon EMR utilise System Security Services Daemon (SSD) pour mapper des groupes Active Directory aux groupes Hadoop. Pour confirmer des mappages de groupe, après la connexion au nœud primaire telle que décrite dans [Utilisation de SSH pour se connecter à des clusters Kerberisés avec Amazon EMR](emr-kerberos-connect-ssh.md), vous pouvez utiliser la commande `hdfs groups` pour confirmer que les groupes Active Directory auxquels votre compte Active Directory appartient ont été mappés aux groupes Hadoop de l'utilisateur Hadoop correspondant sur le cluster. Vous pouvez également consulter d'autres mappages de groupe d'utilisateurs en spécifiant un ou plusieurs noms d'utilisateur avec la commande, par exemple `hdfs groups lijuan`. Pour de plus amples informations, veuillez consulter [groupes](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) dans le [Guide de commandes HDFS d'Apache](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Utilisation de serveurs Active Directory ou LDAP pour l'authentification avec Amazon EMR
Avec les versions 6.12.0 et supérieures d'Amazon EMR, vous pouvez utiliser le protocole LDAP sur SSL (LDAPS) pour lancer un cluster qui s'intègre nativement au serveur d'identité de votre entreprise. LDAP (Lightweight Directory Access Protocol) est un protocole d'application ouvert et neutre qui permet d'accéder à des données et de les conserver. LDAP est couramment utilisé pour l'authentification des utilisateurs par rapport aux serveurs d'identité d'entreprise hébergés sur des applications telles que Active Directory (AD) et OpenLDAP. Grâce à cette intégration native, vous pouvez utiliser votre serveur LDAP pour authentifier les utilisateurs sur Amazon EMR.
Les éléments principaux de l'intégration LDAP d'Amazon EMR sont les suivants :
+ Amazon EMR configure les applications prises en charge pour qu'elles s'authentifient en votre nom à l'aide de l'authentification LDAP.
+ Amazon EMR configure et maintient la sécurité des applications prises en charge avec le protocole Kerberos. Vous n'avez pas besoin de saisir de commandes ou de scripts.
+ Vous bénéficiez d'un contrôle précis des accès (FGAC) via l'autorisation Apache Ranger pour la base de données et les tables Hive Metastore. Pour plus d’informations, consultez [Intégration d'Amazon EMR avec Apache Ranger](emr-ranger.md).
+ Lorsque vous avez besoin d'informations d'identification LDAP pour accéder à un cluster, vous bénéficiez d'un contrôle précis des accès (FGAC) sur les personnes qui peuvent accéder à vos clusters EMR via SSH.
Les pages suivantes présentent une vue d'ensemble conceptuelle, les conditions préalables et les étapes à suivre pour lancer un cluster EMR avec l'intégration LDAP d'Amazon EMR.
**Topics**
+ [
# Présentation de LDAP avec Amazon EMR
](ldap-overview.md)
+ [
# Composants LDAP pour Amazon EMR
](ldap-components.md)
+ [
# Prise en charge des applications et considérations relatives à LDAP pour Amazon EMR
](ldap-considerations.md)
+ [
# Configuration et lancement d'un cluster EMR avec LDAP
](ldap-setup.md)
+ [
# Exemples d'utilisation de LDAP avec Amazon EMR
](ldap-examples.md)
# Présentation de LDAP avec Amazon EMR
LDAP (Lightweight Directory Access Protocol) est un protocole logiciel que les administrateurs réseau utilisent pour gérer et contrôler l'accès aux données en authentifiant les utilisateurs au sein du réseau d'une entreprise. Le protocole LDAP stocke les informations dans une structure d'annuaire hiérarchique et arborescente. Pour plus d'informations, consultez la section [Concepts de base du protocole LDAP](https://ldap.com/basic-ldap-concepts/) sur *LDAP.com*.
Au sein du réseau d'une entreprise, de nombreuses applications peuvent utiliser le protocole LDAP pour authentifier les utilisateurs. Avec l'intégration LDAP d'Amazon EMR, les clusters EMR peuvent utiliser nativement le même protocole LDAP avec une configuration de sécurité supplémentaire.
Amazon EMR prend en charge deux implémentations majeures du protocole LDAP : **Active Directory** et **OpenLDAP**. Bien que d'autres implémentations soient possibles, la plupart d'entre elles s'adaptent aux mêmes protocoles d'authentification qu'Active Directory ou OpenLDAP.
## Active Directory (AD)
Active Directory (AD) est un service d'annuaire de Microsoft pour les réseaux de domaines Windows. AD est inclus dans la plupart des systèmes d'exploitation Windows Server et peut communiquer avec les clients via les protocoles LDAP et LDAPS. Pour l'authentification, Amazon EMR tente d'établir une liaison utilisateur avec votre instance AD en utilisant le nom d'utilisateur principal (UPN) comme nom distinctif et mot de passe. L'UPN utilise le format standard `username@domain_name`.
## OpenLDAP
OpenLDAP est une implémentation gratuite et open source du protocole LDAP. Pour l'authentification, Amazon EMR tente une liaison utilisateur avec votre instance OpenLDAP avec le nom de domaine entièrement qualifié (FQDN) comme nom distinctif et mot de passe. Le FQDN utilise le format standard `username_attribute=username,LDAP_user_search_base`. En général, la valeur `username_attribute` est `uid`, et la valeur `LDAP_user_search_base` contient les attributs de l'arbre qui mène à l'utilisateur. Par exemple, `ou=People,dc=example,dc=com`.
D'autres implémentations libres et open source du protocole LDAP suivent généralement un FQDN similaire à celui d'OpenLDAP pour les noms distinctifs de leurs utilisateurs.
# Composants LDAP pour Amazon EMR
Vous pouvez utiliser votre serveur LDAP pour vous authentifier auprès d'Amazon EMR et de toutes les applications que l'utilisateur utilise directement sur le cluster EMR grâce aux composants suivants.
**Agent secret**
L'*agent secret* est un processus intégré au cluster qui authentifie toutes les demandes des utilisateurs. L'agent secret crée le lien utilisateur vers votre serveur LDAP pour le compte des applications prises en charge sur le cluster EMR. L'agent secret s'exécute en tant qu'utilisateur `emrsecretagent` et écrit des journaux dans le répertoire `/emr/secretagent/log`. Ces journaux fournissent des détails sur l'état de la demande d'authentification de chaque utilisateur et sur les erreurs susceptibles de survenir lors de l'authentification de l'utilisateur.
**Démon des services de sécurité du système (SSSD)**
*SSSD* est un démon qui s'exécute sur chaque nœud d'un cluster EMR compatible LDAP. SSSD crée et gère un utilisateur UNIX pour synchroniser votre identité d'entreprise distante avec chaque nœud. Les applications basées sur Yarn telles que Hive et Spark nécessitent qu'un utilisateur UNIX local existe sur chaque nœud qui exécute une requête pour un utilisateur.
# Prise en charge des applications et considérations relatives à LDAP pour Amazon EMR
Cette rubrique répertorie les applications prises en charge, les fonctionnalités prises en charge et les fonctionnalités non prises en charge.
## Applications prises en charge avec LDAP pour Amazon EMR
**Important**
Les applications répertoriées sur cette page sont les seules applications prises en charge par Amazon EMR pour LDAP. Pour garantir la sécurité du cluster, vous ne pouvez inclure des applications compatibles LDAP que lorsque vous créez un cluster EMR avec LDAP activé. Si vous tentez d'installer d'autres applications non prises en charge, Amazon EMR rejettera votre demande de nouveau cluster.
Les versions 6.12 et supérieures d'Amazon EMR prennent en charge l'intégration LDAP avec les applications suivantes :
+ Apache Livy
+ Apache Hive jusqu'à HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
Vous pouvez également installer les applications suivantes sur un cluster EMR et les configurer pour répondre à vos besoins en matière de sécurité :
+ Apache Spark
+ Apache Hadoop
## Fonctionnalités prises en charge avec LDAP pour Amazon EMR
Vous pouvez utiliser les fonctionnalités Amazon EMR avec l'intégration LDAP :
**Note**
Pour garantir la sécurité des informations d'identification LDAP, vous devez utiliser le chiffrement en transit pour sécuriser le flux de données à destination et en provenance du cluster. Pour plus d'informations sur le chiffrement en transit, consultez [Chiffrez les données au repos et en transit avec Amazon EMR](emr-data-encryption.md).
+ Chiffrement en transit (obligatoire) et au repos
+ Groupes d'instances, parcs d'instances et instances Spot
+ Reconfiguration des applications sur un cluster en cours d'exécution
+ chiffrement côté serveur (SSE) EMRFS
## Fonctions non prises en charge
Tenez compte des limites suivantes lorsque vous utilisez l'intégration Amazon EMR LDAP :
+ Amazon EMR désactive les étapes pour les clusters sur lesquels le protocole LDAP est activé.
+ Amazon EMR ne prend pas en charge les rôles d'exécution ni les AWS Lake Formation intégrations pour les clusters sur lesquels LDAP est activé.
+ Amazon EMR ne prend pas en charge le protocole LDAP avec StartTLS.
+ Amazon EMR ne prend pas en charge le mode haute disponibilité (clusters avec plusieurs nœuds primaires) pour les clusters sur lesquels LDAP est activé.
+ Vous ne pouvez pas faire pivoter les informations d'identification ou les certificats de liaison pour les clusters sur lesquels LDAP est activé. Si l'un de ces champs a fait l'objet d'une rotation, nous vous recommandons de démarrer un nouveau cluster avec les informations d'identification ou les certificats de liaison mis à jour.
+ Vous devez utiliser des bases de recherche exactes avec LDAP. La base de recherche d'utilisateurs et de groupes LDAP ne prend pas en charge les filtres de recherche LDAP.
# Configuration et lancement d'un cluster EMR avec LDAP
Cette section explique comment configurer Amazon EMR pour une utilisation avec l'authentification LDAP.
**Topics**
+ [
# Ajouter AWS Secrets Manager des autorisations au rôle d'instance Amazon EMR
](ldap-setup-asm.md)
+ [
# Création de la configuration de sécurité Amazon EMR pour l'intégration LDAP
](ldap-setup-security.md)
+ [
# Lancement d'un cluster EMR qui s'authentifie auprès de LDAP
](ldap-setup-launch.md)
# Ajouter AWS Secrets Manager des autorisations au rôle d'instance Amazon EMR
Amazon EMR utilise un rôle de service IAM pour effectuer des actions en votre nom afin d'allouer et de gérer les clusters. Le rôle de service pour les instances EC2 de cluster, également appelé *profil d'instance EC2 pour Amazon EMR*, est un type de rôle de service spécial qu'Amazon EMR attribue à chaque instance EC2 d'un cluster au moment du lancement.
Pour définir les autorisations permettant à un cluster EMR d'interagir avec les données Amazon S3 et d'autres services AWS , définissez un profil d'instance Amazon EC2 personnalisé au lieu de `EMR_EC2_DefaultRole` lorsque vous lancez votre cluster. Pour plus d’informations, consultez [Rôle de service pour les instances EC2 de cluster (profil d'instance EC2)](emr-iam-role-for-ec2.md) et [Personnalisez les rôles IAM avec Amazon EMR](emr-iam-roles-custom.md).
Ajoutez les instructions suivantes au profil d'instance EC2 par défaut pour permettre à Amazon EMR de baliser les sessions et d'accéder à celles qui stockent AWS Secrets Manager les certificats LDAP.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**Note**
Vos demandes de cluster échoueront si vous oubliez le caractère générique `*` à la fin du nom du secret lorsque vous définissez les autorisations de Secrets Manager. Le caractère générique représente les versions secrètes.
Vous devez également limiter le champ d'application de la AWS Secrets Manager politique aux seuls certificats dont votre cluster a besoin pour provisionner des instances.
# Création de la configuration de sécurité Amazon EMR pour l'intégration LDAP
Avant de lancer un cluster EMR avec intégration LDAP, suivez les étapes dans [Créez une configuration de sécurité à l'aide de la console Amazon EMR ou du AWS CLI](emr-create-security-configuration.md) pour créer une configuration de sécurité Amazon EMR pour le cluster. Complétez les configurations suivantes dans le bloc `LDAPConfiguration` sous `AuthenticationConfiguration` ou dans les champs correspondants de la section **Configurations de sécurité** de la console Amazon EMR :
**`EnableLDAPAuthentication`**
Option de console : **Protocole d'authentification : LDAP**
Pour utiliser l'intégration LDAP, définissez cette option sur `true` ou sélectionnez-la comme protocole d'authentification lorsque vous créez un cluster dans la console. Par défaut, `EnableLDAPAuthentication` est `true` lorsque vous créez une configuration de sécurité dans la console Amazon EMR.
**`LDAPServerURL`**
Option de console : **Emplacement du serveur LDAP**
L'emplacement du serveur LDAP, y compris le préfixe : `ldaps://location_of_server`.
**`BindCertificateARN`**
Option de console : **Certificat SSL LDAP**
L' AWS Secrets Manager ARN qui contient le certificat pour signer le certificat SSL utilisé par le serveur LDAP. Si votre serveur LDAP est signé par une autorité de certification (CA) publique, vous pouvez fournir un AWS Secrets Manager ARN avec un fichier vide. Pour plus d'informations sur le stockage de votre certificat dans Secrets Manager, consultez [Stockez les certificats TLS dans AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Option de console : **Informations d'identification de liaison du serveur LDAP**
Un AWS Secrets Manager ARN qui contient les informations d'identification de liaison utilisateur de l'administrateur LDAP. Les informations d'identification sont stockées sous forme d'objet JSON. Il n'y a qu'une seule paire clé-valeur dans ce secret. La clé de la paire est le nom d'utilisateur et la valeur est le mot de passe. Par exemple, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Ce champ est facultatif, sauf si vous activez la connexion SSH pour votre cluster EMR. Dans de nombreuses configurations, les instances Active Directory nécessitent des informations d'identification de liaison pour permettre à SSSD de synchroniser les utilisateurs.
**`LDAPAccessFilter`**
Option de console : **Filtre d'accès LDAP**
Spécifie le sous-ensemble d'objets de votre serveur LDAP qui peuvent s'authentifier. Par exemple, si vous souhaitez uniquement accorder l'accès à tous les utilisateurs de la classe d'objet `posixAccount` de votre serveur LDAP, définissez le filtre d'accès comme `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Option de console : **Base de recherche d'utilisateurs LDAP**
La base de recherche à laquelle appartiennent vos utilisateurs au sein de votre serveur LDAP. Par exemple, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Option de console : **base de recherche de groupes LDAP**
La base de recherche à laquelle appartiennent vos groupes au sein de votre serveur LDAP. Par exemple, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Option de console : **Connexion SSH**
Spécifie s'il faut autoriser ou non l'authentification par mot de passe avec les informations d'identification LDAP. Nous vous déconseillons d'activer cette option. Les paires de clés constituent une voie plus sécurisée pour autoriser l'accès aux clusters EMR. Ce champ est facultatif et contient `false` par défaut.
**`LDAPServerType`**
Option de console : **Type de serveur LDAP**
Spécifie le type de serveur LDAP auquel Amazon EMR se connecte. Les options prises en charge sont Active Directory et OpenLDAP. D'autres types de serveurs LDAP peuvent fonctionner, mais Amazon EMR ne prend pas officiellement en charge les autres types de serveurs. Pour de plus amples informations, veuillez consulter [Composants LDAP pour Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Sous-bloc obligatoire pour les configurations de sécurité utilisant le type de serveur Active Directory.
**`ADDomain`**
Option de console : **Domaine Active Directory**
Le nom de domaine utilisé pour créer le nom d'utilisateur principal (UPN) pour l'authentification des utilisateurs avec des configurations de sécurité utilisant le type de serveur Active Directory.
## Considérations relatives aux configurations de sécurité avec LDAP et Amazon EMR
+ Pour créer une configuration de sécurité avec l'intégration d'Amazon EMR LDAP, vous devez utiliser le chiffrement en transit. Pour plus d'informations sur le chiffrement en transit, consultez [Chiffrez les données au repos et en transit avec Amazon EMR](emr-data-encryption.md).
+ Vous ne pouvez pas définir la configuration Kerberos dans la même configuration de sécurité. Amazon EMR fournit un KDC dédié au KDC automatiquement et gère le mot de passe administrateur de ce KDC. Les utilisateurs ne peuvent pas accéder à ce mot de passe administrateur.
+ Vous ne pouvez pas définir de rôles d'exécution IAM AWS Lake Formation dans la même configuration de sécurité.
+ Le `LDAPServerURL` doit avoir le protocole `ldaps://` dans sa valeur.
+ Le `LDAPAccessFilter` ne peut pas être vide.
## Utilisation de LDAP avec l'intégration Apache Ranger pour Amazon EMR
Grâce à l'intégration LDAP pour Amazon EMR, vous pouvez poursuivre l'intégration avec Apache Ranger. Lorsque vous insérez des utilisateurs .your LDAP dans Ranger, vous pouvez ensuite associer ces utilisateurs à un serveur de règles Apache Ranger pour les intégrer à Amazon EMR et à d'autres applications. Pour ce faire, définissez le champ `RangerConfiguration` dans `AuthorizationConfiguration` dans la configuration de sécurité que vous utilisez avec votre cluster LDAP. Pour plus d'informations sur la configuration de la sécurité, consultez [Création de la configuration de sécurité EMR](emr-ranger-security-config.md).
Lorsque vous utilisez LDAP avec Amazon EMR, il n'est pas nécessaire de fournir une `KerberosConfiguration` avec l'intégration Amazon EMR pour Apache Ranger.
# Lancement d'un cluster EMR qui s'authentifie auprès de LDAP
Procédez comme suit pour lancer un cluster EMR avec LDAP ou Active Directory.
1. Configuration de votre environnement :
+ Assurez-vous que les nœuds de votre cluster EMR peuvent communiquer avec Amazon S3 et. AWS Secrets Manager Pour plus d'informations sur la façon de modifier le rôle de votre profil d'instance EC2 afin de communiquer avec ces services, consultez [Ajouter AWS Secrets Manager des autorisations au rôle d'instance Amazon EMR](ldap-setup-asm.md).
+ Si vous envisagez d'exécuter votre cluster EMR dans un sous-réseau privé, vous devez utiliser des points de terminaison AWS PrivateLink Amazon VPC ou utiliser la traduction d'adresses réseau (NAT) pour configurer le VPC afin qu'il communique avec S3 et Secrets Manager. Pour plus d'informations, consultez la section [AWS PrivateLink et points de terminaison d'un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) [instances NAT](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) dans le *Guide de démarrage Amazon VPC*.
+ Assurez-vous qu'il existe une connectivité réseau entre votre cluster EMR et le serveur LDAP. Vos clusters EMR doivent accéder à votre serveur LDAP via le réseau. Les nœuds principal, de noyau et de tâche du cluster communiquent avec le serveur LDAP pour synchroniser les données utilisateur. Si votre serveur LDAP s'exécute sur Amazon EC2, mettez à jour le groupe de sécurité EC2 pour accepter le trafic provenant du cluster EMR. Pour de plus amples informations, veuillez consulter [Ajouter AWS Secrets Manager des autorisations au rôle d'instance Amazon EMR](ldap-setup-asm.md).
1. Créez une configuration de sécurité Amazon EMR pour l'intégration LDAP. Pour de plus amples informations, veuillez consulter [Création de la configuration de sécurité Amazon EMR pour l'intégration LDAP](ldap-setup-security.md).
1. Maintenant que vous êtes configuré, suivez les étapes décrites dans [Lancement d'un cluster Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) pour lancer votre cluster avec les configurations suivantes :
+ Sélectionnez Amazon EMR version 6.12 ou supérieure. Nous vous recommandons d'utiliser la dernière version Amazon EMR.
+ Spécifiez ou sélectionnez uniquement les applications compatibles LDAP pour votre cluster. Pour obtenir la liste des applications prises en charge par LDAP avec Amazon EMR, consultez [Prise en charge des applications et considérations relatives à LDAP pour Amazon EMR](ldap-considerations.md).
+ Appliquez la configuration de sécurité que vous avez créée à l'étape précédente.
# Exemples d'utilisation de LDAP avec Amazon EMR
Une fois que vous avez [configuré un cluster EMR utilisant l'intégration LDAP](ldap-setup-launch.md), vous pouvez fournir vos informations d'identification LDAP à n'importe quelle [application prise en charge](ldap-considerations.md#ldap-considerations-apps) par le biais de son mécanisme d'authentification par nom d'utilisateur et mot de passe intégré. Cette page présente quelques exemples.
## Utilisation de l'authentification LDAP avec Apache Hive
**Example - Apache Hive**
L'exemple de commande suivant démarre une session Apache Hive via HiveServer 2 et Beeline :
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Utilisation de l'authentification LDAP avec Apache Livy
**Example - Apache Livy**
L'exemple de commande suivant démarre une session Livy via cURL. Remplacez `ENCODED-KEYPAIR` par une chaîne codée en Base64 pour `username:password`.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Utilisation de l'authentification LDAP avec Presto
**Example - Presto**
L'exemple de commande suivant démarre une session Presto via la CLI Presto :
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Après avoir exécuté cette commande, saisissez le mot de passe LDAP à l'invite.
## Utilisation de l'authentification LDAP avec Trino
**Example - Turin**
L'exemple de commande suivant démarre une session Trino via la CLI Trino :
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Après avoir exécuté cette commande, saisissez le mot de passe LDAP à l'invite.
## Utilisation de l'authentification LDAP avec Hue
Vous pouvez accéder à l'interface utilisateur de Hue via un tunnel SSH que vous créez sur le cluster, ou vous pouvez configurer un serveur proxy pour diffuser publiquement la connexion à Hue. Étant donné que Hue ne fonctionne pas en mode HTTPS par défaut, nous vous recommandons d'utiliser une couche de chiffrement supplémentaire pour garantir que les communications entre les clients et l'interface utilisateur de Hue sont chiffrées avec HTTPS. Cela réduit le risque que vous exposiez accidentellement les informations d'identification de l'utilisateur en texte brut.
Pour utiliser l'interface utilisateur Hue, ouvrez l'interface utilisateur Hue dans votre navigateur et entrez votre mot de passe LDAP pour vous connecter. Si les informations d'identification sont correctes, Hue vous connecte et utilise votre identité pour vous authentifier auprès de toutes les applications prises en charge.
## Utilisation de SSH pour l'authentification par mot de passe et de tickets Kerberos pour d'autres applications
**Important**
Nous vous déconseillons d'utiliser l'authentification par mot de passe pour vous connecter à un cluster EMR.
Vous pouvez utiliser vos informations d'identification LDAP pour vous connecter en SSH à un cluster EMR. Pour ce faire, définissez la configuration `EnableSSHLogin` comme `true` dans la configuration de sécurité Amazon EMR que vous utilisez pour démarrer le cluster. Ensuite, utilisez la commande suivante pour vous connecter au cluster une fois qu'il a été lancé :
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Après avoir exécuté cette commande, saisissez le mot de passe LDAP à l'invite.
Amazon EMR inclut un script intégré au cluster qui permet aux utilisateurs de générer un fichier keytab Kerberos et un ticket à utiliser avec les applications prises en charge qui n'acceptent pas directement les informations d'identification LDAP. Certaines de ces applications incluent `spark-submit` Spark SQL et PySpark.
Exécutez `ldap-kinit` et suivez les instructions. Si l'authentification réussit, le fichier keytab Kerberos apparaît dans votre répertoire personnel avec un ticket Kerberos valide. Utilisez le ticket Kerberos pour exécuter des applications comme vous le feriez dans n'importe quel environnement activé pour Kerberos.