Options d'architecture Kerberos

Lorsque vous utilisez Kerberos avec AmazonEMR, 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 les options Kerberos compatibles spécifiques au cluster lorsque vous créez le cluster, et vous créez des HDFS répertoires pour les utilisateurs Linux du cluster qui correspondent aux principaux utilisateurs du. 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.

Dédié au cluster KDC (KDCsur le nœud principal)

Cette configuration est disponible avec les EMR versions 5.10.0 et supérieures d'Amazon.

Avantages

• Amazon EMR est propriétaire à part entière duKDC.

• KDCLe EMR cluster est indépendant des KDC implémentations centralisées telles que Microsoft Active Directory ou AWS Managed Microsoft AD.

• L'impact sur les performances est minime car il KDC gère l'authentification uniquement pour les nœuds locaux du cluster.

• Facultativement, d'autres clusters Kerberisés peuvent le référencer KDC en tant que cluster externe. KDC Pour de plus amples informations, veuillez consulter KDCExterne : nœud principal 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 les applications de cluster doivent interagir, vous devez établir une confiance entre domaines entre les clusters ou configurer un cluster comme externe KDC pour les 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'EC2instance du nœud principal correspondant aux KDC utilisateurs principaux, ainsi que les HDFS répertoires de chaque utilisateur.

• Les utilisateurs principaux doivent utiliser un fichier de clé EC2 privée et des kinit informations d'identification pour se connecter au cluster à l'aide SSH de.

Relation d'approbation inter-domaines

Dans cette configuration, les principaux (généralement les utilisateurs) d'un autre domaine Kerberos s'authentifient auprès des composants de l'application sur un EMR cluster Kerberisé, qui possède le sien. KDC Le KDC nœud principal établit une relation de confiance avec un autre nœud KDC en utilisant un principe inter-domaines qui existe dans les deuxKDCs. Le nom principal et le mot de passe correspondent exactement dans chacun d'euxKDC. Les relations d'approbation inter-domaines sont plus communes avec les implémentations Active Directory, comme illustré dans le schéma suivant. Les approbations entre domaines avec un cluster Amazon externe MIT KDC ou KDC sur un autre EMR cluster Amazon sont également prises en charge.

Avantages

• Le EMR cluster sur lequel le KDC est installé conserve la pleine propriété duKDC.

• Avec Active Directory, Amazon crée EMR automatiquement des utilisateurs Linux qui correspondent aux principaux utilisateurs duKDC. Vous devez toujours créer des HDFS annuaires pour chaque utilisateur. En outre, les utilisateurs principaux du domaine Active Directory peuvent accéder aux clusters Kerberisés à l'aide kinit d'informations d'identification, sans le fichier de clé EC2 privée. Cela élimine la nécessité de partager le fichier de clé privée entre les utilisateurs de cluster.

• Comme chaque cluster KDC gère l'authentification des nœuds du cluster, les effets de la latence du réseau et de la surcharge de traitement pour un grand nombre de nœuds dans les clusters sont minimisés.

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 le cluster A et le cluster B établissent tous deux une confiance entre domaines avec aKDC, ils ne se font pas intrinsèquement confiance et leurs applications ne peuvent pas s'authentifier l'une auprès de l'autre pour interagir.

• KDCsdoivent être gérés de manière indépendante et coordonnée afin que les informations d'identification des principaux utilisateurs correspondent exactement.

Externe KDC

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

• Externe KDC — MIT KDC

• KDCExterne : nœud principal sur un autre cluster

• KDCExterne : cluster KDC sur un autre cluster avec approbation inter-domaines Active Directory

Externe KDC — MIT KDC

Cette configuration permet à un ou plusieurs EMR clusters d'utiliser des principes définis et gérés sur un MIT KDC serveur.

Avantages

• Les principes de gestion sont regroupés en un seul KDC document.

• Plusieurs clusters peuvent utiliser la même chose KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter Exigences relatives à l'utilisation de plusieurs clusters avec le même KDC.

• Le nœud principal d'un cluster Kerberisé n'est pas soumis à la charge de performance associée à la maintenance du. KDC

Considérations et restrictions

• Vous devez créer des utilisateurs Linux sur l'EC2instance du nœud principal de chaque cluster Kerberisé qui correspondent aux principaux KDC utilisateurs, ainsi que les HDFS répertoires de chaque utilisateur.

• Les utilisateurs principaux doivent utiliser un fichier de clé EC2 privée et des kinit informations d'identification pour se connecter aux clusters Kerberisés à l'aide de. SSH

• Chaque nœud des EMR clusters Kerberisés doit disposer d'une route réseau vers le. KDC

• Chaque nœud des clusters Kerberisés impose une charge d'authentification à l'extérieurKDC, de sorte que la configuration du nœud KDC affecte les performances du cluster. Lorsque vous configurez le matériel du KDC serveur, considérez le nombre maximum de EMR nœuds Amazon à prendre en charge simultanément.

