Logotipo de Zephyrnet

Inteligencia de datos generativa

Big Data

Simplifique la autenticación con integración LDAP nativa en Amazon EMR | Servicios web de Amazon

Reeditado por Platón
Reeditado por Platón

Fecha:

Vistas: 83

Muchas empresas tienen identidades corporativas almacenadas dentro de proveedores de identidad (IdP) como Directorio Activo (AD) o OpenLDAP. Anteriormente, los clientes que usaban EMR de Amazon podrían integrar sus clústeres con Active Directory configurando una confianza de dominio unidireccional entre su dominio AD y el dominio Kerberos del clúster EMR. Para obtener más detalles, consulte Tutorial: Configurar una confianza entre dominios con un dominio de Active Directory.

Esta configuración ha sido un factor clave para que los usuarios y grupos corporativos estén disponibles dentro de los clústeres de EMR y para definir políticas de control de acceso para controlar su acceso a los datos (por ejemplo, a través de la Integración nativa de Apache Ranger de Amazon EMR).

Aunque esta opción todavía está disponible, Amazon EMR ha lanzado soporte para autenticación LDAP nativa, una nueva característica de seguridad que simplifica la integración con OpenLDAP y Active Directory.

Esta característica permite lo siguiente:

  • Configuración automática de seguridad para las aplicaciones compatibles (HiveServer2, Trino, Presto y Livy) para utilizar el protocolo Kerberos bajo el capó y LDAP como autenticación externa. Esto permite una integración más sencilla desde herramientas externas que, para conectarse con los puntos finales del clúster, ya no tienen que configurar la autenticación Kerberos sino que, en cambio, pueden configurarse simplemente para proporcionar un nombre de usuario y contraseña LDAP.
  • control de acceso detallado (FGAC) sobre quién puede acceder a sus clústeres de EMR a través de SSH
  • políticas de autorización detalladas además de la base de datos y las tablas de Hive Metastore si se usan en combinación con la integración nativa de Amazon EMR Apache Ranger.

En esta publicación, profundizamos en la autenticación LDAP de Amazon EMR, mostrando cómo funciona el flujo de autenticación, cómo recuperar y probar las configuraciones LDAP necesarias y cómo confirmar que un clúster de EMR está correctamente integrado con LDAP.

Usando la información de este blog:

  • Los equipos que administran clústeres de EMR pueden mejorar la coordinación con sus administradores de IdP de LDAP para solicitar la información adecuada y realizar correctamente las pruebas de configuración previa.
  • Los usuarios finales del clúster EMR pueden comprender lo sencillo que es conectarse desde herramientas externas a clústeres EMR habilitados para LDAP en comparación con la autenticación anterior basada en Kerberos.

Cómo funciona la integración LDAP de Amazon EMR

Cuando hablamos de autenticación en el contexto de los marcos EMR, podemos distinguir entre dos niveles:

  • Autenticación externa – Utilizado por usuarios y componentes externos para interactuar con los marcos instalados.
  • Autenticación interna – Se utiliza dentro de los marcos para autenticar las comunicaciones de los componentes internos.

Con esta nueva característica, la autenticación del marco interno todavía se administra a través de Kerberos, pero esto es transparente para los usuarios finales o servicios externos que, por otro lado, utilizan un nombre de usuario y una contraseña para autenticarse.

Los marcos instalados de EMR compatibles implementan un método de autenticación basado en LDAP que, dado un conjunto de credenciales de nombre de usuario y contraseña, los valida con el punto final LDAP y, en caso de éxito, habilita el uso del marco.

El siguiente diagrama resume cómo funciona el flujo de autenticación.

El flujo de trabajo incluye los siguientes pasos:

  1. Un usuario se conecta con uno de los puntos finales admitidos (como HiveServer2, Trino/Presto Coordinator o Hue WebUI) y proporciona sus credenciales corporativas (nombre de usuario y contraseña).
  2. El marco contactado utiliza un autenticador personalizado que realiza la autenticación utilizando el servicio EMR Secret Agent que se ejecuta dentro de las instancias del clúster.
  3. El servicio EMR Secret Agent valida las credenciales proporcionadas con el punto final LDAP.
  4. En caso de éxito ocurre lo siguiente:
    • Se crea una entidad principal de Kerberos para el usuario específico en el centro de distribución de claves MIT del clúster (MIT KDC) que se ejecuta dentro del nodo principal.
    • La tabla de claves principal de Kerberos se crea dentro del directorio de inicio del usuario en el nodo principal.

