Opciones de la arquitectura Kerberos

Cuando utiliza Kerberos con AmazonEMR, puede elegir entre las arquitecturas que se muestran en esta sección. Independientemente de la arquitectura que elija, para configurar Kerberos hay que seguir los mismos pasos. Crea una configuración de seguridad, especifica la configuración de seguridad y las opciones de Kerberos compatibles específicas del clúster al crear el clúster, y crea HDFS directorios para los usuarios de Linux en el clúster que coinciden con los principios de usuario de. 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.

Dedicado al clúster KDC (en el nodo principal) KDC

Esta configuración está disponible con las EMR versiones 5.10.0 y superiores de Amazon.

Ventajas

• Amazon EMR tiene la propiedad total deKDC.

• El KDC del EMR clúster es independiente de KDC las implementaciones centralizadas, como Microsoft Active Directory o AWS Managed Microsoft AD.

• El impacto en el rendimiento es mínimo porque KDC administra la autenticación solo para los nodos locales del clúster.

• Opcionalmente, otros clústeres kerberizados pueden hacer referencia a ellos KDC como externos. KDC Para obtener más información, consulte ExternoKDC: nodo principal de un clúster diferente.

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úster necesitan interoperar, debe establecer una confianza entre dominios entre los clústeres o configurar un clúster como externo KDC para los demás clústeres. Si se establece una confianza entre dominios, KDCs deben tener diferentes dominios de Kerberos.

• Debe crear los usuarios de Linux en la EC2 instancia del nodo principal que correspondan a los KDC usuarios principales, junto con los HDFS directorios de cada usuario.

• Los usuarios principales deben usar un archivo de clave EC2 privada y kinit credenciales para conectarse al clúster mediante. SSH

Relación de confianza entre ámbitos

En esta configuración, los directores (normalmente los usuarios) de un dominio Kerberos diferente se autentican en los componentes de la aplicación de un EMR clúster kerberizado, que tiene el suyo propio. KDC El KDC nodo principal establece una relación de confianza con otro KDC mediante un principal entre dominios que existe en ambos. KDCs El nombre principal y la contraseña coinciden exactamente en cada uno KDC de ellos. 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 las confianzas entre dominios con un clúster externo MIT KDC o KDC en otro EMR clúster de Amazon.

Ventajas

• El EMR clúster en el que KDC está instalado mantiene la propiedad total delKDC.

• Con Active Directory, Amazon crea EMR automáticamente usuarios de Linux que corresponden a los principios de usuario deKDC. Aún debe crear HDFS directorios para cada usuario. Además, los usuarios principales del dominio de Active Directory pueden acceder a los clústeres Kerberizados mediante kinit credenciales, sin el archivo de clave EC2 privada. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.

• Como cada clúster KDC 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 para una gran cantidad de nodos de los 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 el clúster B establecen una confianza entre dominios con aKDC, no confían intrínsecamente el uno en el otro y sus aplicaciones no pueden autenticarse entre sí para interoperar.

• KDCsdeben mantenerse de forma independiente y coordinada para que las credenciales de los usuarios principales coincidan con precisión.

Externo KDC

Las configuraciones con un dispositivo externo KDC son compatibles con Amazon EMR 5.20.0 y versiones posteriores.

• Externo: KDC MIT KDC

• ExternoKDC: nodo principal de un clúster diferente

• ExternoKDC: clúster KDC en un clúster diferente con confianza entre dominios de Active Directory

Externo: KDC MIT KDC

Esta configuración permite que uno o más EMR clústeres utilicen los principios definidos y mantenidos en un MIT KDC servidor.

Ventajas

• La administración de los principales se consolida en una sola unidad. KDC

• Varios clústeres pueden usar lo mismo KDC en el mismo dominio de Kerberos. Para obtener más información, consulte Requisitos para usar varios clústeres con el mismo KDC.

• El nodo principal de un clúster kerberizado no tiene la carga de rendimiento asociada con el mantenimiento del. KDC

Consideraciones y limitaciones

• Debe crear usuarios de Linux en la EC2 instancia del nodo principal de cada clúster kerberizado que correspondan a los usuarios principales, junto con los HDFS directorios de cada KDC usuario.

• Los usuarios principales deben usar un archivo de clave EC2 privada y kinit credenciales para conectarse a los clústeres Kerberizados mediante. SSH

• Cada nodo de los EMR clústeres kerberizados debe tener una ruta de red hacia. KDC

