Uso de Enterprise Security Package en HDInsight
El clúster de Azure HDInsight estándar es de un único usuario. Es apropiado para la mayor parte de las empresas que tienen equipos de aplicaciones pequeños que generan grandes cargas de trabajo de datos. Cada usuario puede crear un clúster dedicado a petición y destruirlo cuando ya no sea necesario.
Muchas empresas han migrado a un modelo en el que los equipos de TI administran los clústeres y varios equipos de aplicaciones los comparten. Estas empresas más grandes necesitan acceso multiusuario a cada clúster de Azure HDInsight.
HDInsight se basa en un proveedor de identidades conocido (Active Directory) de una manera administrada. Mediante la integración de HDInsight con Azure Active Directory Domain Services (Azure AD DS), puede acceder a los clústeres con sus credenciales de dominio.
Las máquinas virtuales (VM) de HDInsight están unidas al dominio proporcionado. De este modo, todos los servicios que se ejecutan en HDInsight (Apache Ambari, servidor de Apache Hive, Apache Ranger, servidor Thrift de Apache Spark, etc.) funcionan perfectamente para el usuario autenticado. Los administradores pueden crear entonces directivas de autorización seguras con Apache Ranger para proporcionar control de acceso basado en rol para los recursos del clúster.
Integración de HDInsight con Active Directory
Apache Hadoop de código abierto se basa en el protocolo Kerberos para proporcionar autenticación y seguridad. Por consiguiente, los nodos del clúster de HDInsight con Enterprise Security Package (ESP) se combinan en un dominio que administra Azure AD DS. Se configura la seguridad de Kerberos para los componentes de Hadoop en el clúster.
Las siguientes cosas se crean automáticamente:
- Una entidad de servicio para cada componente de Hadoop.
- Una entidad de seguridad de máquina para cada máquina unida al dominio.
- Una unidad organizativa (UO) para cada clúster para almacenar estas entidades de servicio y de máquina.
En resumen, es necesario configurar un entorno con:
- Un dominio de Active Directory (administrado por Azure AD DS). El nombre de dominio debe tener 39 caracteres como máximo para funcionar con Azure HDInsight.
- LDAP seguro (LDAPS) habilitado en Azure AD DS.
- Conectividad de red adecuada desde la red virtual de HDInsight a la red virtual de Azure AD DS, si elige redes virtuales independientes para ellas. Una máquina virtual dentro de la red virtual de HDInsight debe tener una línea de visión a Azure AD DS a través del emparejamiento de la red virtual. Si HDInsight y Azure AD DS se implementan en la misma red virtual, la conectividad se proporciona de manera automática y no es necesaria ninguna otra acción.
Configuración de distintos controladores de dominio
HDInsight actualmente solo admite Azure AD DS como el controlador de dominio principal que el clúster usa para la comunicación de Kerberos. Pero hay otras configuraciones complejas de Active Directory que son posibles, siempre que dicha configuración lleve a habilitar Azure AD DS para el acceso de HDInsight.
Azure Active Directory Domain Services
Azure AD DS proporciona un dominio administrado que es totalmente compatible con Windows Server Active Directory. Microsoft se encarga de administrar y supervisar el dominio, y de aplicarle los parches, en una configuración de alta disponibilidad (HA). Puede implementar el clúster sin preocuparse por mantener los controladores de dominio.
Los usuarios, los grupos y las contraseñas se sincronizan desde Azure AD. La sincronización unidireccional desde la instancia de Azure AD a Azure AD DS permite que los usuarios inicien sesión en el clúster con las mismas credenciales corporativas.
Para más información, consulte Configuración de clústeres de HDInsight con Enterprise Security Package mediante Azure Active Directory Domain Services.
Active Directory local o Active Directory en máquinas virtuales de IaaS
Si tiene una instancia de Active Directory local o configuraciones más complejas de Active Directory para el dominio, puede sincronizar esas identidades con Azure AD mediante Azure AD Connect. Luego puede habilitar Azure AD DS en ese inquilino de Active Directory.
Como Kerberos se basa en valores hash de contraseña, debe habilitar la sincronización de hash de contraseñas en Azure AD DS.
Si está usando la federación con los Servicios de federación de Active Directory (AD FS), debe habilitar la sincronización del hash de contraseña. (Para ver una configuración recomendada, consulte este vídeo.) La sincronización del hash contraseña le permite llevar a cabo la recuperación ante desastres en caso de que su infraestructura de AD FS falle; asimismo, también le ayudará a proporcionar protección para las credenciales filtradas. Para más información, consulte Implementación de la sincronización de hash de contraseñas con la sincronización de Azure AD Connect.
El uso de una instancia de Active Directory local o de Active Directory solo en máquinas virtuales de IaaS, sin Azure AD ni Azure AD DS, no es una configuración compatible con los clústeres de HDInsight con ESP.
Si se está usando la federación y los hash de contraseña se sincronizan correctamente, pero recibe errores de autenticación, compruebe si está habilitada la autenticación de contraseña en la nube para la entidad de servicio de PowerShell. De lo contrario, debe establecer una directiva para la Detección del dominio principal (HRD) en el inquilino de Azure AD. Para comprobar y establecer la directiva de HRD:
Instale la versión preliminar del módulo de PowerShell de Azure AD.
Install-Module AzureADConéctese con las credenciales de un administrador global (administrador de inquilinos).
Connect-AzureADCompruebe si ya se ha creado la entidad de servicio "Microsoft Azure PowerShell".
Get-AzureADServicePrincipal -SearchString "Microsoft Azure Powershell"Si no existe, cree la entidad de servicio.
$powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2Cree y asocie la directiva a la entidad de servicio.
# Determine whether policy exists Get-AzureADPolicy | Where {$_.DisplayName -eq "EnableDirectAuth"} # Create if not exists $policy = New-AzureADPolicy ` -Definition @('{"HomeRealmDiscoveryPolicy":{"AllowCloudPasswordValidation":true}}') ` -DisplayName "EnableDirectAuth" ` -Type "HomeRealmDiscoveryPolicy" # Determine whether a policy for the service principal exist Get-AzureADServicePrincipalPolicy ` -Id $powershellSPN.ObjectId # Add a service principal policy if not exist Add-AzureADServicePrincipalPolicy ` -Id $powershellSPN.ObjectId ` -refObjectID $policy.ID