• Les performances du cluster dépendent de la latence du réseau entre les nœuds des clusters Kerberisés et le. KDC

• La résolution de problèmes peut être plus difficile en raison d'interdépendances.

KDCExterne : nœud principal sur un autre cluster

Cette configuration est presque identique à l'MITKDCimplémentation externe ci-dessus, sauf qu'elle KDC se trouve sur le nœud principal d'un EMR cluster. Pour plus d’informations, consultez Dédié au cluster KDC (KDCsur le nœud principal) et Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory.

Avantages

• Les principes de gestion sont regroupés en un seul KDC document.

• Plusieurs clusters peuvent utiliser la même chose KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter Exigences relatives à l'utilisation de plusieurs clusters avec le même KDC.

Considérations et restrictions

• Vous devez créer des utilisateurs Linux sur l'EC2instance du nœud principal de chaque cluster Kerberisé qui correspondent aux principaux KDC utilisateurs, ainsi que les HDFS répertoires de chaque utilisateur.

• Les utilisateurs principaux doivent utiliser un fichier de clé EC2 privée et des kinit informations d'identification pour se connecter aux clusters Kerberisés à l'aide de. SSH

• Chaque nœud de chaque EMR cluster doit disposer d'une route réseau vers leKDC.

• Chaque EMR nœud Amazon des clusters Kerberisés impose une charge d'authentification à l'extérieurKDC, de sorte que la configuration du nœud KDC affecte les performances du cluster. Lorsque vous configurez le matériel du KDC serveur, considérez le nombre maximum de EMR nœuds Amazon à prendre en charge simultanément.

• Les performances du cluster dépendent de la latence du réseau entre les nœuds des clusters et leKDC.

• La résolution de problèmes peut être plus difficile en raison d'interdépendances.

KDCExterne : cluster KDC sur un autre cluster avec approbation inter-domaines Active Directory

Dans cette configuration, vous devez d'abord créer un cluster avec un cluster dédié KDC doté d'une confiance interdomaines unidirectionnelle avec Active Directory. Pour voir un didacticiel détaillé, consultez Didacticiel : configuration d'une approbation inter-domaines avec un domaine Active Directory. Vous lancez ensuite des clusters supplémentaires, en référençant le cluster KDC auquel vous faites confiance en tant qu'entité externeKDC. Pour obtenir un exemple, consultez Cluster externe KDC avec confiance inter-domaines Active Directory. Cela permet à chaque EMR cluster Amazon qui utilise l'externe KDC d'authentifier les principaux définis et gérés dans un domaine Microsoft Active Directory.

Avantages

• La gestion des mandataires est regroupée dans le domaine Active Directory.

• Amazon EMR rejoint le domaine Active Directory, ce qui élimine le besoin de créer des utilisateurs Linux correspondant aux utilisateurs Active Directory. Vous devez toujours créer des HDFS annuaires pour chaque utilisateur.

• Plusieurs clusters peuvent utiliser la même chose KDC dans le même domaine Kerberos. Pour de plus amples informations, veuillez consulter Exigences relatives à l'utilisation de plusieurs clusters avec le même KDC.

• Les utilisateurs principaux du domaine Active Directory peuvent accéder aux clusters Kerberisés à l'aide kinit d'informations d'identification, sans le fichier de clé EC2 privée. Cela élimine la nécessité de partager le fichier de clé privée entre les utilisateurs de cluster.

• Seul un nœud EMR principal Amazon est chargé de la maintenanceKDC, et seul ce cluster doit être créé avec des informations d'identification Active Directory pour garantir la confiance entre domaines entre Active Directory KDC et Active Directory.

Considérations et restrictions

• Chaque nœud de chaque EMR cluster doit disposer d'une route réseau vers le contrôleur de domaine Active Directory KDC et le contrôleur de domaine Active Directory.

• Chaque EMR nœud Amazon impose une charge d'authentification à l'externeKDC, de sorte que la configuration du nœud KDC affecte les performances du cluster. Lorsque vous configurez le matériel du KDC serveur, considérez le nombre maximum de EMR nœuds Amazon à prendre en charge simultanément.

• Les performances des clusters dépendent de la latence du réseau entre les nœuds des clusters et le KDC serveur.

• La résolution de problèmes peut être plus difficile en raison d'interdépendances.

Exigences relatives à l'utilisation de plusieurs clusters avec le même KDC

Plusieurs clusters peuvent utiliser la même chose 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 environnement externeKDC, assurez-vous qu'ils utilisent des domaines Kerberos différents. Si les clusters doivent utiliser le même domaine Kerberos, assurez-vous qu'ils se trouvent dans des sous-réseaux différents et que leurs CIDR plages ne se chevauchent pas.