• Cada nodo de los clústeres kerberizados supone una carga de autenticación para el externoKDC, por lo que la configuración del nodo afecta al rendimiento del KDC clúster. Al configurar el hardware del KDC servidor, tenga en cuenta el número máximo de EMR nodos de Amazon que se admitirán simultáneamente.

• El rendimiento del clúster depende de la latencia de la red entre los nodos de los clústeres Kerberizados y los. KDC

• La solución de problemas puede ser más difícil debido a las interdependencias.

ExternoKDC: nodo principal de un clúster diferente

Esta configuración es casi idéntica a la MIT KDC implementación externa anterior, excepto que KDC se encuentra en el nodo principal de un EMR clúster. Para obtener más información, consulte Dedicado al clúster KDC (en el nodo principal) KDC y Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory.

Ventajas

• Los principios de administración se consolidan en un solo KDC elemento.

• Varios clústeres pueden usar lo mismo KDC en el mismo dominio de Kerberos. Para obtener más información, consulte Requisitos para usar varios clústeres con el mismo KDC.

Consideraciones y limitaciones

• Debe crear usuarios de Linux en la EC2 instancia del nodo principal de cada clúster kerberizado que correspondan a los usuarios principales, junto con los HDFS directorios de cada KDC usuario.

• Los usuarios principales deben usar un archivo de clave EC2 privada y kinit credenciales para conectarse a los clústeres Kerberizados mediante. SSH

• Cada nodo de cada EMR clúster debe tener una ruta de red hacia. KDC

• Cada EMR nodo de Amazon en los clústeres kerberizados supone una carga de autenticación para el externoKDC, por lo que la configuración del nodo KDC afecta al rendimiento del clúster. Al configurar el hardware del KDC servidor, tenga en cuenta el número máximo de EMR nodos de Amazon que se admitirán simultáneamente.

• El rendimiento del clúster depende de la latencia de la red entre los nodos de los clústeres y elKDC.

• La solución de problemas puede ser más difícil debido a las interdependencias.

ExternoKDC: clúster KDC en un clúster diferente con confianza entre dominios de Active Directory

En esta configuración, primero debe crear un clúster con un clúster dedicado KDC que tenga una confianza unidireccional entre dominios 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. A continuación, se lanzan clústeres adicionales y se hace referencia al clúster KDC que tiene la confianza como externo. KDC Para ver un ejemplo, consulte Clúster KDC externo con confianza entre dominios de Active Directory. Esto permite que cada EMR clúster de Amazon que utilice el externo KDC autentique los principales definidos y mantenidos en un dominio de Microsoft Active Directory.

Ventajas

• La administración de entidades principales se consolida en el dominio de Active Directory.

• Amazon EMR se une al dominio de Active Directory, lo que elimina la necesidad de crear usuarios de Linux que correspondan a los usuarios de Active Directory. Aún debe crear HDFS directorios para cada usuario.

• Varios clústeres pueden usar lo mismo KDC en el mismo dominio de Kerberos. Para obtener más información, consulte Requisitos para usar varios clústeres con el mismo KDC.

• Los usuarios principales del dominio de Active Directory pueden acceder a los clústeres kerberizados mediante kinit credenciales, sin el EC2 archivo de clave privada. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.

• Solo un nodo EMR principal de Amazon tiene la carga de mantener elKDC, y solo ese clúster debe crearse con las credenciales de Active Directory para la confianza entre dominios entre Active Directory KDC y Active Directory.

Consideraciones y limitaciones

• Cada nodo de cada EMR clúster debe tener una ruta de red al controlador de dominio de Active Directory KDC y al mismo.

• Cada EMR nodo de Amazon impone una carga de autenticación al externoKDC, por lo que la configuración del nodo KDC afecta al rendimiento del clúster. Al configurar el hardware del KDC servidor, tenga en cuenta el número máximo de EMR nodos de Amazon que se admitirán simultáneamente.

• El rendimiento de los clústeres depende de la latencia de la red entre los nodos de los clústeres y el KDC servidor.

• La solución de problemas puede ser más difícil debido a las interdependencias.

Requisitos para usar varios clústeres con el mismo KDC

Varios clústeres pueden usar lo mismo KDC en el mismo dominio 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 externoKDC, asegúrese de que los clústeres utilicen distintos dominios de Kerberos. Si los clústeres deben usar el mismo dominio de Kerberos, asegúrese de que los clústeres estén en subredes diferentes y de que sus CIDR rangos no se superpongan.