Simplifiez l'authentification avec l'intégration LDAP native sur Amazon EMR | Amazon Web Services

De nombreuses entreprises ont des identités d'entreprise stockées chez des fournisseurs d'identité (IdP) comme active Directory (AD) ou OpenLDAP. Auparavant, les clients utilisant Amazon DME pourraient intégrer leurs clusters à Active Directory en configurant une approbation de domaine unidirectionnelle entre leur domaine AD et le domaine Kerberos du cluster EMR. Pour plus de détails, reportez-vous à Tutoriel : Configurer une approbation entre domaines avec un domaine Active Directory.

Cette configuration a été un outil clé pour rendre les utilisateurs et les groupes d'entreprise disponibles au sein des clusters EMR et définir des politiques de contrôle d'accès pour contrôler leur accès aux données (par exemple, via le Intégration Apache Ranger native d'Amazon EMR).

Bien que cette option soit toujours disponible, Amazon EMR a publié prise en charge de l'authentification LDAP native, une nouvelle fonctionnalité de sécurité qui simplifie l'intégration avec OpenLDAP et Active Directory.

Cette fonctionnalité permet les éléments suivants :

configuration automatique de la sécurité pour les applications prises en charge (HiveServer2, Trino, Presto et Livy) pour utiliser le protocole Kerberos sous le capot et LDAP comme authentification externe. Cela permet une intégration plus simple à partir d'outils externes qui, pour se connecter aux points de terminaison du cluster, n'ont plus besoin de configurer l'authentification Kerberos mais peuvent simplement être configurés pour fournir un nom d'utilisateur et un mot de passe LDAP.
contrôle d'accès précis (FGAC) pour déterminer qui peut accéder à vos clusters EMR via SSH
des politiques d'autorisation précises au-dessus de la base de données et des tables Hive Metastore si elles sont utilisées en combinaison avec l'intégration native d'Amazon EMR Apache Ranger.

Dans cet article, nous approfondissons l'authentification LDAP Amazon EMR, montrant comment fonctionne le flux d'authentification, comment récupérer et tester les configurations LDAP nécessaires et comment confirmer qu'un cluster EMR est correctement intégré à LDAP.

Utilisation des informations sur ce blog :

Les équipes gérant des clusters EMR peuvent améliorer la coordination avec leurs administrateurs IdP LDAP afin de demander les informations appropriées et d'effectuer correctement les tests de pré-configuration.
Les utilisateurs finaux des clusters EMR peuvent comprendre à quel point il est simple de se connecter à partir d'outils externes aux clusters EMR compatibles LDAP par rapport à l'authentification précédente basée sur Kerberos.

Fonctionnement de l'intégration Amazon EMR LDAP

Lorsqu’on parle d’authentification dans le contexte des frameworks EMR, on peut distinguer deux niveaux :

Authentification externe – Utilisé par les utilisateurs et les composants externes pour interagir avec les frameworks installés
Authentification interne – Utilisé dans les frameworks pour authentifier les communications des composants internes

Avec cette nouvelle fonctionnalité, l'authentification du cadre interne est toujours gérée via Kerberos, mais cela est transparent pour les utilisateurs finaux ou les services externes qui, de l'autre côté, utilisent un nom d'utilisateur et un mot de passe pour s'authentifier.

Les frameworks installés EMR pris en charge implémentent une méthode d'authentification basée sur LDAP qui, étant donné un ensemble d'informations d'identification de nom d'utilisateur et de mot de passe, les valide par rapport au point de terminaison LDAP et, en cas de succès, permet l'utilisation du framework.

Le diagramme suivant résume le fonctionnement du flux d'authentification.

Le workflow comprend les étapes suivantes:

Un utilisateur se connecte à l'un des points de terminaison pris en charge (tels que HiveServer2, Trino/Presto coordinateur ou Hue WebUI) et fournit ses informations d'identification d'entreprise (nom d'utilisateur et mot de passe).
Le framework contacté utilise un authentificateur personnalisé qui effectue l'authentification à l'aide du service EMR Secret Agent exécuté dans les instances de cluster.
Le service EMR Secret Agent valide les informations d'identification fournies par rapport au point de terminaison LDAP.
En cas de succès, les événements suivants se produisent :
- Un principal Kerberos est créé pour l'utilisateur spécifique sur le centre de distribution de clés MIT du cluster (MIT KDC) exécuté à l'intérieur du nœud principal.
- Le keytab principal Kerberos est créé dans le répertoire personnel de l'utilisateur sur le nœud principal.