Una vez completada la autenticación, el usuario puede comenzar a utilizar el marco.

Dentro de todas las instancias del clúster, el servicio SSSD está configurado para recuperar usuarios y grupos del punto final LDAP y hacerlos disponibles como usuarios del sistema.

El flujo de autenticación al conectarse con SSH es un poco diferente y se resume en el siguiente diagrama.

El flujo de trabajo incluye los siguientes pasos:

  1. Un usuario se conecta con SSH a la instancia principal de EMR y proporciona las credenciales corporativas (nombre de usuario y contraseña).
  2. El servicio SSHD contactado utiliza el servicio SSSD para validar las credenciales proporcionadas.
  3. El servicio SSSD valida las credenciales proporcionadas con el punto final LDAP. En caso de éxito, el usuario llega al directorio de inicio relacionado. En este punto, el usuario puede utilizar las diferentes CLI (beeline, trino-cli, presto-cli, curl) para acceder a Hive, Trino/Presto o Livy.
  4. Para utilizar las CLI de Spark (spark-submit, pyspark, spark-shell), el usuario tiene que invocar el ldap-kinit script y proporcione el nombre de usuario y la contraseña solicitados.
  5. La autenticación se realiza utilizando el servicio EMR Secret Agent que se ejecuta dentro de las instancias del clúster.
  6. El servicio EMR Secret Agent valida las credenciales proporcionadas con el punto final LDAP.
  7. En caso de éxito ocurre lo siguiente:
    • Se crea una entidad principal de Kerberos para el usuario específico en el clúster MIT KDC que se ejecuta dentro del nodo principal.
    • La tabla de claves principal de Kerberos se crea dentro del directorio de inicio del usuario en el nodo principal.
    • Se obtiene un ticket Kerberos y se almacena en la caché de tickets Kerberos del usuario en el nodo principal.

Una vez que el ldap-kinit Cuando se completa el script, el usuario puede comenzar a usar las CLI de Spark.

En las siguientes secciones, mostramos cómo recuperar los valores de configuración LDAP requeridos e investigamos cómo iniciar un clúster con autenticación LDAP de EMR y probarlo.

Encuentre los parámetros LDAP adecuados

Para configurar la autenticación LDAP para Amazon EMR, el primer paso es recuperar las propiedades LDAP que se utilizarán para configurar su clúster. Necesitas la siguiente información:

  • El nombre DNS del servidor LDAP
  • Un certificado en formato PEM que se utilizará para interactuar a través de LDAP seguro (LDAPS) con el punto final LDAP
  • La base de búsqueda de usuarios LDAP, que es una ruta (o rama) en el árbol LDAP desde donde buscar usuarios (solo se recuperarán los usuarios que pertenecen a esta rama).
  • La base de búsqueda de grupos LDAP, que es una ruta (o rama) en el árbol LDAP desde donde buscar grupos (solo se recuperarán los grupos que pertenecen a esta rama).
  • El servidor LDAP vincula las credenciales de usuario, que son el nombre de usuario y la contraseña de un usuario de servicio (normalmente denominado usuario vinculado) que se utilizará para activar consultas LDAP y recuperar información del usuario, como el nombre de usuario y la pertenencia al grupo.

Con Active Directory, un administrador de AD puede recuperar esta información directamente desde el Active Directory Users and Computers herramienta. Cuando elige un usuario en esta herramienta, puede ver los atributos relacionados (por ejemplo, distinguishedName). La siguiente captura de pantalla muestra un ejemplo.

En la captura de pantalla, podemos ver que el distinguishedName para el usuario john es CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, lo que significa que john pertenece a las siguientes bases de búsqueda, ordenadas de la más estrecha a la más amplia:

  • 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

Dependiendo de la cantidad de entradas dentro del directorio LDAP de una empresa, el uso de una base de búsqueda amplia puede generar tiempos de recuperación prolongados y tiempos de espera. Es una buena práctica configurar la base de búsqueda para que sea lo más estrecha posible para incluir a todos los usuarios necesarios. En el ejemplo anterior, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com puede ser una buena base de búsqueda si todos los usuarios a los que desea proporcionar acceso al clúster EMR son parte de esa unidad organizativa.

