Options d'architecture Kerberos - Amazon EMR

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.

Options d'architecture Kerberos

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.

KDC dédié du cluster (KDC sur le nœud principal)

Cette configuration est disponible dans les versions d'Amazon EMR 5.10.0 et ultérieures.

Avantages

  • Amazon EMR est propriétaire 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 plus d'informations, consultez KDC externe : nœud maître sur un autre cluster.

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 approbation inter-domaines est établie, les KDC doivent disposer de différents domaines Kerberos.

  • Vous devez créer des utilisateurs Linux sur l'instance EC2 du nœud principal 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 ation d'approbation

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 sur le nœud principal établit une relation d'approbation avec un autre KDC à l'aide d'un mandataire inter-domaines qui existe dans les deux KDC. Le nom et le mot de passe du mandataire 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.

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 mandataires d'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é.

  • Les KDC doivent être conservés de manière indépendante et coordonnée afin que les informations d'identification des mandataires d'utilisateur correspondent précisément.

KDC externe

Les configurations avec un KDC externe sont prises en charge avec Amazon EMR 5.20.0 et versions ultérieures.

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.

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. Cela permet aux applications de cluster d'interagir et simplifie l'authentification de la communication entre les clusters par rapport à une relation d'approbation inter-domaines.

  • Le nœud principal 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 principal 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 maître sur un autre cluster

Cette configuration est presque identique à l'implémentation KDC MIT externe ci-dessus, sauf que le KDC est sur le nœud principal d'un cluster EMR. Pour plus d’informations, consultez KDC dédié du cluster (KDC sur le nœud principal) et Didacticiel : Configurer une approbation inter-domaines avec un domaine Active Directory.

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. Cela permet aux applications d'un cluster et aux clusters activés pour Kerberos d'interagir. Cela simplifie également l'authentification de la communication entre clusters par rapport à une approbation inter-domaines.

Considérations et restrictions

  • Vous devez créer des utilisateurs Linux sur l'instance EC2 du nœud principal 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 : clusterez le KDC sur un autre cluster avec la confiance 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 : Configurer une approbation inter-domaines avec un domaine Active Directory. Vous pouvez ensuite lancer d'autres clusters faisant référence au cluster KDC qui a la confiance comme KDC externe. Pour voir un exemple, consultez KDC de cluster externe avec approbation inter-domaines Active Directory. Ceci permet à chaque cluster Amazon EMR qui utilise le KDC externe d'authentifier les mandataires définis et maintenus dans un domaine Microsoft Active Directory.

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, qui est différent du domaine Active Directory. Cela permet aux applications de cluster d'interagir.

  • 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 maître 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.