Une fois l'authentification terminée, l'utilisateur peut commencer à utiliser le framework.

Dans toutes les instances de cluster, le service SSSD est configuré pour récupérer les utilisateurs et les groupes du point de terminaison LDAP et les rendre disponibles en tant qu'utilisateurs système.

Le flux d'authentification lors de la connexion avec SSH est un peu différent et est résumé dans le diagramme suivant.

Le workflow comprend les étapes suivantes:

Un utilisateur se connecte via SSH à l'instance principale EMR, en fournissant les informations d'identification de l'entreprise (nom d'utilisateur et mot de passe).
Le service SSHD contacté utilise le service SSSD pour valider les informations d'identification fournies.
Le service SSSD valide les informations d'identification fournies par rapport au point de terminaison LDAP. En cas de succès, l'utilisateur atterrit sur le répertoire personnel associé. A ce stade, l'utilisateur peut utiliser les différentes CLI (beeline, trino-cli, presto-cli, curl) pour accéder à Hive, Trino/Presto ou Livy.
Pour utiliser les CLI Spark (spark-submit, pyspark, spark-shell), l'utilisateur doit appeler le ldap-kinit script et fournissez le nom d’utilisateur et le mot de passe demandés.
L'authentification est effectuée à l'aide du service EMR Secret Agent exécuté dans les instances de cluster.
Le service EMR Secret Agent valide les informations d'identification fournies par rapport au point de terminaison LDAP.
En cas de succès, les événements suivants se produisent :
- Un principal Kerberos est créé pour l'utilisateur spécifique sur le cluster MIT KDC exécuté à l'intérieur du nœud principal.
- Le keytab principal Kerberos est créé dans le répertoire personnel de l'utilisateur sur le nœud principal.
- Un ticket Kerberos est obtenu et stocké dans le cache de tickets Kerberos de l'utilisateur sur le nœud principal.

Après le ldap-kinit Le script est terminé, l'utilisateur peut commencer à utiliser les CLI Spark.

Dans les sections suivantes, nous montrons comment récupérer les valeurs de paramètre LDAP requises et étudions comment lancer un cluster avec l'authentification EMR LDAP et le tester.

Trouver les paramètres LDAP appropriés

Pour configurer l'authentification LDAP pour Amazon EMR, la première étape consiste à récupérer les propriétés LDAP à utiliser pour configurer votre cluster. Vous avez besoin des informations suivantes :

Le nom DNS du serveur LDAP
Un certificat au format PEM à utiliser pour interagir via Secure LDAP (LDAPS) avec le point de terminaison LDAP
La base de recherche d'utilisateurs LDAP, qui est un chemin (ou branche) de l'arborescence LDAP à partir duquel rechercher les utilisateurs (seuls les utilisateurs appartenant à cette branche seront récupérés)
La base de recherche de groupes LDAP, qui est un chemin (ou branche) de l'arborescence LDAP à partir duquel rechercher des groupes (seuls les groupes appartenant à cette branche seront récupérés)
Les informations d'identification de l'utilisateur de liaison du serveur LDAP, qui sont le nom d'utilisateur et le mot de passe d'un utilisateur de service (généralement appelé utilisateur de liaison) à utiliser pour déclencher des requêtes LDAP et récupérer des informations utilisateur telles que le nom d'utilisateur et l'appartenance à un groupe.