Otra forma de recuperar atributos de usuario es utilizando el ldapsearch herramienta. Puede utilizar este método tanto para Active Directory como para OpenLDAP, y es extremadamente útil para probar la conectividad con el punto final LDAP.

El siguiente es un ejemplo con Active Directory (OpenLDAP es similar).

El punto final LDAP debe poder resolverse y ser accesible mediante Nube informática elástica de Amazon (Amazon EC2) Instancias del clúster EMR a través de TCP en el puerto 636. Se sugiere ejecutar la prueba desde una instancia EC2 de Amazon Linux 2 que pertenezca a la misma subred que el clúster EMR y que tenga el mismo grupo de seguridad EMR asociado que las instancias del clúster EMR.

Después de iniciar una instancia EC2, instale el nc herramienta y pruebe la resolución DNS y la conectividad. Asumiendo que DC1.awsemr.com es el nombre DNS para el punto final LDAP, ejecute los siguientes comandos:

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

Si la resolución DNS no funciona correctamente, debería recibir un error como el siguiente:

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

Si no se puede acceder al punto final, debería recibir un error como el siguiente:

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

En cualquiera de estos casos, el equipo de redes y DNS debe participar para solucionar los problemas.

En caso de éxito, el resultado debería verse como el siguiente:

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 todo funciona, continúe con la prueba e instale el openldap clientes de la siguiente manera:

sudo yum install openldap-clients

Entonces corre ldapsearch Comandos para recuperar información sobre usuarios y grupos desde el punto final LDAP. Los siguientes son ejemplos ldapsearch comandos:

#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}"

Utilizamos los siguientes parámetros:

  • -x – Esto permite una autenticación sencilla.
  • -D – Indica al usuario que debe realizar la búsqueda.
  • -w – Indica la contraseña del usuario.
  • -H – Esto indica la URL del servidor LDAP.
  • -b – Esta es la búsqueda base.
  • LDAPTLS_CACERT – Esto indica el certificado público SSL PEM del punto final LDAPS o el certificado público SSL PEM de la autoridad certificadora raíz del punto final LDAPS. Esto se puede obtener de un usuario administrador de AD u OpenLDAP.

El siguiente es un ejemplo de resultado del comando anterior:

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

Como podemos ver en el resultado de muestra, el usuario John se identifica con el nombre distinguido CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, y la data-engineers grupo al que pertenece el usuario (memberOf valor) se identifica por el nombre distinguido CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Podemos ejecutar nuestro ldapsearch consultas para recuperar información de usuarios y grupos utilizando una base de búsqueda limitada:

#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})" "*"

También puedes aplicar otros filtros durante la búsqueda. Para obtener más información sobre cómo crear filtros LDAP, consulte Filtros LDAP.

Mediante la ejecución ldapsearch comandos, puede probar la conectividad LDAP y las propiedades LDAP, y determinar la configuración necesaria.

Prueba la solución

Después de haber verificado que la conectividad al punto final LDAP está abierta y que las configuraciones LDAP son correctas, continúe con la configuración del entorno para iniciar un clúster habilitado para LDAP de EMR.

Crear secretos de AWS Secret Manager

Antes de crear la configuración de seguridad de EMR, debe crear dos Administrador secreto de AWS misterios. Estas credenciales se utilizan para interactuar con el punto final LDAP y recuperar detalles del usuario, como el nombre de usuario y la pertenencia al grupo.

  1. En la consola de Secrets Manager, elija Misterios en el panel de navegación.
  2. Elige Almacenar un nuevo secreto.
  3. tipo secreto, seleccione Otro tipo de secreto.
  4. Cree un nuevo secreto especificando el binduser nombre distinguido como la clave y el binduser contraseña como valor.
  5. Cree un segundo secreto que especifique en texto sin formato el certificado público SSL del punto final LDAPS o el certificado público de la autoridad de certificación raíz LDAPS.
    Este certificado es confiable, lo que permite una comunicación segura entre el clúster EMR y el punto final LDAPS.

Crear la configuración de seguridad de EMR

