Utilizar o Pacote de Segurança Enterprise no HDInsight
O cluster padrão do Azure HDInsight é um cluster de usuário único. É adequado para a maioria das empresas que têm equipes de aplicativos menores criando grandes cargas de trabalho de dados. Cada usuário pode criar um cluster dedicado sob demanda e destruí-lo quando não for mais necessário.
Muitas empresas migraram para um modelo no qual as equipes de TI gerenciam clusters e várias equipes de aplicativos compartilham clusters. Essas empresas maiores precisam de acesso multiusuário a cada cluster no Azure HDInsight.
O HDInsight depende de um provedor de identidade popular - o Ative Directory - de forma gerenciada. Ao integrar o HDInsight com os Serviços de Domínio do Microsoft Entra, você pode acessar os clusters usando suas credenciais de domínio.
As máquinas virtuais (VMs) no HDInsight são domínios associados ao domínio fornecido. Assim, todos os serviços executados no HDInsight (Apache Ambari, servidor Apache Hive, Apache Ranger, servidor thrift Apache Spark e outros) funcionam perfeitamente para o usuário autenticado. Os administradores podem então criar políticas de autorização fortes usando o Apache Ranger para fornecer controle de acesso baseado em função para recursos no cluster.
Integrar o HDInsight no Active Directory
O Apache Hadoop de código aberto depende do protocolo Kerberos para autenticação e segurança. Portanto, os nós de cluster do HDInsight com o Enterprise Security Package (ESP) são associados a um domínio gerenciado pelos Serviços de Domínio Microsoft Entra. A segurança Kerberos é configurada para os componentes do Hadoop no cluster.
As seguintes coisas são criadas automaticamente:
- Uma entidade de serviço para cada componente do Hadoop
- Uma entidade de máquina para cada máquina que ingressou no domínio
- Uma Unidade Organizacional (UO) para cada cluster para armazenar essas entidades de serviço e de máquina
Para resumir, você precisa configurar um ambiente com:
- Um domínio do Ative Directory (gerenciado pelos Serviços de Domínio Microsoft Entra). O nome de domínio deve ter 39 caracteres ou menos para funcionar com o Azure HDInsight.
- LDAP seguro (LDAPS) ativado nos Serviços de Domínio Microsoft Entra.
- Conectividade de rede adequada da rede virtual HDInsight para a rede virtual dos Serviços de Domínio Microsoft Entra, se você escolher redes virtuais separadas para elas. Uma VM dentro da rede virtual HDInsight deve ter uma linha de visão para os Serviços de Domínio Microsoft Entra por meio do emparelhamento de rede virtual. Se o HDInsight e os Serviços de Domínio Microsoft Entra forem implantados na mesma rede virtual, a conectividade será fornecida automaticamente e nenhuma ação adicional será necessária.
Configurar diferentes controladores de domínio
Atualmente, o HDInsight suporta apenas os Serviços de Domínio Microsoft Entra como o controlador de domínio principal que o cluster usa para comunicação Kerberos. Mas outras configurações complexas do Ative Directory são possíveis, desde que essa configuração permita habilitar os Serviços de Domínio Microsoft Entra para acesso ao HDInsight.
Microsoft Entra Domain Services
Os Serviços de Domínio Microsoft Entra fornecem um domínio gerenciado que é totalmente compatível com o Ative Directory do Windows Server. A Microsoft cuida do gerenciamento, aplicação de patches e monitoramento do domínio em uma configuração altamente disponível (HA). Você pode implantar seu cluster sem se preocupar com a manutenção de controladores de domínio.
Usuários, grupos e senhas são sincronizados a partir do Microsoft Entra ID. A sincronização unidirecional da instância do Microsoft Entra com os Serviços de Domínio do Microsoft Entra permite que os usuários entrem no cluster usando as mesmas credenciais corporativas.
Para obter mais informações, consulte Configurar clusters HDInsight com ESP usando os Serviços de Domínio Microsoft Entra.
Active Directory no local ou Active Directory em VMs IaaS
Se você tiver uma instância local do Ative Directory ou configurações mais complexas do Ative Directory para seu domínio, poderá sincronizar essas identidades com a ID do Microsoft Entra usando o Microsoft Entra Connect. Em seguida, você pode habilitar os Serviços de Domínio do Microsoft Entra nesse locatário do Ative Directory.
Como o Kerberos depende de hashes de senha, você deve habilitar a sincronização de hash de senha nos Serviços de Domínio Microsoft Entra.
Se estiver a utilizar os AD FS, deverá ativar a sincronização do hash de palavras-passe (para a configuração recomendada, veja este vídeo). A sincronização do hash de palavras-passe ajuda com a recuperação após desastre no caso da infraestrutura do AD FS falhar e também ajuda a proporcionar proteção contra a fuga de credenciais. Para obter mais informações, consulte Habilitar a sincronização de hash de senha com o Microsoft Entra Connect Sync.
O uso do Ative Directory local ou do Ative Directory apenas em VMs IaaS, sem o Microsoft Entra ID e os Serviços de Domínio Microsoft Entra, não é uma configuração suportada para clusters HDInsight com ESP.
Nota
Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a atualização de descontinuação. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e correções de segurança. Os módulos preteridos continuarão a funcionar até 30 de março de 2025.
Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas frequentes sobre migração. Nota: As versões 1.0.x do MSOnline podem sofrer interrupções após 30 de junho de 2024.
Se a federação estiver a ser utilizada e os hashes de palavras-passe estiverem sincronizados corretamente, mas estiver a obter falhas de autenticação, verifique se a autenticação de palavras-passe da cloud está ativada para o principal de serviço do PowerShell. Caso contrário, você deve definir uma política de HRD (Home Realm Discovery) para seu locatário do Microsoft Entra. Para verificar e definir a política de DRH:
Instale o módulo de visualização do Azure AD PowerShell.
Install-Module AzureADConecte-se usando credenciais de administrador global (administrador de locatário).
Connect-AzureADVerifique se a entidade de serviço do Microsoft Azure PowerShell já foi criada.
Get-AzureADServicePrincipal -SearchString "Microsoft Azure PowerShell"Se ele não existir, crie a entidade de serviço.
$powershellSPN = New-AzureADServicePrincipal -AppId 1950a258-227b-4e31-a9cf-717495945fc2Crie e anexe a política a esta entidade de serviço.
# 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