Avec Active Directory, un administrateur AD peut récupérer ces informations directement depuis le Active Directory Users and Computers outil. Lorsque vous choisissez un utilisateur dans cet outil, vous pouvez voir les attributs associés (par exemple, distinguishedName). La capture d'écran suivante montre un exemple.

Sur la capture d'écran, nous pouvons voir que le distinguishedName pour l'utilisateur John est CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, ce qui signifie que john appartient aux bases de recherche suivantes, classées de la plus étroite à la plus large :

OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
OU=italy,OU=emr,DC=awsemr,DC=com
OU=emr,DC=awsemr,DC=com
DC=awsemr,DC=com

En fonction du nombre d'entrées contenues dans l'annuaire LDAP d'une entreprise, l'utilisation d'une large base de recherche peut entraîner des délais de récupération et des délais d'attente longs. C'est une bonne pratique de configurer la base de recherche pour qu'elle soit aussi étroite que possible afin d'inclure tous les utilisateurs nécessaires. Dans l'exemple précédent, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com peut constituer une bonne base de recherche si tous les utilisateurs auxquels vous souhaitez donner accès au cluster EMR font partie de cette unité organisationnelle.

Une autre façon de récupérer les attributs utilisateur consiste à utiliser le ldapsearch outil. Vous pouvez utiliser cette méthode pour Active Directory ainsi que pour OpenLDAP, et elle est extrêmement utile pour tester la connectivité avec le point de terminaison LDAP.

Ce qui suit est un exemple avec Active Directory (OpenLDAP est similaire).

Le point de terminaison LDAP doit être résoluble et accessible par Cloud de calcul élastique Amazon (Amazon EC2) Instances de cluster EMR via TCP sur le port 636. Il est suggéré d'exécuter le test à partir d'une instance Amazon Linux 2 EC2 appartenant au même sous-réseau que le cluster EMR et ayant le même groupe de sécurité EMR associé aux instances de cluster EMR.

Après avoir lancé une instance EC2, installez le nc et testez la résolution DNS et la connectivité. En admettant que DC1.awsemr.com est le nom DNS du point de terminaison LDAP, exécutez les commandes suivantes :

sudo yum install nc
nc -vz DC1.awsemr.com 636

Si la résolution DNS ne fonctionne pas correctement, vous devriez recevoir une erreur semblable à la suivante :

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Could not resolve hostname "DC1.awsemr.com": Name or service not known. QUITTING.

Si le point de terminaison n'est pas accessible, vous devriez recevoir une erreur semblable à la suivante :

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

Dans l’un ou l’autre de ces cas, l’équipe réseau et DNS doit être impliquée afin de dépanner et de résoudre les problèmes.

En cas de succès, le résultat devrait ressembler à ce qui suit :

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.1.235:636.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Si tout fonctionne, procédez aux tests et installez le openldap clients comme suit :

sudo yum install openldap-clients

Ensuite, courez ldapsearch commandes pour récupérer des informations sur les utilisateurs et les groupes à partir du point de terminaison LDAP. Ce qui suit sont des exemples ldapsearch commandes:

#Customize these 6 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_TO_SEARCH=john
FILTER=(sAMAccountName=${USER_TO_SEARCH})
INFO_TO_SEARCH="*"

#Search user
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${SEARCH_BASE}" "${FILTER}" "${INFO_TO_SEARCH}"

Nous utilisons les paramètres suivants :

-x – Cela permet une authentification simple.
-D – Ceci indique à l’utilisateur d’effectuer la recherche.
-w – Ceci indique le mot de passe de l'utilisateur.
-H – Ceci indique l'URL du serveur LDAP.
-b – C'est la recherche de base.
LDAPTLS_CACERT – Ceci indique le certificat public SSL PEM du point de terminaison LDAPS ou le certificat public SSL PEM de l'autorité de certification racine du point de terminaison LDAPS. Ceci peut être obtenu auprès d’un utilisateur administrateur AD ou OpenLDAP.

Voici un exemple de résultat de la commande précédente :