Complete los siguientes pasos para crear la configuración de seguridad de EMR:

  1. En la consola de Amazon EMR, elija Configuraciones de seguridad bajo EMR en EC2 en el panel de navegación.
  2. Elige Crear.
  3. Nombre de la configuración de seguridad, ingresa un nombre.
  4. Opciones de configuración de configuración de seguridad, seleccione Elija configuraciones personalizadas.
  5. Cifrado, seleccione Activar el cifrado en tránsito.
  6. Tipo de proveedor de certificadosSeleccione PEM.
  7. Elija la ubicación del certificado PEM, ingrese un paquete PEM ubicado en Servicio de almacenamiento simple de Amazon (Amazon S3) o un proveedor de certificados personalizados de Java.
    Tenga en cuenta que el cifrado en tránsito es obligatorio para poder utilizar la función de autenticación LDAP. Para obtener más información sobre el cifrado en tránsito, consulte Proporcionar certificados para cifrar datos en tránsito con cifrado de Amazon EMR.
  8. Elige Siguiente.
  9. Seleccione LDAP para Protocolo de autenticacion.
  10. Ubicación del servidor LDAP, ingrese el punto final LDAPS (ldaps://<ldap_endpoint_DNS_name>).
  11. Certificado SSL LDAP, ingrese el segundo secreto que creó en Secrets Manager.
  12. Filtro de acceso LDAP, ingrese un filtro LDAP que se aplica para restringir el acceso a un subconjunto de usuarios recuperados de la base de búsqueda de usuarios LDAP. Si el campo se deja vacío, no se aplican filtros y todos los usuarios que pertenecen a la base de búsqueda de usuarios LDAP pueden acceder a los puntos finales protegidos por LDAP de EMR con sus credenciales corporativas. Los siguientes son filtros de ejemplo y sus funciones:
    • (claseobjeto=persona) – Filtrar usuarios con el atributo. objectClass establecer como person
    • (miembroDe=CN=administradores,OU=grupos,OU=italia,OU=emr,DC=awsemr,DC=com) – Filtrar usuarios pertenecientes al admins grupo de XNUMX
    • (|(miembro de=CN=ingenieros de datos,OU=grupos,OU=italia,OU=emr,DC=awsemr,DC=com)(miembro de=CN=administradores,OU=grupos,OU=italia,OU=emr, DC=awsemr,DC=com)) – Filtrar usuarios pertenecientes ya sea al data-engineers o de admins grupo (que usamos para esta publicación)
  13. Ingrese valores para Base de búsqueda de usuarios LDAP y Base de búsqueda de grupos LDAP. Tenga en cuenta que las dos bases de búsqueda no admiten filtros en línea (por ejemplo, lo siguiente no es compatible: 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))).
  14. Seleccione Activar el inicio de sesión SSH. Esto solo es necesario si desea que sus usuarios de LDAP puedan utilizar SSH dentro de instancias del clúster con sus credenciales corporativas. Si el inicio de sesión SSH está habilitado, se necesita el filtro de acceso LDAP; de lo contrario, la autenticación SSH fallará.
  15. Credenciales de enlace del servidor LDAP, ingrese el primer secreto que creó en Secrets Manager.
  16. En Autorización sección, mantenga seleccionados los valores predeterminados:
    • Rol de IAM para aplicaciones, seleccione Perfil de instancia.
    • Método de control de acceso detallado, seleccione Ninguna.
  17. Elige Siguiente.
  18. Revise el resumen de configuración y elija Crear.

Inicie el clúster EMR

Puede iniciar el clúster EMR utilizando el Consola de administración de AWS, la Interfaz de línea de comandos de AWS (AWS CLI), o cualquier SDK de AWS.

Cuando cree el EMR en el clúster EC2, asegúrese de especificar las siguientes configuraciones:

  • versión EMR – Utilice Amazon EMR 6.12.0 o superior.
  • Aplicaciones – Seleccione Hadoop, Spark, Hive, Hue, Livy y Presto/Trino.
  • Configuración de seguridad – Especifique la configuración de seguridad que creó en el paso anterior.
  • Par de claves EC2 – Utilice un par de claves existente.
  • Grupos de red y seguridad. – Utilice una configuración que permita que las instancias EMR EC2 interactúen con el punto final LDAPS. En el Encuentre los parámetros LDAP adecuados sección, debería haber confirmado una configuración válida.

