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. # 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).