filter: (sAMAccountName=john)
requesting: *
dn: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: john
givenName: john
distinguishedName: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
instanceType: 4
whenCreated: 20230804094021.0Z
whenChanged: 20230804094021.0Z
displayName: john
uSNCreated: 262459
memberOf: CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
uSNChanged: 262466
name: john
objectGUID:: gTxn8qYvy0SVL+mYAAbb8Q==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 133356156212864439
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAIKyNe7Dn3azp7Sh+rgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: john
sAMAccountType: 805306368
userPrincipalName: john@awsemr.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=awsemr,DC=com
dSCorePropagationData: 20230804094021.0Z
dSCorePropagationData: 16010101000000.0Z

Comme nous pouvons le voir sur l'exemple de sortie, l'utilisateur Jean est identifié par le nom distinctif CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, et le data-engineers groupe auquel appartient l'utilisateur (memberOf valeur) est identifié par le nom distinctif CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Nous pouvons exécuter notre ldapsearch requêtes pour récupérer les informations sur l'utilisateur et le groupe à l'aide d'une base de recherche restreinte :

#Customize these 9 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_SEARCH_BASE=OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
GROUPS_SEARCH_BASE=OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
USER_TO_SEARCH=john
GROUP_TO_SEARCH=data-engineers

#Search User
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${USER_SEARCH_BASE}" "(sAMAccountName=${USER_TO_SEARCH})" "*"

#Search Group
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${GROUPS_SEARCH_BASE}" "(sAMAccountName=${GROUP_TO_SEARCH})" "*"

Vous pouvez également appliquer d'autres filtres lors de la recherche. Pour plus d'informations sur la création de filtres LDAP, reportez-vous à Filtres LDAP.

En exécutant ldapsearch commandes, vous pouvez tester la connectivité LDAP et les propriétés LDAP, et déterminer la configuration nécessaire.

Testez la solution

Après avoir vérifié que la connectivité au point de terminaison LDAP est ouverte et que les configurations LDAP sont correctes, procédez à la configuration de l'environnement pour lancer un cluster compatible EMR LDAP.

Créer des secrets AWS Secret Manager

Avant de créer la configuration de sécurité EMR, vous devez créer deux Gestionnaire de secrets AWS secrets. Vous utilisez ces informations d'identification pour interagir avec le point de terminaison LDAP et récupérer les détails de l'utilisateur tels que le nom d'utilisateur et l'appartenance à un groupe.

Sur la console Secrets Manager, choisissez Secrets dans le volet de navigation.
Selectionnez Stocker un nouveau secret.
Pour Type secret, sélectionnez Autre type de secret.
Créez un nouveau secret spécifiant le binduser nom distinctif comme clé et le binduser mot de passe comme valeur.
Créez un deuxième secret spécifiant en clair le certificat public SSL du point de terminaison LDAPS ou le certificat public de l'autorité de certification racine LDAPS.
Ce certificat est fiable, permettant une communication sécurisée entre le cluster EMR et le point de terminaison LDAPS.

Créer la configuration de sécurité EMR

Effectuez les étapes suivantes pour créer la configuration de sécurité EMR :