Confirme que la autenticación LDAP esté funcionando

Cuando el clúster esté en funcionamiento, puede comprobar que la autenticación LDAP funciona correctamente.

If inicio de sesión ssh fue habilitado como parte de Autenticación LDAP dentro de Configuración de seguridad EMR, puede acceder mediante SSH a su clúster especificando un usuario LDAP y solicitando la contraseña relacionada cuando se le solicite:

ssh myldapuser@<emr_primary_node>

Si el inicio de sesión SSH estaba deshabilitado, puede utilizar SSH dentro del clúster utilizando el par de claves EC2 especificado durante la creación del clúster:

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

Una forma alternativa de acceder a la instancia principal, si lo prefiere, es utilizar Gestor de sesiones, una capacidad de Gerente de sistemas de AWS. Para obtener más información, consulte Conéctese a su instancia de Linux con AWS Systems Manager Session Manager.

Cuando esté dentro de la instancia principal, puede probar que los usuarios y grupos LDAP se recuperen correctamente utilizando el id dominio. El siguiente es un comando de muestra para comprobar si el usuario john se recupera correctamente con los grupos relacionados:

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

Luego puede probar la autenticación en los diferentes marcos instalados.

Primero, recuperemos el certificado público de los marcos y almacenémoslo dentro de un almacén de confianza. Todos los marcos comparten el mismo certificado público (el que usamos para configurar el cifrado en tránsito), por lo que puede usar cualquiera de los puntos finales protegidos por SSL (puerto Hive 10000, puerto Presto/Trino 8446, puerto Livy 8998) para recuperarlo. . Tome el certificado del punto final de HiveServer2 (puerto 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

Luego utilice este almacén de confianza para comunicarse de forma segura con los diferentes marcos.

Utilice el siguiente código para probar la autenticación de HiveServer2 con 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 utiliza Presto, pruebe la autenticación de Presto con el presto CLI (proporcione la contraseña de usuario cuando se le solicite):

#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 utiliza Trino, pruebe la autenticación de Trino con el trino CLI (proporcione la contraseña de usuario cuando se le solicite):

#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

Probar Livy autenticación con 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: "]}

Pruebe los comandos de Spark con 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()

Tenga en cuenta que aquí probamos la autenticación desde dentro del clúster, pero podemos interactuar con Trino, Hive, Presto y Livy incluso desde fuera del clúster, siempre que la conectividad y la resolución DNS estén configuradas correctamente. Las CLI de Spark son las únicas que se pueden utilizar únicamente desde el interior del clúster.

Para probar la autenticación de Hue, complete los siguientes pasos:

  1. Navegue a la interfaz de usuario web de Hue alojada en http://<emr_primary_node>:8888/ y proporcione un nombre de usuario y contraseña de LDAP.
  2. Pruebe consultas SQL dentro de los editores Hive y Trino/Presto.

Para probar con una herramienta SQL externa (como DBeaver conectando a Trino), complete los siguientes pasos. Asegúrese de configurar el grupo de seguridad del nodo primario de EMR para que permita el tráfico TCP desde la IP de DBeaver al puerto del punto final del marco deseado (por ejemplo, 10000 para HiveServer2, 8446 para Trino/Presto) y para configurar correctamente la resolución de DNS en el cliente DBeaver. máquina para resolver correctamente el nombre de host del nodo principal de EMR.

  1. Desde la instancia principal de su clúster de EMR, copie a un depósito S3 los archivos truststore.jks (previamente creado) y /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (cambiar la versión XXX dependiendo de la versión EMR).
  2. Descargue en su máquina cliente DBeaver el truststore.jks y trino-jdbc-XXX-amzn-0.jar archivos.
  3. Abra DBeaver y elija Base de datos, A continuación, elija Administrador de conductor.
  4. Elige Nuevo para crear un nuevo controlador.
  5. En Ajustes pestaña, proporcione la siguiente información:
    • Nombre del conductor, introduzca EMR Trino.
    • Nombre de la clase, introduzca io.trino.jdbc.TrinoDriver.
    • Plantilla de URL, introduzca jdbc:trino://{host}:{port}.
  6. En Bibliotecas pestaña, complete los siguientes pasos:
    • Elige Agregar Archivo.
    • Elija el archivo JAR del controlador Trino JDBC del sistema de archivos local (trino-jdbc-XXX-amzn-0.jar).
  7. Elige OK para crear el controlador.
  8. Elige Base de datos y Nueva conexión de base de datos.
  9. En Inicio pestaña, especifique lo siguiente:
    • Conéctate por, seleccione Anfitrión.
    • Anfitrión, ingrese el nodo principal de EMR.
    • Puerto, ingrese el puerto Trino (8446 por defecto).
  10. En Propiedades del controlador pestaña, agregue las siguientes propiedades:
    • Añada SSL True como el valor
    • Añada SSLTrustStorePath con el truststore.jks ubicación del archivo como valor.
    • Añada SSLTrustStorePassword con el truststore.jks contraseña que utilizó para crearlo como valor.
  11. Elige Acabado.
  12. Elija la conexión creada y elija el CONTACTO del icono.
  13. Ingrese su nombre de usuario y contraseña de LDAP, luego elija OK.

Si todo funciona, debería poder explorar los catálogos, bases de datos y tablas de Trino en el panel de navegación. Para ejecutar consultas, elija Editor SQL, A continuación, elija Abrir el editor SQL.

Desde el Editor SQL, puede consultar sus tablas.

Próximos pasos

La nueva función de autenticación LDAP de Amazon EMR simplifica la forma en que los usuarios pueden obtener acceso a los marcos instalados de EMR. Cuando los usuarios utilizan un marco, es posible que desee controlar los datos a los que pueden acceder. Para este tema específico, puede utilizar la autenticación LDAP en combinación con la integración nativa de EMR Apache Ranger. Para obtener más información, consulte Integre Amazon EMR con Apache Ranger.

Limpiar

Complete las siguientes acciones de limpieza para eliminar los recursos que creó después de esta publicación y evitar incurrir en costos adicionales. Para esta publicación, limpiamos usando la CLI de AWS. También puedes limpiar usando acciones similares a través de la consola.

  1. Si lanzó una instancia EC2 para verificar la conectividad LDAP y ya no la necesita, elimínela con el siguiente comando (especifique su ID de instancia): 
    aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>

  2. Si lanzó una instancia EC2 para probar DBeaver y ya no la necesita, puede usar el comando anterior para eliminarla.
  3. Elimine el clúster de EMR con el siguiente comando (especifique su ID de clúster de EMR): 
    aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>

    Tenga en cuenta que si el clúster EMR tiene Protección de terminación habilitado, antes de ejecutar el anterior terminate-clusters comando, tienes que desactivarlo. Puede hacerlo con el siguiente comando (especifique su ID de clúster de EMR):

    aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1

  4. Elimine la configuración de seguridad de EMR con el siguiente comando: 
    aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

  5. Elimine los secretos de Secrets Manager con los siguientes comandos: 
    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>

Conclusión

En esta publicación, analizamos cómo puede configurar y probar la autenticación LDAP en EMR en clústeres EC2. Discutimos cómo recuperar la configuración LDAP necesaria, probar la conectividad con el punto final LDAP, configurar su configuración de seguridad EMR y probar que la autenticación LDAP funciona correctamente. Esta publicación también destacó cómo se simplifica el flujo de autenticación en comparación con la configuración de confianza entre dominios estándar de Active Directory. Para obtener más información sobre esta función, consulte Utilice servidores Active Directory o LDAP para la autenticación con Amazon EMR.

Acerca de los autores

Stefano Sandona es arquitecto sénior de soluciones de Big Data en AWS. Le encantan los datos, los sistemas distribuidos y la seguridad. Ayuda a clientes de todo el mundo a diseñar plataformas de big data seguras, escalables y confiables.

Adnan Hemani es un ingeniero de desarrollo de software en AWS que trabaja con el equipo de EMR. Se centra en la postura de seguridad de las aplicaciones que se ejecutan en clústeres de EMR. Está interesado en las aplicaciones modernas de Big Data y en cómo los clientes interactúan con ellas.

punto_img

Información más reciente

punto_img

Derechos de autor @ 2024 Plato Technologies Inc.