Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Autenticación en nodos de clúster de Amazon EMR
Lo clientes SSH pueden utilizar un par de claves de Amazon EC2 para autenticarse en instancias de clúster. De forma alternativa, con las versiones 5.10.0 y posteriores de Amazon EMR, puede configurar Kerberos para autenticar a los usuarios y las conexiones SSH con el nodo principal. Además, con las versiones 5.12.0 y posteriores de Amazon EMR, puede autenticarse con LDAP.
**Topics**
+ [Use un par de claves de EC2 para credenciales de SSH para Amazon EMR](emr-plan-access-ssh.md)
+ [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md)
+ [Uso de servidores de Active Directory o LDAP para la autenticación con Amazon EMR](ldap.md)
# Use un par de claves de EC2 para credenciales de SSH para Amazon EMR
Los nodos de clúster de Amazon EMR se ejecutan en instancias de Amazon EC2. Puede conectarse a nodos del clúster de la misma forma que puede conectarse a instancias de Amazon EC2. Puede utilizar Amazon EC2 para crear un par de claves, o bien puede importar un par de claves. Al crear un clúster, puede especificar el par de claves de Amazon EC2 que se utilizará para las conexiones SSH en todas las instancias del clúster. También puede crear un clúster sin un par de claves. Esto se hace con clústeres transitorios que se inician, ejecutan pasos, y luego se terminan de forma automática.
El cliente SSH que se utiliza para conectar al clúster necesita utilizar el archivo de clave privada asociado a este par de claves. Se trata de un archivo.pem para clientes SSH que utilizan Linux, Unix y MacOS. Debe establecer permisos para que solo el propietario de la clave tenga permiso para acceder al archivo. Para los clientes SSH que utilizan Windows, es un archivo .ppk, que normalmente se crea a partir del archivo .pem.
+ Para obtener más información sobre la creación de un par de claves de Amazon EC2, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
+ *Para obtener instrucciones sobre cómo usar Pu TTYgen para crear un archivo.ppk a partir de un archivo.pem, [consulte Convertir la clave privada mediante Pu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) en la Guía del usuario de TTYgen Amazon EC2.*
+ Para obtener más información sobre cómo configurar los permisos del archivo.pem y cómo conectarse al nodo principal de un clúster de EMR mediante diferentes métodos, incluidos `ssh` Linux o macOS, PuTTY desde Windows o AWS CLI desde cualquier sistema operativo compatible, consulte. [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md)
# Uso de Kerberos para la autenticación con Amazon EMR
Las versiones 5.10.0 y posteriores de Amazon EMR son compatibles con Kerberos. Kerberos es un protocolo de autenticación de redes que utiliza la criptografía de clave secreta para proporcionar una autenticación sólida, de forma que las contraseñas u otras credenciales no se envíen a través de la red en un formato no cifrado.
En Kerberos, los servicios y los usuarios que necesitan autenticarse se conocen como *entidades principales*. Las entidades principales existen dentro de un *ámbito* de Kerberos. En el ámbito, un servidor de Kerberos conocido como *centro de distribución de claves (KDC)* proporciona los medios para que se autentiquen las entidades principales. El KDC lo hace mediante la emisión de *tickets* para la autenticación. El KDC mantiene una base de datos de las entidades principales dentro de su ámbito, sus contraseñas y otros datos administrativos sobre cada una de las entidades principales. Un KDC también puede aceptar credenciales de autenticación de entidades principales de otros ámbitos, lo que se conoce como una *confianza entre ámbitos*. Además, un clúster de EMR puede utilizar un KDC externo para autenticar principales.
Una forma común de establecer una relación de confianza entre ámbitos o de utilizar un KDC externo es autenticar a los usuarios desde un dominio de Active Directory. Esto permite a los usuarios obtener acceso a un clúster de EMR con su cuenta de dominio cuando utilizan SSH para conectarse a un clúster o trabajan con aplicaciones de macrodatos.
Si utiliza autenticación de Kerberos, Amazon EMR configura Kerberos para las aplicaciones, componentes y subsistemas que instala en el clúster, de forma que se autentiquen entre sí.
**importante**
Amazon EMR no se admite AWS Directory Service for Microsoft Active Directory en un fideicomiso entre dominios ni como un KDC externo.
Antes de configurar Kerberos con Amazon EMR, le recomendamos que se familiarice con los conceptos de Kerberos, los servicios que se ejecutan en un KDC y las herramientas de administración de servicios de Kerberos. Para obtener más información, consulte la [documentación de Kerberos del MIT](http://web.mit.edu/kerberos/krb5-latest/doc/), que publica el [consorcio Kerberos](http://kerberos.org/).
**Topics**
+ [Aplicaciones compatibles con Amazon EMR](emr-kerberos-principals.md)
+ [Opciones de la arquitectura de Kerberos con Amazon EMR](emr-kerberos-options.md)
+ [Configuración de Kerberos en Amazon EMR](emr-kerberos-configure.md)
+ [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: Configuración de un KDC dedicado del clúster con Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md)
# Aplicaciones compatibles con Amazon EMR
Dentro de un clúster de EMR, las entidades principales de Kerberos son los servicios de aplicaciones de macrodatos y los subsistemas que se ejecutan en todos los nodos del clúster. Amazon EMR puede configurar las aplicaciones y componentes que se indican a continuación para utilizar Kerberos. Cada aplicación tiene una entidad principal de Kerberos asociada.
Amazon EMR no admite las relaciones de confianza entre ámbitos con AWS Directory Service for Microsoft Active Directory.
Amazon EMR solo configura las características de autenticación de Kerberos de código abierto para las aplicaciones y los componentes indicados a continuación. Cualquier otra aplicación instalada no utiliza Kerberos, lo que puede provocar la incapacidad para comunicarse con los componentes que utilizan Kerberos y generar errores en la aplicación. Las aplicaciones y componentes que no utilizan Kerberos no tienen habilitada la autenticación. Las aplicaciones y los componentes compatibles pueden variar según las distintas versiones de Amazon EMR.
La interfaz de usuario de Livy es la única interfaz de usuario web alojada en el clúster que está kerberizado.
+ **Hadoop MapReduce**
+ **HBase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ No active Hive con la autenticación LDAP. Esto puede provocar problemas al comunicarse con el YARN que utiliza Kerberos.
+ **Hue**
+ Hue la autenticación de usuarios no se establece automáticamente y se pueden configurar mediante la configuración de la API.
+ El servidor de Hue utiliza Kerberos. El front-end (la UI) de Hue no está configurado para la autenticación. La autenticación LDAP se puede configurar para la UI de Hue.
+ **Livy**
+ La suplantación de Livy con clústeres kerberizados es compatible con las versiones 5.22.0 y posteriores de Amazon EMR.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto admite la autenticación de Kerberos en las versiones 6.9.0 y posteriores de Amazon EMR.
+ Si quiere usar la autenticación de Kerberos para Presto, debe habilitar el [cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino admite la autenticación de Kerberos en las versiones 6.11.0 y posteriores de Amazon EMR.
+ Si quiere usar la autenticación de Kerberos para Trino, debe habilitar el [cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ Zeppelin solo está configurado para utilizar Kerberos con el intérprete Spark. No está configurado para otros intérpretes.
+ Los intérpretes de Zeppelin kerberizado que no sean Spark no admiten la suplantación de identidad de usuario.
+ **ZooKeeper**
+ Zookeeper cliente no es compatible.
# Opciones de la arquitectura de Kerberos con Amazon EMR
Cuando se utiliza Kerberos con Amazon EMR, puede elegir entre las arquitecturas que se indican en esta sección. Independientemente de la arquitectura que elija, para configurar Kerberos hay que seguir los mismos pasos. Debe crear una configuración de seguridad, especificar la configuración de seguridad y las opciones de Kerberos específicas del clúster compatibles al crear el clúster y crear directorios de HDFS para los usuarios de Linux en el clúster que coincidan con las entidades principales de usuarios en el KDC. Para leer una explicación sobre las opciones de configuración y configuraciones de ejemplo de cada arquitectura, consulte [Configuración de Kerberos en Amazon EMR](emr-kerberos-configure.md).
## KDC dedicado del clúster (KDC en nodo principal)
Esta configuración está disponible con las versiones 5.10.0 y posteriores de Amazon EMR.
![\[Amazon EMRclúster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Ventajas**
+ Amazon EMR tiene la plena propiedad del KDC.
+ El KDC en el clúster de EMR es independiente de las implementaciones de KDC centralizadas, como Microsoft Active Directory o AWS Managed Microsoft AD.
+ El impacto en el rendimiento es mínimo, ya que el KDC administra la autenticación solo para los nodos locales del clúster.
+ Opcionalmente, otros clústeres que utilizan Kerberos pueden hacer referencia al KDC como un KDC externo. Para obtener más información, consulte [KDC externo: nodo principal en un clúster diferente](#emr-kerberos-extkdc-cluster-summary).
**Consideraciones y limitaciones**
+ Los clústeres que utilizan Kerberos no se pueden autenticarse entre sí, por lo que las aplicaciones no pueden interactuar. Si las aplicaciones de clústeres tienen que interactuar, debe establecer una relación de confianza entre ámbitos entre los clústeres o configurar un clúster como el KDC externo para otros clústeres. Si se establece una confianza entre dominios, estos KDCs deben tener diferentes dominios de Kerberos.
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuario deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse al clúster mediante SSH.
## Relación de confianza entre ámbitos
En esta configuración, las entidades principales (normalmente usuarios) de otro ámbito de Kerberos se autentican para los componentes de la aplicación en un clúster de EMR que utiliza Kerberos y que tiene su propio KDC. El KDC del nodo principal establece una relación de confianza con otro KDC mediante un principal *entre dominios* que existe en ambos. KDCs El nombre y la contraseña de la entidad principal deben coincidir exactamente en cada KDC. Las relaciones de confianza entre ámbitos son más comunes con las implementaciones de Active Directory, tal y como se muestra en el siguiente diagrama. También se admiten relaciones de confianza entre ámbitos con un KDC de MIT externo o un KDC en otro clúster de Amazon EMR.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Ventajas**
+ El clúster de EMR en el que está instalado el KDC mantiene la plena propiedad del KDC.
+ Con Active Directory, Amazon EMR crea automáticamente usuarios de Linux que se corresponden con las entidades principales de usuario del KDC. Aun así, debe crear directorios de HDFS para cada usuario. Además, las entidades principales de usuario del dominio de Active Directory pueden obtener acceso a los clústeres que utilizan Kerberos mediante credenciales de `kinit`, sin el archivo de clave privada de EC2. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.
+ Dado que cada KDC del clúster administra la autenticación de los nodos del clúster, se minimizan los efectos de la latencia de la red y la sobrecarga de procesamiento de un gran número de nodos entre clústeres.
**Consideraciones y limitaciones**
+ Si va a establecer una relación de confianza con un ámbito de Active Directory, debe proporcionar un nombre de usuario y contraseña de Active Directory con permisos para unir entidades principales al dominio al crear el clúster.
+ Las relaciones de confianza entre ámbitos no se pueden establecer entre ámbitos de Kerberos con el mismo nombre.
+ Las relaciones de confianza entre ámbitos deben establecerse de forma explícita. Por ejemplo, si el Clúster A y B establecen una relación de confianza entre ámbitos con un KDC, no confían intrínsecamente uno en el otro y sus aplicaciones no pueden autenticarse entre sí para interaccionar.
+ KDCs debe mantenerse de forma independiente y coordinada para que las credenciales de los principales usuarios coincidan con precisión.
## KDC externo
Las configuraciones con un KDC externo son compatibles con las versiones 5.20.0 y posteriores de Amazon EMR.
+ [KDC externo: KDC de MIT](#emr-kerberos-extkdc-mit-summary)
+ [KDC externo: nodo principal en un clúster diferente](#emr-kerberos-extkdc-cluster-summary)
+ [KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC externo: KDC de MIT
Esta configuración permite que uno o varios clústeres de EMR utilicen entidades principales definidas y mantenidos en un servidor de KDC de MIT.
![\[Amazon EMRclúster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Ventajas**
+ La administración de principales se consolida en un solo KDC.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
+ El nodo principal en un clúster que utiliza Kerberos no tiene la carga de rendimiento asociada con el mantenimiento del KDC.
**Consideraciones y limitaciones**
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal del clúster que tiene Kerberos que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuarios deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse a los clústeres que utilizan Kerberos mediante SSH.
+ Cada nodo de los clústeres de EMR que utilizan Kerberos debe tener una ruta de red al KDC.
+ Cada nodo en los clústeres que utilizan Kerberos impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos en los clústeres que utilizan Kerberos y el KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
### KDC externo: nodo principal en un clúster diferente
Esta configuración es casi idéntica a la implementación de KDC de MIT externo anterior, salvo que el KDC está en el nodo principal de un clúster de EMR. Para obtener más información, consulte [KDC dedicado del clúster (KDC en nodo principal)](#emr-kerberos-localkdc-summary) y [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de 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/es_es/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Ventajas**
+ La administración de principales se consolida en un solo KDC.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
**Consideraciones y limitaciones**
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal del clúster que tiene Kerberos que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuarios deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse a los clústeres que utilizan Kerberos mediante SSH.
+ Cada nodo de cada clúster de EMR debe tener una ruta de red al KDC.
+ Cada nodo de Amazon EMR de los clústeres que utilizan Kerberos impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos de clústeres y el KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
### KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory
En esta configuración, primero se crea un clúster con un KDC dedicado del clúster que tiene una relación de confianza entre ámbitos unidireccional con Active Directory. Para ver un tutorial detallado, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md). A continuación, lance clústeres adicionales, haciendo referencia al KDC del clúster que tiene la relación de confianza con un KDC externo. Para ver un ejemplo, consulta [KDC externo del clúster con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). De este modo, cada clúster de Amazon EMR puede utilizar el KDC externo para autenticar entidades principales definidas y mantenidas en un dominio de Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Ventajas**
+ La administración de entidades principales se consolida en el dominio de Active Directory.
+ Amazon EMR se incorpora al ámbito de Active Directory, lo que elimina la necesidad de crear usuarios de Linux que se correspondan con usuarios de Active Directory. Aun así, debe crear directorios de HDFS para cada usuario.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
+ Las entidades principales de usuarios del dominio de Active Directory pueden acceder a los clústeres que utilizan Kerberos mediante credenciales de `kinit`, sin el archivo de clave privada de EC2. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.
+ Solo un nodo principal de Amazon EMR tiene la carga del mantenimiento del KDC y solo ese clúster debe crearse con credenciales de Active Directory para la relación de confianza entre ámbitos entre el KDC y Active Directory.
**Consideraciones y limitaciones**
+ Cada nodo de cada clúster de EMR debe tener una ruta de red al KDC y el controlador de dominio de Active Directory.
+ Cada nodo de Amazon EMR impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos de los clústeres y el servidor de KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
## Requisitos para utilizar varios clústeres con el mismo KDC
Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Sin embargo, si los clústeres se ejecutan simultáneamente, es posible que se produzcan errores si utilizan ServicePrincipal nombres de Kerberos que entren en conflicto.
Si tiene varios clústeres simultáneos con el mismo KDC externo, asegúrese de que los clústeres utilicen distintos ámbitos de Kerberos. Si los clústeres deben usar el mismo dominio de Kerberos, asegúrese de que estén en subredes diferentes y de que sus rangos de CIDR no se superpongan.
# Configuración de Kerberos en Amazon EMR
En esta sección, se proporcionan detalles y ejemplos de la configuración de Kerberos con arquitecturas comunes. Independientemente de la arquitectura que elija, los aspectos básicos de la configuración son los mismos y se realizan en tres pasos. Si utiliza un KDC externo o configura una relación de confianza entre ámbitos, debe asegurarse de que todos los nodos de un clúster tengan una ruta de red al KDC externo, incluida la configuración de los grupos de seguridad aplicables para permitir el tráfico de entrada y salida de Kerberos.
## Paso 1: Cree una configuración de seguridad con propiedades de Kerberos
La configuración de seguridad especifica detalles sobre el KDC de Kerberos y permite reutilizar la configuración de Kerberos cada vez que se crea un clúster. Puede crear una configuración de seguridad mediante la consola de Amazon EMR AWS CLI, la o la API de EMR. La configuración de seguridad también pueden contener otras opciones de seguridad, como, por ejemplo, el cifrado. Para obtener más información acerca de la creación y especificación de las configuraciones de seguridad cuando se crea un clúster, consulte [Uso de configuraciones de seguridad para configurar la seguridad del clúster de Amazon EMR](emr-security-configurations.md). Para obtener más información acerca de las propiedades de Kerberos en una configuración de seguridad, consulte [Configuración de Kerberos para las configuraciones de seguridad](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Paso 2: Cree un clúster y especifique los atributos de Kerberos específicos del clúster
Al crear un clúster, especifique la configuración de seguridad de Kerberos junto con las opciones de Kerberos específicas del clúster. Cuando utilice la consola de Amazon EMR, solo están disponibles las opciones de Kerberos compatibles con la configuración de seguridad especificada. Cuando utilice la AWS CLI API de Amazon EMR, asegúrese de especificar las opciones de Kerberos compatibles con la configuración de seguridad especificada. Por ejemplo, si especifica la contraseña de la entidad principal para una relación de confianza entre ámbitos al crear un clúster mediante la CLI y la configuración de seguridad especificada no tiene parámetros de relación de confianza entre ámbitos, se produce un error. Para obtener más información, consulte [Configuración de Kerberos para clústeres](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Paso 3: configure el nodo principal del clúster
En función de los requisitos de su arquitectura e implementación, es posible que sea necesario realizar una configuración adicional en el clúster. Puede hacer esto después de crearla o mediante pasos o acciones de arranque durante el proceso de creación.
Para cada usuario autenticado de Kerberos que se conecte al clúster utilizando SSH, debe asegurarse de que se crean cuentas de Linux que se corresponden con el usuario de Kerberos. Si el controlador de dominio de Active Directory proporciona las entidades principales de usuario, ya sea como el KDC externo o a través de una relación de confianza entre ámbitos, Amazon EMR crea cuentas de usuario de Linux de forma automática. Si no se utiliza Active Directory, debe crear entidades principales para cada usuario que se correspondan con su usuario de Linux. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
Cada usuario también debe tener un directorio de usuarios de HDFS propio que debe crear usted. Además, SSH debe estar configurado con GSSAPI habilitado para permitir conexiones de los usuarios autenticados por Kerberos. GSSAPI debe estar habilitado en el nodo principal y se debe configurar la aplicación SSH del cliente para que utilice GSSAPI. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
# Configuración de seguridad y configuración de clústeres para Kerberos en Amazon EMR
Al crear un clúster que utiliza Kerberos, debe especificar la configuración de seguridad junto con los atributos de Kerberos específicos para el clúster. No puede especificar un conjunto sin el otro, o se producirá un error.
En este tema, se ofrece información general de los parámetros de configuración disponibles para Kerberos al crear una configuración de seguridad y un clúster. Además, se proporcionan ejemplos de CLI para crear configuraciones de seguridad compatibles y clústeres para arquitecturas comunes.
## Configuración de Kerberos para las configuraciones de seguridad
Puede crear una configuración de seguridad que especifique los atributos de Kerberos mediante la consola Amazon EMR, AWS CLI la o la API EMR. La configuración de seguridad también pueden contener otras opciones de seguridad, como, por ejemplo, el cifrado. Para obtener más información, consulte [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
Utilice las siguientes referencias para conocer las opciones de configuración de seguridad disponibles para la arquitectura Kerberos que elija. Se muestra la configuración de la consola de Amazon EMR. Para ver las opciones de la CLI correspondientes, consulte [Especificar la configuración de Kerberos mediante AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) o [Ejemplos de configuraciones](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Configuración de Kerberos para clústeres
Puede especificar la configuración de Kerberos al crear un clúster mediante la consola Amazon EMR, la API EMR o AWS CLI la API EMR.
Utilice las siguientes referencias para conocer las opciones de configuración de clústeres disponibles para la arquitectura Kerberos que elija. Se muestra la configuración de la consola de Amazon EMR. Para ver las opciones de la CLI correspondientes, consulte [Ejemplos de configuraciones](emr-kerberos-config-examples.md).
| Parámetro | Description (Descripción) |
| --- | --- |
| Ámbito | El nombre del ámbito de Kerberos para el clúster. La convención de Kerberos consiste en establecerlo igual que el nombre del dominio, pero en mayúsculas. Por ejemplo, para el dominio `ec2.internal`, se utiliza `EC2.INTERNAL` como nombre de ámbito. |
| Contraseña de administración de KDC | La contraseña utilizada en el clúster `kadmin` o `kadmin.local`. Son interfaces de línea de comandos para el sistema de administración de Kerberos V5, que mantiene las entidades principales, las políticas de contraseñas y las tablas de claves de Kerberos para el clúster. |
| Contraseña de la entidad principal de confianza entre ámbitos (opcional) | Es necesaria para establecer una confianza entre ámbitos. La contraseña de la entidad principal de confianza entre ámbitos, que debe ser idéntica en los distintos ámbitos. Use una contraseña segura. |
| Usuario de incorporación al dominio de Active Directory (opcional) | Obligatorio cuando se utiliza Active Directory en una relación de confianza entre ámbitos. Se trata de un nombre de inicio de sesión de usuario de una cuenta de Active Directory con permisos para incorporar equipos al dominio. Amazon EMR utiliza esta identidad para incorporar el clúster al dominio. Para obtener más información, consulte [Paso 3: adición de cuentas al dominio para el clúster de EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Contraseña de incorporación al dominio de Active Directory (opcional) | La contraseña del usuario de incorporación a un dominio de Active Directory. Para obtener más información, consulte [Paso 3: adición de cuentas al dominio para el clúster de EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Ejemplos de configuraciones
Los siguientes ejemplos muestran las configuraciones de seguridad y las configuraciones de clúster para escenarios comunes. AWS CLI los comandos se muestran por motivos de brevedad.
## KDC local
Los siguientes comandos crean un clúster con un KDC dedicado del clúster que se ejecuta en el nodo principal. Es necesario realizar una configuración adicional en el clúster. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
**Crear configuración de seguridad**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Crear un clúster**
```
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 dedicado del clúster con una relación de confianza entre ámbitos de Active Directory
Los siguientes comandos crean un clúster con un KDC dedicado del clúster que se ejecuta en el nodo principal con una relación de confianza entre ámbitos con un dominio de Active Directory. Se necesita realizar configuración adicional en el clúster y en Active Directory. Para obtener más información, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md).
**Crear configuración de seguridad**
```
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"}}}}}'
```
**Crear un clúster**
```
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 externo en un clúster diferente
Los siguientes comandos crean un clúster que hace referencia a un KDC dedicado del clúster en el nodo principal de un clúster diferente para autenticar entidades principales. Es necesario realizar una configuración adicional en el clúster. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
**Crear configuración de seguridad**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Crear un clúster**
```
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 externo del clúster con una relación de confianza entre ámbitos de Active Directory
Los siguientes comandos crean un clúster sin KDC. El clúster hace referencia a un KDC dedicado del clúster que se ejecuta en el nodo principal de otro clúster para autenticar entidades principales. Esa KDC posee una relación de confianza entre ámbitos con un controlador de dominio de Active Directory. Es necesario realizar una configuración adicional en el nodo principal con el KDC. Para obtener más información, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md).
**Crear configuración de seguridad**
```
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"}}}}}'
```
**Crear un clúster**
```
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
```
# Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos
Amazon EMR crea clientes de usuario autenticados por Kerberos para las aplicaciones que se ejecutan en el clúster; por ejemplo, el usuario `hadoop`, el usuario `spark` y otros. También puede añadir usuarios autenticados a los procesos del clúster mediante Kerberos. Luego, los usuarios autenticados pueden conectarse al clúster con sus credenciales de Kerberos y trabajar con aplicaciones. Para que un usuario pueda autenticarse en el clúster, es necesario realizar las siguientes configuraciones:
+ En el clúster debe existir una cuenta de Linux que coincida con la entidad principal de Kerberos en el KDC. Amazon EMR lo hace automáticamente en arquitecturas que se integran con Active Directory.
+ Debe crear un directorio de usuarios de HDFS en el nodo principal para cada usuario y proporcionar permisos de usuario al directorio.
+ Debe configurar el servicio SSH para que GSSAPI esté habilitado en el nodo principal. Además, los usuarios deben tener un cliente SSH con GSSAPI habilitado.
## Adición de usuarios de Linux y entidades principales de Kerberos al nodo principal
Si no utiliza Active Directory, debe crear las cuentas de Linux en el nodo principal del clúster y agregar entidades principales para estos usuarios de Linux al KDC. Esto incluye una entidad principal en el KDC para el nodo principal. Además de las entidades principales de usuarios, el KDC que se ejecuta en el nodo principal necesita una entidad principal para el host local.
Cuando la arquitectura incluye integración con Active Directory, los usuarios y entidades principales de Linux en el KDC local, si procede, se crean automáticamente. Puede omitir este paso. Para obtener más información, consulte [Relación de confianza entre ámbitos](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) y [KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**importante**
El KDC, junto con la base de datos de entidades principales, se pierde cuando el nodo principal termina porque el nodo principal utiliza almacenamiento efímero. Si crea usuarios para las conexiones SSH, le recomendamos que establezca una relación de confianza entre dominios con un KDC externo configurado para lograr una alta disponibilidad. Como alternativa, si crea usuarios para las conexiones SSH mediante cuentas de Linux, automatice el proceso de creación de cuentas mediante acciones y scripts de arranque para que pueda repetirse al crear un clúster nuevo.
La manera más sencilla de añadir usuarios y entidades principales de KDC es enviar un paso al clúster después de crearlo o al crear el clúster. Si lo prefiere, puede conectarse al nodo principal utilizando un par de claves de EC2 como el usuario predeterminado `hadoop` para ejecutar los comandos. Para obtener más información, consulte [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md).
En el siguiente ejemplo, se envía un script bash `configureCluster.sh` a un clúster que ya existe, especificando su ID de clúster. El script se almacena en 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"]
```
El siguiente ejemplo muestra el contenido del script `configureCluster.sh`. El script también se encarga de la creación de los directorios de usuario de HDFS y de habilitar GSSAPI para SSH, lo que se explica en las siguientes secciones.
```
#!/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
```
## Adición de directorios de HDFS de usuarios
Para permitir a los usuarios iniciar sesión en el clúster para ejecutar los trabajos de Hadoop, debe agregar directorios de usuario de HDFS para sus cuentas de Linux y conceder a cada usuario la propiedad de su directorio.
La manera más sencilla de crear directorios de HDFS es enviar un paso al clúster después de crearlo o al crear el clúster. Si lo prefiere, podría conectarse al nodo principal utilizando un par de claves de EC2 como el usuario predeterminado `hadoop` para ejecutar los comandos. Para obtener más información, consulte [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md).
En el siguiente ejemplo, se envía un script bash `AddHDFSUsers.sh` a un clúster que ya existe, especificando su ID de clúster. El script se almacena en 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"]
```
El siguiente ejemplo muestra el contenido del 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
```
## Habilitación de GSSAPI para SSH
Para que los usuarios autenticados por Kerberos se conecten al nodo principal mediante SSH, el servicio SSH debe tener habilitada la autenticación de GSSAPI. Para habilitar GSSAPI, ejecute los siguientes comandos desde la línea de comandos del nodo principal o utilice un paso para ejecutarlo como un script. Después de volver a configurar SSH, reinicie el servicio.
```
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
```
# Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR
En esta sección, se muestran los pasos para que un usuario autenticado por Kerberos se conecte al nodo principal de un clúster de EMR.
Cada equipo que se utiliza para una conexión SSH debe tener instalados un cliente SSH y aplicaciones de cliente de Kerberos. Lo más probable es que los equipos Linux los incluyan de forma predeterminada. Por ejemplo, OpenSSH está instalado en la mayoría de los sistemas operativos Linux, Unix y macOS. Puede comprobar si tiene un cliente SSH escribiendo **ssh** en la línea de comandos. Si su equipo no reconoce el comando, instale un cliente SSH para conectarse al nodo principal. El proyecto OpenSSH ofrece una implementación gratuita de toda la suite de herramientas de SSH. Para obtener más información, consulte el sitio web [OpenSSH](http://www.openssh.org/). Los usuarios de Windows pueden utilizar aplicaciones como [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) como cliente SSH.
Para obtener más información sobre las conexiones SSH persistentes, use [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
SSH utiliza GSSAPI para autenticar a los clientes de Kerberos y debe habilitar la autenticación de GSSAPI para el servicio SSH en el nodo principal del clúster. Para obtener más información, consulte [Habilitación de GSSAPI para SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Los clientes SSH también deben utilizar GSSAPI.
En los siguientes ejemplos, *MasterPublicDNS* utilice el valor que aparece para el **DNS público maestro** en la pestaña **Resumen** del panel de detalles del clúster, por ejemplo,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Requisito previo para krb5.conf (sin Active Directory)
Cuando se utiliza una configuración sin integración con Active Directory, además del cliente SSH y las aplicaciones de cliente de Kerberos, cada equipo cliente debe tener una copia del archivo `/etc/krb5.conf` que coincida con el archivo `/etc/krb5.conf` en el nodo principal del clúster.
**Para copiar el archivo krb5.conf**
1. Utilice SSH para conectarse al nodo principal mediante un par de claves de EC2 y el usuario `hadoop`predeterminado, por ejemplo, `hadoop@MasterPublicDNS`. Para obtener instrucciones detalladas, consulte [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
1. Desde el nodo principal, copie el contenido del archivo `/etc/krb5.conf`. Para obtener más información, consulte [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
1. En cada equipo cliente que se utilice para conectarse al clúster, cree un archivo `/etc/krb5.conf` idéntico a partir de la copia que hizo en el paso anterior.
## Uso de kinit y SSH
Cada vez que un usuario se conecta desde un equipo cliente con credenciales de Kerberos, el usuario debe renovar primero los tickets de Kerberos para su usuario en el equipo cliente. Además, se debe configurar el cliente SSH para utilizar la autenticación GSSAPI.
**Para utilizar SSH para conectarse a un clúster de EMR que utilice Kerberos**
1. Utilice `kinit` para renovar sus tickets de Kerberos, como se muestra en el siguiente ejemplo
```
kinit user1
```
1. Utilice un cliente `ssh` junto con la entidad principal que creó en el KDC dedicado del clúster o el nombre de usuario de Active Directory. Asegúrese de que la autenticación GSSAPI está habilitada, tal y como se muestra en los siguientes ejemplos.
**Ejemplo: usuarios de Linux**
La opción `-K `especifica la autenticación GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Ejemplo: usuarios de Windows (PuTTY)**
Asegúrese de que la opción de autenticación GSSAPI de la sesión está habilitada, tal y como se muestra:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: Configuración de un KDC dedicado del clúster con Amazon EMR
En este tema, le enseñaremos cómo crear un clúster con un *centro de distribución de claves (KDC)* dedicado, cómo agregar manualmente cuentas de usuario de Linux a todos los nodos del clúster, cómo agregar entidades principales de Kerberos al KDC en el nodo principal y cómo asegurarse de que los equipos cliente tengan instalado un cliente de Kerberos.
Para obtener más información sobre la compatibilidad de Amazon EMR con Kerberos y KDC, así como enlaces a la documentación de Kerberos del MIT, consulte [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md).
## Paso 1: creación del clúster que utiliza Kerberos
1. Cree una configuración de seguridad que habilite Kerberos. En el siguiente ejemplo, se muestra un `create-security-configuration` comando que utiliza el AWS CLI que especifica la configuración de seguridad como una estructura JSON en línea. También puede hacer referencia a un archivo guardado de forma local.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Cree un clúster que haga referencia a la configuración de seguridad, establezca los atributos de Kerberos para el clúster y añada las cuentas de Linux mediante una acción de arranque. El siguiente ejemplo muestra el uso de un comando `create-cluster `en la AWS CLI. El comando hace referencia a la configuración de seguridad que se ha creado anteriormente, `MyKerberosConfig`. También hace referencia a un script sencillo, `createlinuxusers.sh`, como acción de arranque, que debe crear y cargar en Amazon S3 antes de crear el clúster.
```
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
```
El siguiente código ilustra el contenido del script `createlinuxusers.sh`, que agrega user1, user2 y user3 en cada nodo del clúster. En el siguiente paso, añadirá estos usuarios como entidades principales de KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Paso 2: adición de entidades principales al KDC, creación directorios de usuarios de HDFS y configuración de SSH
En el KDC que se ejecuta en el nodo principal, se debe agregar una entidad principal para el host local y para cada usuario que se cree en el clúster. También puede crear directorios de HDFS para cada usuario en caso de que necesitan conectarse al clúster y ejecutar trabajos de Hadoop. Del mismo modo, configurae el servicio SSH para activar la autenticación GSSAPI, que es necesaria para Kerberos. Después de habilitar GSSAPI, reinicie el servicio SSH.
La forma más sencilla de realizar estas tareas es enviar un paso para el clúster. El siguiente ejemplo envía un script bash `configurekdc.sh` al clúster que ha creado en el paso anterior, haciendo referencia a su ID de clúster. El script se almacena en Amazon S3. De forma alternativa, puede conectarse al nodo principal utilizando un par de claves de EC2 para ejecutar los comandos o enviar el paso durante la creación del clúster.
```
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"]
```
El siguiente código muestra el contenido del 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
```
Los usuarios que ha añadido ahora deberían ser capaces de conectarse al clúster mediante SSH. Para obtener más información, consulte [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory
Al crear una relación de confianza entre ámbitos, se permite a las entidades principales (normalmente usuarios) de otro ámbito de Kerberos autenticar a los componentes de la aplicación en el clúster de EMR. El *centro de distribución de claves (KDC)* dedicado al clúster establece una relación de confianza con otro KDC mediante un principio *multidominio* que existe en ambos. KDCs El nombre y la contraseña de la entidad principal deben coincidir exactamente.
Una relación de confianza entre ámbitos requiere que los KDC puedan tener acceso entre sí a través de la red y resolver sus nombres de dominio. Pasos para establecer una relación de confianza con un ámbito Microsoft AD controlador de dominio se ejecutan como una instancia de EC2 se suministran a continuación, junto con un ejemplo de configuración de red que proporciona la conectividad y la resolución de nombres de dominio. Se acepta cualquier configuración de red que permita el tráfico de red necesario entre ellos. KDCs
Opcionalmente, después de establecer una relación de confianza entre ámbitos con Active Directory utilizando un KDC en un clúster, puede crear otro clúster con una configuración de seguridad diferente para hacer referencia al KDC en el primer clúster como un KDC externo. Para ver un ejemplo de la configuración de seguridad y la configuración del clúster, consulte [KDC externo del clúster con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Para obtener más información sobre la compatibilidad de Amazon EMR con Kerberos y KDC, así como enlaces a la documentación de Kerberos del MIT, consulte [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md).
**importante**
Amazon EMR no admite fideicomisos entre dominios con. AWS Directory Service for Microsoft Active Directory
[Paso 1: Configuración de la VPC y la subred](#emr-kerberos-ad-network)
[Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory](#emr-kerberos-ad-dc)
[Paso 3: adición de cuentas al dominio para el clúster de EMR](#emr-kerberos-ad-users)
[Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory](#emr-kerberos-ad-configure-trust)
[Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC](#emr-kerberos-ad-DHCP)
[Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster)
[Paso 7: creación de usuarios de HDFS y configuración de permisos en el clúster para las cuentas de usuario de Active Directory](#emr-kerberos-ad-hadoopuser)
## Paso 1: Configuración de la VPC y la subred
Los pasos siguientes muestran cómo crear una VPC y una subred para que el KDC dedicado del clúster pueda tener acceso al controlador de dominio de Active Directory y resolver su nombre de dominio. En estos pasos, la resolución de nombres de dominio se proporciona haciendo referencia al controlador de dominio de Active Directory como el servidor de nombres de dominio en el conjunto de opciones de DHCP. Para obtener más información, consulte [Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC](#emr-kerberos-ad-DHCP).
El KDC y el controlador de dominio de Active Directory deben ser capaces de resolver sus respectivos nombres de dominio. Esto permite a Amazon EMR incorporar equipos al dominio y configurar automáticamente las cuentas de Linux y los parámetros de SSH correspondientes en las instancias de clúster.
Si Amazon EMR no puede resolver el nombre de dominio, se puede hacer referencia a la relación de confianza mediante la dirección IP del controlador de dominio de Active Directory. Sin embargo, debe agregar manualmente las cuentas de usuario de Linux, agregar las correspondientes entidades principales al KDC dedicado del clúster y configurar SSH.
**Para configurar la VPC y la subred**
1. Cree una instancia de Amazon VPC con una única subred pública. Para obtener más información, consulte [Paso 1: creación de la VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) en la *Guía de introducción a Amazon VPC*.
**importante**
Cuando utilice un controlador de dominio de Microsoft Active Directory, elija un bloque CIDR para el clúster de EMR de modo que IPv4 todas las direcciones tengan menos de nueve caracteres (por ejemplo, 10.0.0.0/16). Esto se debe a que los nombres DNS de los equipos del clúster se utilizan cuando los equipos se unen al directorio de Active Directory. AWS asigna [nombres de host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) en función de la IPv4 dirección, de manera que las direcciones IP más largas pueden dar como resultado nombres DNS de más de 15 caracteres. Active Directory tiene un límite de 15 caracteres para registrar los nombres de los equipos que se incorporan, y trunca los nombres que son más largos, lo que puede provocar errores impredecibles.
1. Elimine el conjunto de opciones de DHCP predeterminado asignado a la VPC. Para obtener más información, consulte [Cambiar una VPC para que no utilice ninguna opción de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Posteriormente, puede añadir uno nuevo que especifique el controlador de dominio de Active Directory como servidor DNS.
1. Confirme que se ha activado el soporte de DNS para la VPC, es decir, que se han activado los nombres de host DNS y la resolución de DNS. De forma predeterminada, están habilitadas. Para obtener más información, consulte [Actualización de la compatibilidad de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Confirme que la VPC tiene un asociada una gateway de Internet, que es la opción predeterminada. Para obtener más información, consulte [Creación y asociación de una gateway de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**nota**
En este ejemplo, se utiliza una gateway de Internet porque se está estableciendo un nuevo controlador de dominio para la VPC. Puede que no sea necesaria una gateway de Internet para su aplicación. El único requisito es que el KDC dedicado del clúster pueda tener acceso al controlador de dominio de Active Directory.
1. Cree una tabla de ruteo personalizada, añada una ruta que se dirija a la gateway de Internet y, a continuación, asóciela a la subred. Para obtener más información, consulte [Creación de una tabla de enrutamiento personalizada](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Al lanzar la instancia EC2 para el controlador de dominio, debe tener una IPv4 dirección pública estática para que pueda conectarse a ella mediante RDP. La forma más sencilla de hacerlo es configurar la subred para que asigne automáticamente direcciones públicas IPv4 . Este no es el valor predeterminado cuando se crea una subred. Para obtener más información, consulte [Modificación del atributo de IPv4 direccionamiento público de la subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si lo prefiere, puede asignar la dirección al lanzar la instancia. Para obtener más información, consulta Cómo [asignar una IPv4 dirección pública durante el lanzamiento de una instancia](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Cuando termine, anote la VPC y la subred. IDs Los utilizará posteriormente al lanzar el controlador de dominio de Active Directory y el clúster.
## Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory
1. Lance una instancia de EC2 basada en la AMI base de Microsoft Windows Server 2016. Le recomendamos un tipo de instancia m4.xlarge o mejor. Para obtener más información, consulte [Lanzamiento de una instancia AWS Marketplace](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) en la *Guía del usuario de Amazon EC2*.
1. Anote el Group ID (ID de grupo) del grupo de seguridad asociado a la instancia EC2. Lo necesitará para [Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster). Usamos. *sg-012xrlmdomain345* También puede especificar distintos grupos de seguridad para el clúster de EMR y esta instancia que permita el tráfico entre ellos. Para obtener más información, consulte [Grupos de seguridad de Amazon EC2 para instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) en la *Guía del usuario de Amazon EC2*.
1. Conéctese a la instancia de EC2 a través de RDP. Para obtener más información, consulte [Conexión a su instancia de Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) en la *Guía del usuario de Amazon EC2*.
1. Inicie **Administrador del servidor** para instalar y configurar el rol de los servicios de dominio de Active Directory en el servidor. Promocione el servidor a controlador de dominio y asígnele un nombre de dominio (el ejemplo que utilizamos aquí es `ad.domain.com`). Anote el nombre de dominio porque lo necesitará más adelante al crear el clúster y la configuración de seguridad de EMR. Si es la primera vez que configura Active Directory, puede seguir las instrucciones de [How to Set Up Active Directory (AD) in Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
La instancia se reiniciará cuando termine.
## Paso 3: adición de cuentas al dominio para el clúster de EMR
Establezca una conexión RDP con el controlador de dominio de Active Directory para crear cuentas de usuario en Usuarios y equipos de Active Directory para cada usuario del clúster. Para obtener más información, consulte [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) en el sitio *Microsoft Learn*. Anote el **User logon name (Nombre de inicio de sesión de usuario)** de cada usuario. Necesitas estas versiones posteriores al configurar el clúster.
Cree también una cuenta con privilegios suficientes para incorporar ordenadores al dominio. Tiene que especificar esta cuenta al crear un clúster. Amazon EMR la utiliza para incorporar las instancias del clúster al dominio Solo debe especificar esta cuenta y su contraseña [Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster). Para delegar los privilegios de incorporación de equipos a la cuenta, le recomendamos que cree un grupo con privilegios de incorporación y, a continuación, asigne el usuario al grupo. Para obtener instrucciones, consulte [Delegación de privilegios de vinculación a directorios](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) en la *Guía de administración de AWS Directory Service *.
## Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory
Los comandos del ejemplo siguiente crean una relación de confianza en Active Directory, que es una confianza de ámbito, entrante, unidireccional y no transitiva con el KDC dedicado del clúster. El ejemplo que utilizamos para el ámbito del clúster es `EC2.INTERNAL`. Sustituya el *KDC-FQDN* nombre de **DNS público** que aparece en la lista para el nodo principal de Amazon EMR que aloja el KDC. El parámetro `passwordt` especifica la **cross-realm principal password (contraseña de la entidad principal de confianza entre ámbitos)**, que se especifica junto con el **realm (ámbito)** del clúster al crear un clúster. El nombre del ámbito se deriva del nombre de dominio predeterminado en `us-east-1` para el clúster. El `Domain` es el dominio de Active Directory en el que va a crear la confianza, que es en minúsculas por convención. El ejemplo utiliza `ad.domain.com`
Abra el símbolo del sistema de Windows con privilegios de administrador y escriba los siguientes comandos para crear la relación de confianza en el controlador de dominio de 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
```
## Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC
Ahora que está configurado el controlador de dominio de Active Directory, debe configurar la VPC para utilizarla como servidor de nombres de dominio para la resolución de nombres en la VPC. Para ello, asocie un conjunto de opciones de DHCP. En **Nombre de dominio**, especifique el nombre de dominio del clúster; por ejemplo, `ec2.internal` si el clúster se encuentra en la región us-east-1 o `region.compute.internal` para las demás regiones. En el caso de **los servidores de nombres de dominio**, debe especificar la dirección IP del controlador de dominio de Active Directory (al que se debe poder acceder desde el clúster) como primera entrada, seguida del **AmazonProvidedDNS** (por ejemplo ***xx.xx.xx.xx*, AmazonProvided** DNS). Para obtener más información, consulte [Cambio de los conjuntos de opciones de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Paso 6: Lanzar un clúster de EMR que utiliza Kerberos
1. En Amazon EMR, cree una configuración de seguridad que especifique el controlador de dominio de Active Directory que ha creado en los pasos anteriores. A continuación se muestra un ejemplo. Sustituya el dominio, `ad.domain.com`por el nombre del dominio especificado en el [Paso 2: lanzamiento e instalación del controlador de dominio de 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. Cree el clúster con los siguientes atributos:
+ Utilice la opción `--security-configuration` para especificar la configuración de seguridad que ha creado. Usamos *MyKerberosConfig* en el ejemplo.
+ Utilice la propiedad `SubnetId` de `--ec2-attributes option` para especificar la subred que ha creado en [Paso 1: Configuración de la VPC y la subred](#emr-kerberos-ad-network). Usamos *step1-subnet* en el ejemplo.
+ Utilice `AdditionalMasterSecurityGroups` y `AdditionalSlaveSecurityGroups` de la opción `--ec2-attributes` para especificar que el grupo de seguridad asociado al controlador de dominio de AD desde [Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory](#emr-kerberos-ad-dc) está asociado al nodo principal del clúster, así como a los nodos secundarios y de tareas. Usamos *sg-012xrlmdomain345* en el ejemplo.
Utilice `--kerberos-attributes` para especificar los siguientes atributos de Kerberos específicos del clúster:
+ El ámbito para el clúster que especificó al configurar el controlador de dominio de Active Directory.
+ La contraseña de la entidad principal de confianza entre ámbitos que especificó como `passwordt` en el [Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory](#emr-kerberos-ad-configure-trust).
+ Una `KdcAdminPassword`, que se puede utilizar para administrar el KDC dedicado del clúster.
+ El nombre de inicio de sesión de usuario y la contraseña de la cuenta de Active Directory con privilegios para incorporar equipos que ha creado en el [Paso 3: adición de cuentas al dominio para el clúster de EMR](#emr-kerberos-ad-users).
El siguiente ejemplo lanza un clúster que utiliza 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
```
## Paso 7: creación de usuarios de HDFS y configuración de permisos en el clúster para las cuentas de usuario de Active Directory
Cuando se configura una relación de confianza con Active Directory, Amazon EMR crea usuarios de Linux en el clúster para cada cuenta de usuario de Active Directory. Por ejemplo, el nombre de inicio de sesión de usuario `LiJuan` en Active Directory se corresponde con la cuenta de Linux de `lijuan`. Los nombres de usuario de Active Directory pueden contener letras mayúsculas, pero Linux no distingue entre mayúsculas y minúsculas para dichos nombres.
Para permitir a los usuarios iniciar sesión en el clúster para ejecutar los trabajos de Hadoop, debe agregar directorios de usuario de HDFS para sus cuentas de Linux y conceder a cada usuario la propiedad de su directorio. Para ello, le recomendamos que ejecute un script almacenado en Amazon S3 como un paso de clúster. De forma alternativa, puede ejecutar los comandos en el script siguiente desde la línea de comandos en el nodo principal. Utilice el par de claves de EC2 especificado al crear el clúster para conectarse al nodo principal a través de SSH como usuario de Hadoop. Para obtener más información, consulte [Use un par de claves de EC2 para credenciales de SSH para Amazon EMR](emr-plan-access-ssh.md).
Ejecute el siguiente comando para añadir un paso al clúster que ejecuta 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"]
```
El contenido del archivo *AddHDFSUsers.sh* es el siguiente.
```
#!/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
```
### Grupos de Active Directory asignados a grupos de Hadoop
Amazon EMR utiliza System Security Services Daemon (SSD) para asignar grupos de Active Directory a grupos de Hadoop. Para confirmar las asignaciones de grupos, después de iniciar sesión en el nodo principal tal y como se describe en [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md), puede utilizar el comando `hdfs groups` para confirmar que los grupos de Active Directory a los que pertenece su cuenta de Active Directory se han asignado a los grupos de Hadoop del usuario de Hadoop correspondiente en el clúster. También puede comprobar los mapeos de grupos de otros usuarios especificando uno o varios nombres de usuario con el comando, por ejemplo `hdfs groups lijuan`. Para obtener más información, consulte [groups](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) en la [Apache HDFS Commands Guide](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Uso de servidores de Active Directory o LDAP para la autenticación con Amazon EMR
Con las versiones 6.12.0 y posteriores de Amazon EMR, puede utilizar el protocolo LDAP sobre SSL (LDAPS) para lanzar un clúster que se integre de forma nativa con su servidor de identidad corporativa. El LDAP (protocolo ligero de acceso a directorios) es un protocolo de aplicaciones abierto e independiente del proveedor que accede a los datos y los mantiene. El LDAP se utiliza habitualmente para la autenticación de usuarios en servidores de identidad corporativa alojados en aplicaciones como Active Directory (AD) y OpenLDAP. Con esta integración nativa, puede usar su servidor LDAP para autenticar a los usuarios en Amazon EMR.
Entre los aspectos destacados de la integración del LDAP de Amazon EMR se encuentran los siguientes:
+ Amazon EMR configura las aplicaciones compatibles para que se autentiquen con la autenticación LDAP en su nombre.
+ Amazon EMR configura y mantiene la seguridad de las aplicaciones compatibles con el protocolo Kerberos. No es necesario introducir ningún comando o script.
+ Se obtiene un control de acceso detallado (FGAC) mediante la autorización de Apache Ranger para las bases de datos y tablas del metaalmacén de Hive. Para obtener más información, consulte [Integración de Amazon EMR con Apache Ranger](emr-ranger.md).
+ Cuando necesita credenciales del LDAP para acceder a un clúster, obtiene un control de acceso detallado (FGAC) sobre quién puede acceder a sus clústeres de EMR a través de SSH.
En las siguientes páginas se proporciona información general conceptual, los requisitos previos y los pasos para lanzar un clúster de EMR con la integración del LDAP de Amazon EMR.
**Topics**
+ [Descripción general del LDAP con Amazon EMR](ldap-overview.md)
+ [Componentes del LDAP para Amazon EMR](ldap-components.md)
+ [Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR](ldap-considerations.md)
+ [Configuración y lanzamiento de un clúster de EMR con el LDAP](ldap-setup.md)
+ [Ejemplos de uso del LDAP con Amazon EMR](ldap-examples.md)
# Descripción general del LDAP con Amazon EMR
El protocolo ligero de acceso a directorios (LDAP) es un protocolo de software que los administradores de red utilizan para administrar y controlar el acceso a los datos mediante la autenticación de los usuarios dentro de la red de una empresa. El protocolo LDAP almacena la información en una estructura jerárquica de directorios en árbol. Para obtener más información, consulte [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/) en *LDAP.com*.
Dentro de la red de una empresa, muchas aplicaciones pueden utilizar el protocolo LDAP para autenticar a los usuarios. Con la integración del LDAP de Amazon EMR, los clústeres de EMR pueden utilizar de forma nativa el mismo protocolo LDAP con una configuración de seguridad adicional.
Amazon EMR admite dos implementaciones principales del protocolo LDAP: **Active Directory** y **OpenLDAP**. Si bien son posibles otras implementaciones, la mayoría se ajusta a los mismos protocolos de autenticación que Active Directory u OpenLDAP.
## Active Directory (AD)
Active Directory (AD) es un servicio de directorios de Microsoft para redes de dominio de Windows. AD está incluido en la mayoría de los sistemas operativos Windows Server y puede comunicarse con los clientes a través de los protocolos LDAP y LDAPS. Amazon EMR intenta vincular un usuario a su instancia de AD con el nombre principal del usuario (UPN) como nombre distintivo y la contraseña para realizar la autenticación. El UPN utiliza el formato estándar `username@domain_name`.
## OpenLDAP
OpenLDAP es una implementación gratuita y de código abierto del protocolo LDAP. Para la autenticación, Amazon EMR intenta vincular un usuario a su instancia de OpenLDAP con el nombre de dominio completo (FQDN) como nombre distintivo y la contraseña. El FQDN utiliza el formato estándar `username_attribute=username,LDAP_user_search_base`. Por lo general, el valor `username_attribute` es `uid` y el valor `LDAP_user_search_base` contiene los atributos del árbol que conduce al usuario. Por ejemplo, `ou=People,dc=example,dc=com`.
Otras implementaciones gratuitas y de código abierto del protocolo LDAP suelen seguir un FQDN similar al de OpenLDAP para los nombres distintivos de sus usuarios.
# Componentes del LDAP para Amazon EMR
Puede usar su servidor LDAP para autenticarse con Amazon EMR y cualquier aplicación que el usuario utilice directamente en el clúster de EMR a través de los siguientes componentes.
**Agente secreto**
El *agente secreto* es un proceso que se ejecuta en el clúster que autentica todas las solicitudes de los usuarios. El agente secreto crea el enlace de usuario a su servidor LDAP en nombre de las aplicaciones compatibles en el clúster de EMR. El agente secreto se ejecuta como el usuario `emrsecretagent` y escribe registros en el directorio `/emr/secretagent/log`. Estos registros proporcionan detalles sobre el estado de la solicitud de autenticación de cada usuario y cualquier error que pueda surgir durante la autenticación del usuario.
**System Security Services Daemon (SSSD)**
*SSSD* es un daemon que se ejecuta en cada nodo de un clúster de EMR habilitado para el LDAP. SSSD crea y administra un usuario de UNIX para sincronizar su identidad corporativa remota con cada nodo. Las aplicaciones basadas en YARN, como Hive y Spark, requieren que haya un usuario local de UNIX en cada nodo que ejecute una consulta para un usuario.
# Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR
En este tema se enumeran las aplicaciones compatibles, las características compatibles y las características no compatibles.
## Aplicaciones compatibles con el LDAP para Amazon EMR
**importante**
Las aplicaciones que aparecen en esta página son las únicas aplicaciones que Amazon EMR admite para el LDAP. Para garantizar la seguridad del clúster, solo puede incluir aplicaciones compatibles con el LDAP al crear un clúster de EMR con el LDAP habilitado. Si intenta instalar otras aplicaciones no compatibles, Amazon EMR rechazará su solicitud de un nuevo clúster.
Las versiones 6.12 y posteriores de Amazon EMR admiten la integración del LDAP con las siguientes aplicaciones:
+ Apache Livy
+ Desde Apache Hive hasta HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
También puede instalar las siguientes aplicaciones en un clúster de EMR y configurarlas para que se ajusten a sus necesidades de seguridad:
+ Apache Spark
+ Apache Hadoop
## Características compatibles con el LDAP para Amazon EMR
Puede utilizar las siguientes características de Amazon EMR con la integración del LDAP:
**nota**
Para mantener seguras las credenciales del LDAP, debe utilizar el cifrado en tránsito para proteger el flujo de datos dentro y fuera del clúster. Para obtener más información sobre el cifrado en tránsito, consulte [Cifrar datos en reposo y en tránsito con Amazon EMR](emr-data-encryption.md).
+ Cifrado en reposo y en tránsito (obligatorio)
+ Grupos de instancias, flotas de instancias e instancias de spot
+ Reconfiguración de aplicaciones en un clúster en ejecución
+ Cifrado del servidor (SSE) de EMRFS
## Características no admitidas
Tenga en cuenta las siguientes limitaciones cuando utilice la integración del LDAP de Amazon EMR:
+ Amazon EMR deshabilita los pasos para los clústeres con el LDAP habilitado.
+ Amazon EMR no admite funciones e AWS Lake Formation integraciones de tiempo de ejecución para clústeres con LDAP habilitado.
+ Amazon EMR no admite el LDAP con StartTLS.
+ Amazon EMR no admite el modo de alta disponibilidad (clústeres con varios nodos principales) en los clústeres con el LDAP habilitado.
+ No puede vincular de forma rotativa las credenciales ni los certificados de los clústeres con el LDAP habilitado. Si alguno de esos campos se ha rotado, le recomendamos que inicie un clúster nuevo con las credenciales o certificados de vinculación actualizados.
+ Debe utilizar bases de búsqueda exactas con LDAP. La base de búsqueda de usuarios y grupos de LDAP no admite los filtros de búsqueda de LDAP.
# Configuración y lanzamiento de un clúster de EMR con el LDAP
En esta sección, se explica cómo configurar Amazon EMR para su uso con la autenticación LDAP.
**Topics**
+ [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md)
+ [Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP](ldap-setup-security.md)
+ [Lanzamiento de un clúster de EMR que se autentique con LDAP](ldap-setup-launch.md)
# Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR
Amazon EMR utiliza un rol de servicio de IAM para realizar acciones en su nombre para aprovisionar y administrar clústeres. El rol de servicio para instancias de EC2 de clúster, también conocido como el *perfil de instancia de EC2 para Amazon EMR*, es un tipo especial de rol de servicio que Amazon EMR asigna a cada instancia de EC2 de un clúster en el momento del lanzamiento.
Para definir los permisos para que un clúster de EMR interactúe con los datos de Amazon S3 y otros productos de AWS , defina un perfil de instancia de Amazon EC2 personalizado en lugar de `EMR_EC2_DefaultRole` al lanzar el clúster. Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md) y [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md).
Añada las siguientes instrucciones al perfil de instancia EC2 predeterminado para permitir que Amazon EMR etiquete las sesiones y acceda al que almacena AWS Secrets Manager los certificados 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*"
]
}
```
**nota**
Las solicitudes de clúster fallarán si olvida agregar el carácter comodín `*` al final del nombre del secreto al configurar los permisos de Secrets Manager. El comodín representa las versiones secretas.
También debe limitar el alcance de la AWS Secrets Manager política a solo los certificados que su clúster necesita para aprovisionar instancias.
# Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP
Antes de lanzar un clúster de EMR con integración del LDAP, siga los pasos de [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md) para crear una configuración de seguridad de Amazon EMR para el clúster. Complete las siguientes configuraciones en el bloque `LDAPConfiguration` en `AuthenticationConfiguration` o en los campos correspondientes de la sección **Configuraciones de seguridad** de la consola de Amazon EMR:
**`EnableLDAPAuthentication`**
Opción de consola: **Protocolo de autenticación: LDAP**
Para usar la integración del LDAP, establezca esta opción en `true` o selecciónela como protocolo de autenticación al crear un clúster en la consola. De forma predeterminada, `EnableLDAPAuthentication` es `true` cuando crea una configuración de seguridad en la consola de Amazon EMR.
**`LDAPServerURL`**
Opción de consola: **ubicación del servidor LDAP**
La ubicación del servidor LDAP, incluido el prefijo: `ldaps://location_of_server`.
**`BindCertificateARN`**
Opción de consola: **Certificado SSL del LDAP**
El AWS Secrets Manager ARN que contiene el certificado para firmar el certificado SSL que utiliza el servidor LDAP. Si su servidor LDAP está firmado por una autoridad de certificación (CA) pública, puede proporcionar un AWS Secrets Manager ARN con un archivo en blanco. Para obtener más información sobre cómo almacenar el certificado en Secrets Manager, consulte [Guarde los certificados TLS en AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opción de consola: **credenciales de vinculación del servidor LDAP**
Un AWS Secrets Manager ARN que contiene las credenciales de enlace de usuario administrador de LDAP. Las credenciales se almacenan como un objeto JSON. Solo hay un par clave-valor en este secreto; la clave del par es el nombre de usuario y el valor es la contraseña. Por ejemplo, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Este campo es opcional, a menos que habilite el inicio de sesión SSH para su clúster de EMR. En muchas configuraciones, las instancias de Active Directory requieren credenciales de vinculación para permitir que SSSD sincronice los usuarios.
**`LDAPAccessFilter`**
Opción de consola: **filtro de acceso del LDAP**
Especifica el subconjunto de objetos del servidor LDAP que pueden autenticarse. Por ejemplo, si desea conceder acceso a todos los usuarios con la clase de objeto `posixAccount` de su servidor LDAP, defina el filtro de acceso como `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opción de consola: **base de búsqueda de usuarios de LDAP**
La base de búsqueda a la que pertenecen sus usuarios en su servidor LDAP. Por ejemplo, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Opción de consola: **base de búsqueda de grupos LDAP**
La base de búsqueda a la que pertenecen sus grupos dentro de su servidor LDAP. Por ejemplo, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Opción de consola: **inicio de sesión SSH**
Especifica si se permite o no la autenticación por contraseña con credenciales del LDAP. No le recomendamos habilitar esta opción. Los pares de claves son una ruta más segura para permitir el acceso a los clústeres de EMR. Este campo es opcional y de forma predeterminada es `false`.
**`LDAPServerType`**
Opción de consola: **tipo de servidor LDAP**
Especifica el tipo de servidor LDAP al que se conecta Amazon EMR. Las opciones compatibles son Active Directory y OpenLDAP. Es posible que otros tipos de servidores LDAP funcionen, pero Amazon EMR no admite oficialmente otros tipos de servidores. Para obtener más información, consulte [Componentes del LDAP para Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Un subbloque obligatorio para las configuraciones de seguridad que utilizan el tipo de servidor Active Directory.
**`ADDomain`**
Opción de consola: **dominio de Active Directory**
El nombre de dominio utilizado para crear el nombre principal de usuario (UPN) para la autenticación del usuario con configuraciones de seguridad que utilizan el tipo de servidor Active Directory.
## Aspectos que hay que tener en cuenta para realizar las configuraciones de seguridad con el LDAP y Amazon EMR
+ Para crear una configuración de seguridad con la integración del LDAP de Amazon EMR, debe utilizar el cifrado en tránsito. Para obtener información sobre el cifrado en tránsito, consulte [Cifrar datos en reposo y en tránsito con Amazon EMR](emr-data-encryption.md).
+ No puede definir la configuración de Kerberos en la misma configuración de seguridad. Amazon EMR aprovisiona un KDC dedicado al KDC de forma automática y administra la contraseña de administrador de este KDC. Los usuarios no pueden acceder a esta contraseña de administrador.
+ No puede definir las funciones de tiempo de ejecución de IAM ni AWS Lake Formation en la misma configuración de seguridad.
+ La `LDAPServerURL` debe tener el protocolo `ldaps://` en su valor.
+ El `LDAPAccessFilter` no puede estar vacío.
## Uso del LDAP con la integración de Apache Ranger para Amazon EMR
Con la integración del LDAP para Amazon EMR, puede ampliar su integración con Apache Ranger. Cuando extraiga sus usuarios del LDAP en Ranger, podrá asociarlos a un servidor de políticas de Apache Ranger para integrarlos con Amazon EMR y otras aplicaciones. Para ello, defina el campo `RangerConfiguration` de la configuración de seguridad que `AuthorizationConfiguration` va a utilizar con el clúster del LDAP. Para obtener más información acerca de cómo definir la configuración de seguridad, consulte [Creación de la configuración de seguridad de EMR](emr-ranger-security-config.md).
Cuando utilice el LDAP con Amazon EMR, no tendrá que proporcionar una `KerberosConfiguration` con la integración de Amazon EMR para Apache Ranger.
# Lanzamiento de un clúster de EMR que se autentique con LDAP
Siga estos pasos para lanzar un clúster de EMR con el LDAP o Active Directory:
1. Configure su entorno:
+ Asegúrese de que los nodos del clúster de EMR puedan comunicarse con Amazon S3 y. AWS Secrets Manager Para obtener más información sobre cómo modificar el rol de su perfil de instancia de EC2 para comunicarse con estos servicios, consulte [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md).
+ Si planea ejecutar su clúster de EMR en una subred privada, debe usar puntos de enlace de AWS PrivateLink Amazon VPC o usar la traducción de direcciones de red (NAT) para configurar la VPC de manera que se comunique con S3 y Secrets Manager. Para obtener más información, consulte [AWS PrivateLink y puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) e [Instancias NAT](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) en la *Guía de introducción a Amazon VPC*.
+ Asegúrese de que haya conectividad de red entre el clúster de EMR y el servidor LDAP. Los clústeres de EMR deben acceder a su servidor LDAP a través de la red. Los nodos principal, central y de tareas del clúster se comunican con el servidor LDAP para sincronizar los datos de los usuarios. Si su servidor LDAP se ejecuta en Amazon EC2, actualice el grupo de seguridad de EC2 para que acepte el tráfico del clúster de EMR. Para obtener más información, consulte [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md).
1. Cree una configuración de seguridad de Amazon EMR para la integración del LDAP. Para obtener más información, consulte [Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP](ldap-setup-security.md).
1. Una vez completada la configuración, siga los pasos de [Lanzar un clúster de Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) para lanzar el clúster con las siguientes configuraciones:
+ Seleccione Amazon EMR versión 6.12 o superior. Le recomendamos utilizar la última versión de Amazon EMR.
+ Especifique o seleccione únicamente las aplicaciones de su clúster que admitan el LDAP. Para obtener una lista de las aplicaciones que admitan el LDAP con Amazon EMR, consulte [Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR](ldap-considerations.md).
+ Aplique la configuración de seguridad que creó en el paso anterior.
# Ejemplos de uso del LDAP con Amazon EMR
Una vez que [aprovisione un clúster de EMR que utilice la integración del LDAP](ldap-setup-launch.md), podrá proporcionar sus credenciales de LDAP a cualquier [aplicación compatible](ldap-considerations.md#ldap-considerations-apps) mediante su mecanismo de autenticación de nombre de usuario y contraseña integrado. Esta página muestra algunos ejemplos.
## Uso de la autenticación LDAP con Apache Hive
**Example : Apache Hive**
El siguiente comando de ejemplo inicia una sesión de Apache Hive a través de 2 y Beeline: HiveServer
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Uso de la autenticación LDAP con Apache Livy
**Example : Apache Livy**
El siguiente comando de ejemplo inicia una sesión de Livy a través de cURL. Sustituya `ENCODED-KEYPAIR` por una cadena cifrada en Base64 para `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
```
## Uso de la autenticación LDAP con Presto
**Example : Presto**
El siguiente comando de ejemplo inicia una sesión de Presto a través de la CLI de Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
## Uso de la autenticación LDAP con Trino
**Example : Trino**
El siguiente comando de ejemplo inicia una sesión de Trino a través de la CLI de Trino:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
## Uso de la autenticación LDAP con Hue
Puede acceder a la interfaz de usuario de Hue a través de un túnel SSH que cree en el clúster, o bien puede configurar un servidor proxy para que transmita públicamente la conexión a Hue. Como Hue no se ejecuta en modo HTTPS de forma predeterminada, le recomendamos que utilice una capa de cifrado adicional para garantizar que la comunicación entre los clientes y la interfaz de usuario de Hue esté cifrada con HTTPS. Esto reduce la posibilidad de que exponga accidentalmente las credenciales de usuario en texto sin formato.
Para usar la interfaz de usuario de Hue, abra la interfaz de usuario de Hue en su navegador e ingrese la contraseña y su nombre de usuario del LDAP para iniciar sesión. Si las credenciales son correctas, Hue inicia sesión y usa su identidad para que pueda autenticarse en todas las aplicaciones compatibles.
## Uso de SSH para la autenticación por contraseña y tickets de Kerberos para otras aplicaciones
**importante**
No le recomendamos autenticarse por contraseña para conectarse vía SSH a un clúster de EMR.
Puede usar sus credenciales del LDAP para conectarse vía SSH a un clúster de EMR. Para ello, establezca la configuración `EnableSSHLogin` en `true` en la configuración de seguridad de Amazon EMR que utilice para iniciar el clúster. Cuando se lance el clúster, use el siguiente comando para conectarse vía SSH en el clúster:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
Amazon EMR incluye un script en el clúster que permite a los usuarios generar un archivo keytab y un ticket de Kerberos para usarlos con aplicaciones compatibles que no aceptan credenciales del LDAP directamente. Algunas de estas aplicaciones incluyen `spark-submit` Spark SQL y. PySpark
Ejecute `ldap-kinit` y siga las instrucciones. Si la autenticación se realiza correctamente, el archivo keytab de Kerberos aparecerá en su directorio principal con un ticket de Kerberos válido. Utilice el ticket de Kerberos para ejecutar aplicaciones como lo haría en cualquier entorno kerberizado.