Sur la console Amazon EMR, choisissez Configurations de sécurité sous DME sur EC2 dans le volet de navigation.
Selectionnez Création.
Pour Nom de la configuration de sécurité, entrez un nom.
Pour Options de configuration de la configuration de la sécurité, sélectionnez Choisissez les paramètres personnalisés.
Pour Chiffrement, sélectionnez Activer le chiffrement en transit.
Pour Type de fournisseur de certificatsélectionner PEM.
Pour Choisissez l'emplacement du certificat PEM, saisissez soit un bundle PEM situé dans Service de stockage simple Amazon (Amazon S3) ou un fournisseur de certificat personnalisé Java.
Notez que le cryptage en transit est obligatoire pour pouvoir utiliser la fonctionnalité d'authentification LDAP. Pour plus d'informations sur le chiffrement en transit, reportez-vous à Fournir des certificats pour chiffrer les données en transit avec le chiffrement Amazon EMR.
Selectionnez Suivant.
Sélectionnez LDAP en Protocole d'authentification.
Pour Emplacement du serveur LDAP, saisissez le point de terminaison LDAPS (ldaps://<ldap_endpoint_DNS_name>).
Pour Certificat SSL LDAP, saisissez le deuxième secret que vous avez créé dans Secrets Manager.
Pour Filtre d'accès LDAP, saisissez un filtre LDAP appliqué afin de restreindre l'accès à un sous-ensemble d'utilisateurs extrait de la base de recherche d'utilisateurs LDAP. Si le champ est laissé vide, aucun filtre n'est appliqué et tous les utilisateurs appartenant à la base de recherche d'utilisateurs LDAP peuvent accéder aux points de terminaison EMR protégés par LDAP avec leurs informations d'identification d'entreprise. Voici des exemples de filtres et leurs fonctions :
- (objectClass=personne) – Filtrer les utilisateurs avec l'attribut objectClass définir comme person
- (memberOf=CN=admins,OU=groups,OU=italie,OU=emr,DC=awsemr,DC=com) – Filtrer les utilisateurs appartenant au admins groupe
- (|(memberof=CN=data-engineers,OU=groups,OU=italie,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italie,OU=emr, DC=awsemr,DC=com)) – Filtrer les utilisateurs appartenant soit au data-engineers au sein de l’ admins groupe (que nous utilisons pour cet article)
Entrez des valeurs pour Base de recherche d'utilisateurs LDAP ainsi que Base de recherche de groupe LDAP. Notez que les deux bases de recherche ne prennent pas en charge les filtres en ligne (par exemple, les éléments suivants ne sont pas pris en charge : OU=users,OU=italy,OU=emr,DC=awsemr,DC=com?subtree?(|(memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com))).
Sélectionnez Activer la connexion SSH. Cela n'est nécessaire que si vous souhaitez que vos utilisateurs LDAP puissent se connecter en SSH à l'intérieur des instances de cluster avec leurs informations d'identification d'entreprise. Si la connexion SSH est activée, le filtre d'accès LDAP est nécessaire, sinon l'authentification SSH échouera.
Pour Informations d'identification de liaison du serveur LDAP, saisissez le premier secret que vous avez créé dans Secrets Manager.
Dans le Autorisation section, conservez les valeurs par défaut sélectionnées :
- Pour Rôle IAM pour les applications, sélectionnez Profil d'instance.
- Pour Méthode de contrôle d'accès à granularité fine, sélectionnez Aucun.
Selectionnez Suivant.
Consultez le résumé de la configuration et choisissez Création.

Lancer le cluster EMR

Vous pouvez lancer le cluster EMR à l'aide du Console de gestion AWS, Interface de ligne de commande AWS (AWS CLI), ou tout autre SDK AWS.

Lorsque vous créez le cluster EMR sur EC2, veillez à spécifier les configurations suivantes :

Version DME – Utilisez Amazon EMR 6.12.0 ou supérieur.
Applications – Sélectionnez Hadoop, Spark, Hive, Hue, Livy et Presto/Trino.
Configuration de sécurité – Spécifiez la configuration de sécurité que vous avez créée à l'étape précédente.
paire de clés EC2 – Utilisez une paire de clés existante.
Groupes de réseau et de sécurité – Utilisez une configuration qui permet aux instances EMR EC2 d'interagir avec le point de terminaison LDAPS. Dans le Trouver les paramètres LDAP appropriés section, vous devriez avoir confirmé une configuration valide.

Confirmez que l'authentification LDAP fonctionne

Lorsque le cluster est opérationnel, vous pouvez vérifier que l'authentification LDAP fonctionne correctement.

If Connexion SSH a été activé dans le cadre de Authentification LDAP à l'intérieur de l' Configuration de la sécurité DME, vous pouvez vous connecter via SSH à votre cluster en spécifiant un utilisateur LDAP, en demandant le mot de passe associé lorsque cela vous est demandé :

ssh myldapuser@<emr_primary_node>

Si la connexion SSH a été désactivée, vous pouvez vous connecter via SSH à l'intérieur du cluster en utilisant la paire de clés EC2 spécifiée lors de la création du cluster :

ssh -i mykeypair.pem ec2-user@<emr_primary_node>

Une autre façon d'accéder à l'instance principale, si vous préférez, consiste à utiliser Session Manager, une capacité de Gestionnaire de systèmes AWS. Pour plus d'informations, reportez-vous à Connectez-vous à votre instance Linux avec AWS Systems Manager Session Manager.

Lorsque vous êtes dans l'instance principale, vous pouvez tester que les utilisateurs et groupes LDAP sont correctement récupérés à l'aide de l'option id commande. Ce qui suit est un exemple de commande pour vérifier si l'utilisateur john est correctement récupéré avec les groupes associés :

[ec2-user@ip-10-0-2-237 ~]# id john
uid=941601122(john) gid=941600513(users-group) groups=941600513(users-group),941601123(data-engineers)

Vous pourrez ensuite tester l’authentification sur les différents frameworks installés.

Tout d’abord, récupérons le certificat public des frameworks et stockons-le dans un truststore. Tous les frameworks partagent le même certificat public (celui que nous avons utilisé pour configurer le cryptage en transit), vous pouvez donc utiliser n'importe lequel des points de terminaison protégés par SSL (port Hive 10000, port Presto/Trino 8446, port Livy 8998) pour le récupérer. . Récupérez le certificat du point de terminaison HiveServer2 (port 10000) :

#Export Hive Server 2 public SSL certificate to a PEM file
openssl s_client -showcerts -connect $(hostname -f):10000 </dev/null 2>/dev/null|openssl x509 -outform PEM > certificate.pem

#Import the PEM certificate inside a truststore
echo "yes" | keytool -import -alias hive_cert -file certificate.pem -storetype JKS -keystore truststore.jks -storepass myStrongPassword

Utilisez ensuite ce truststore pour communiquer en toute sécurité avec les différents frameworks.

Utilisez le code suivant pour tester l'authentification HiveServer2 avec beeline:

#Use the truststore to connect to the Hive Server 2
beeline -u "jdbc:hive2://$(hostname -f):10000/default;ssl=true;sslTrustStore=truststore.jks;trustStorePassword=myStrongPassword" -n john -p johnPassword

Si vous utilisez Presto, testez l'authentification Presto avec le presto CLI (fournir le mot de passe utilisateur lorsque demandé) :

#Use the truststore to connect to the Presto coordinator
presto-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Si vous utilisez Trino, testez l'authentification Trino avec le trino CLI (fournir le mot de passe utilisateur lorsque demandé) :

#Use the truststore to connect to the Trino coordinator
trino-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Teste Livy authentification avec curl :

#Trust the PEM certificte to connect to the Livy server

#Start session
curl --cacert certificate.pem -X POST 
-u "john:johnPassword" 
--data '{"kind": "spark"}' 
-H "Content-Type: application/json" 
https://$(hostname -f):8998/sessions 
-c cookies.txt

#Example of output
#{"id":0,"name":null,"appId":null,"owner":"john","proxyUser":"john","state":"starting","kind":"spark","appInfo":{"driverLogUrl":null,"sparkUiUrl":null},"log":["stdout: ","nstderr: ","nYARN Diagnostics: "]}

Testez les commandes Spark avec pyspark:

#SSH inside the primary instance with the specific user
ssh john@<emr-primary-node>
#Or impersonate the user
sudo su - john

#Create a keytab and obtain a kerberos ticket running the ldap-kinit tool
$ ldap-kinit
Username: john
Password: 

#Output
{"message":"ok","contents":{"username":"john","expirationTime":"2023-09-14T15:24:06.303Z[UTC]"}}

#Check the kerberos ticket has been created
$ klist

# Test spark CLIs
$ pyspark

>>> spark.sql("show databases").show()
>>> quit()

Notez qu'ici nous avons testé l'authentification depuis l'intérieur du cluster, mais nous pouvons interagir avec Trino, Hive, Presto et Livy même depuis l'extérieur du cluster dans la mesure où la connectivité et la résolution DNS sont correctement configurées. Les CLI Spark sont les seules qui peuvent être utilisées uniquement depuis l’intérieur du cluster.

Pour tester l'authentification Hue, procédez comme suit :

Accédez à l'interface utilisateur Web Hue hébergée sur http://<emr_primary_node>:8888/ et fournissez un nom d'utilisateur et un mot de passe LDAP.
Testez les requêtes SQL dans les éditeurs Hive et Trino/Presto.

Pour tester avec un outil SQL externe (tel que DBeaver connexion à Trino), procédez comme suit. Assurez-vous de configurer le groupe de sécurité du nœud principal EMR afin qu'il autorise le trafic TCP de l'adresse IP DBeaver vers le port du point de terminaison du framework souhaité (par exemple, 10000 pour HiveServer2, 8446 pour Trino/Presto) et de configurer correctement la résolution DNS sur le client DBeaver. ordinateur pour résoudre correctement le nom d'hôte du nœud principal EMR.

Depuis l'instance principale de votre cluster EMR, copiez dans un compartiment S3 les fichiers truststore.jks (précédemment créé) et /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (changer la version XXX selon la version du DME).
Téléchargez sur votre machine client DBeaver le truststore.jks ainsi que trino-jdbc-XXX-amzn-0.jar fichiers.
Ouvrez DBeaver et choisissez Base de données, Puis choisissez Driver Manager.
Selectionnez Nouveauté pour créer un nouveau pilote.
Sur le Paramètres onglet, fournissez les informations suivantes :
- Pour Nom du conducteur, Entrer EMR Trino.
- Pour Nom du cours, Entrer io.trino.jdbc.TrinoDriver.
- Pour Modèle d'URL, Entrer jdbc:trino://{host}:{port}.
Sur le Bibliothèques , procédez comme suit :
- Selectionnez Ajouter un fichier.
- Choisissez le fichier JAR du pilote Trino JDBC dans le système de fichiers local (trino-jdbc-XXX-amzn-0.jar).
Selectionnez OK pour créer le pilote.
Selectionnez Base de données ainsi que Nouvelle connexion à la base de données.
Sur le Entrée , spécifiez les éléments suivants :
- Pour Connectez-vous par, sélectionnez Hôte.
- Pour Hôte, entrez le nœud principal EMR.
- Pour Port, entrez le port Trino (8446 par défaut).
Sur le Propriétés du pilote , ajoutez les propriétés suivantes :
- Ajouter SSL avec True comme valeur.
- Ajouter SSLTrustStorePath les truststore.jks emplacement du fichier comme valeur.
- Ajouter SSLTrustStorePassword les truststore.jks mot de passe que vous avez utilisé pour le créer comme valeur.
Selectionnez Finition.
Choisissez la connexion créée et choisissez le NOUS CONTACTER icône.
Saisissez votre nom d'utilisateur et votre mot de passe LDAP, puis choisissez OK.

Si tout fonctionne, vous devriez pouvoir parcourir les catalogues, bases de données et tables Trino dans le volet de navigation. Pour exécuter des requêtes, choisissez Éditeur SQL, Puis choisissez Ouvrir l'éditeur SQL.

Depuis l'éditeur SQL, vous pouvez interroger vos tables.

Prochaines étapes

La nouvelle fonctionnalité d'authentification LDAP d'Amazon EMR simplifie la manière dont les utilisateurs peuvent accéder aux infrastructures installées EMR. Lorsque les utilisateurs utilisent un framework, vous souhaiterez peut-être gérer les données auxquelles ils peuvent accéder. Pour ce sujet spécifique, vous pouvez utiliser l'authentification LDAP en combinaison avec l'intégration native EMR Apache Ranger. Pour plus d'informations, reportez-vous à Intégrez Amazon EMR à Apache Ranger.

Nettoyer

Effectuez les actions de nettoyage suivantes pour supprimer les ressources que vous avez créées à la suite de cette publication et éviter d'engager des coûts supplémentaires. Pour cet article, nous nettoyons à l'aide de l'AWS CLI. Vous pouvez également nettoyer en utilisant des actions similaires via la console.

Si vous avez lancé une instance EC2 pour vérifier la connectivité LDAP et que vous n'en avez plus besoin, supprimez-la avec la commande suivante (précisez votre ID d'instance) :
```
aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>
```
Si vous avez lancé une instance EC2 pour tester DBeaver et que vous n'en avez plus besoin, vous pouvez utiliser la commande précédente pour la supprimer.
Supprimez le cluster EMR avec la commande suivante (spécifiez votre ID de cluster EMR) :
```
aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>
```
Notez que si le cluster EMR a Protection contre la résiliation activé, avant d'exécuter la procédure précédente terminate-clusters commande, vous devez la désactiver. Vous pouvez le faire avec la commande suivante (spécifiez votre ID de cluster EMR) :
```
aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1
```

Supprimez la configuration de sécurité EMR avec la commande suivante :

aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

Supprimez les secrets Secrets Manager avec les commandes suivantes :

aws secretsmanager delete-secret 
--secret-id <first-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

aws secretsmanager delete-secret 
--secret-id <second-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

Conclusion

Dans cet article, nous avons expliqué comment configurer et tester l'authentification LDAP sur EMR sur les clusters EC2. Nous avons expliqué comment récupérer les paramètres LDAP nécessaires, tester la connectivité avec le point de terminaison LDAP, configurer votre configuration de sécurité EMR et tester le bon fonctionnement de l'authentification LDAP. Cet article a également souligné à quel point le flux d'authentification est simplifié par rapport à la configuration standard de confiance entre domaines Active Directory. Pour en savoir plus sur cette fonctionnalité, reportez-vous à Utilisez des serveurs Active Directory ou LDAP pour l'authentification avec Amazon EMR.

À propos des auteurs

Stefano Sandona est architecte senior de solutions Big Data chez AWS. Il aime les données, les systèmes distribués et la sécurité. Il aide ses clients du monde entier à concevoir des plateformes Big Data sécurisées, évolutives et fiables.

Adnan Hémani est un ingénieur en développement logiciel chez AWS travaillant avec l'équipe EMR. Il se concentre sur la posture de sécurité des applications exécutées sur des clusters EMR. Il s'intéresse aux applications Big Data modernes et à la manière dont les clients interagissent avec elles.

Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
La source: https://aws.amazon.com/blogs/big-data/simplify-authentication-with-native-ldap-integration-on-amazon-emr/

Intelligence de données générative

Simplifiez l'authentification avec l'intégration LDAP native sur Amazon EMR | Services Web Amazon

Fonctionnement de l'intégration Amazon EMR LDAP

Trouver les paramètres LDAP appropriés

Testez la solution

Créer des secrets AWS Secret Manager

Créer la configuration de sécurité EMR

Lancer le cluster EMR

Confirmez que l'authentification LDAP fonctionne

Prochaines étapes

Nettoyer

Conclusion

À propos des auteurs

Comment utiliser des sacs personnalisés au Royaume-Uni pour transformer votre entreprise

Le protocole de jalonnement Ethereum Lido Finance dépasse le million de validateurs

Dernières informations

Présentation de QuantoSwap : un DEX révolutionnaire basé sur Ethereum avec plusieurs sources de revenus

Solo Bitcoin Miner obtient une récompense de bloc entière de 3.125 BTC

OpenAI en pourparlers pour un partenariat avec Worldcoin (WLD)

Interdiction des crypto-monnaies en Russie : seuls les actifs numériques nationaux sont autorisés à partir du 1er septembre

La France propose d'acheter des actifs stratégiques à la société informatique en difficulté Atos

Avraham Eisenberg, exploiteur des marchés de mangues, accusé de possession de pornographie juvénile