Opções de arquitetura Kerberos com a Amazon EMR

Ao usar o Kerberos com a AmazonEMR, você pode escolher entre as arquiteturas listadas nesta seção. Independentemente da arquitetura que escolhida, você pode configurar o Kerberos usando as mesmas etapas. Você cria uma configuração de segurança, especifica a configuração de segurança e as opções Kerberos compatíveis específicas do cluster ao criar o cluster e cria HDFS diretórios para usuários Linux no cluster que correspondem aos principais usuários no. KDC Para obter uma explicação sobre as opções de configuração e configurações de exemplo para cada arquitetura, consulte Configurando o Kerberos na Amazon EMR.

Dedicado ao cluster KDC (KDCno nó primário)

Essa configuração está disponível com as EMR versões 5.10.0 e posteriores da Amazon.

Vantagens

• A Amazon EMR tem propriedade total daKDC.

• O KDC no EMR cluster é independente de KDC implementações centralizadas, como Microsoft Active Directory ou. AWS Managed Microsoft AD

• O impacto no desempenho é mínimo porque KDC gerencia a autenticação somente para nós locais dentro do cluster.

• Opcionalmente, outros clusters Kerberizados podem referenciá-los KDC como externos. KDC Para obter mais informações, consulte Externo KDC — nó primário em um cluster diferente.

Considerações e limitações

• Os clusters Kerberizados não podem autenticar uns ao outros, portanto, os aplicativos não podem interoperar. Se os aplicativos de cluster precisarem interoperar, você deverá estabelecer uma relação de confiança entre os clusters ou configurar um cluster como externo KDC para outros clusters. Se uma relação de confiança entre reinos for estabelecida, eles KDCs devem ter reinos Kerberos diferentes.

• Você deve criar usuários Linux na EC2 instância do nó primário que correspondam aos principais KDC usuários, junto com os HDFS diretórios de cada usuário.

• Os usuários principais devem usar um arquivo de chave EC2 privada e kinit credenciais para se conectar ao cluster usando. SSH

Relação de confiança entre realms

Nessa configuração, os principais (geralmente usuários) de uma região Kerberos diferente se autenticam nos componentes do aplicativo em um cluster KerberizadoEMR, que tem seu próprio. KDC O KDC no nó primário estabelece uma relação de confiança com outro KDC usando um princípio entre domínios que existe em ambos. KDCs O nome principal e a senha coincidem exatamente em cada umKDC. Relações de confianças entre realms são mais comuns com implementações do Active Directory, conforme mostrado no diagrama a seguir. Confianças entre regiões com um cluster externo MIT KDC ou em KDC outro EMR cluster da Amazon também são suportadas.

Vantagens

• O EMR cluster no qual o KDC está instalado mantém a propriedade total doKDC.

• Com o Active Directory, a Amazon cria EMR automaticamente usuários Linux que correspondem aos principais usuários doKDC. Você ainda precisa criar HDFS diretórios para cada usuário. Além disso, usuários principais no domínio do Active Directory podem acessar clusters Kerberizados usando kinit credenciais, sem o EC2 arquivo de chave privada. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.

• Como cada cluster KDC gerencia a autenticação dos nós no cluster, os efeitos da latência da rede e da sobrecarga de processamento de um grande número de nós nos clusters são minimizados.

Considerações e limitações

• Se estiver estabelecendo uma relação de confiança com um domínio do Active Directory, você deverá fornecer um nome de usuário e senha do Active Directory com permissões para se juntar aos principais do domínio ao criar o cluster.

• As relações de confiança entre realms não podem ser estabelecidas entre realms do Kerberos com o mesmo nome.

• As relações de confiança entre realms deve ser estabelecidas explicitamente. Por exemplo, se o cluster A e o cluster B estabelecerem uma relação de confiança entre regiões com aKDC, eles não confiam inerentemente um no outro e seus aplicativos não podem se autenticar uns nos outros para interoperar.

• KDCsdevem ser mantidas de forma independente e coordenada para que as credenciais dos usuários principais correspondam com precisão.

Externo KDC

As configurações com um externo KDC são compatíveis com o Amazon EMR 5.20.0 e versões posteriores.

• Externo KDC — MIT KDC

• Externo KDC — nó primário em um cluster diferente

• Externo KDC — cluster KDC em um cluster diferente com confiança entre regiões do Active Directory

Externo KDC — MIT KDC

Essa configuração permite que um ou mais EMR clusters usem os principais definidos e mantidos em um MIT KDC servidor.

Vantagens

• Os diretores administrativos são consolidados em um único. KDC

• Vários clusters podem usar o mesmo KDC no mesmo reino Kerberos. Para obter mais informações, consulte Requisitos para usar vários clusters com o mesmo KDC.

• O nó primário em um cluster Kerberizado não tem a carga de desempenho associada à manutenção do. KDC

Considerações e limitações

• Você deve criar usuários Linux na EC2 instância do nó primário de cada cluster Kerberizado que correspondam aos principais usuários, junto com os HDFS diretórios de cada KDC usuário.

• Os usuários principais devem usar um arquivo de chave EC2 privada e kinit credenciais para se conectar aos clusters Kerberizados usando. SSH

• Cada nó em EMR clusters Kerberizados deve ter uma rota de rede para o. KDC

• Cada nó em clusters Kerberizados coloca uma carga de autenticação no externoKDC, portanto, a configuração do KDC afeta o desempenho do cluster. Ao configurar o hardware do KDC servidor, considere o número máximo de EMR nós da Amazon a serem suportados simultaneamente.

• O desempenho do cluster depende da latência da rede entre os nós nos clusters Kerberizados e o. KDC

• A solução de problemas pode ser mais difícil devido a interdependências.

Externo KDC — nó primário em um cluster diferente

Essa configuração é quase idêntica à MIT KDC implementação externa acima, exceto pelo fato de KDC estar no nó primário de um EMR cluster. Para ter mais informações, consulte Dedicado ao cluster KDC (KDCno nó primário) e Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory.

Vantagens

• Os diretores administrativos são consolidados em um único. KDC

• Vários clusters podem usar o mesmo KDC no mesmo reino Kerberos. Para obter mais informações, consulte Requisitos para usar vários clusters com o mesmo KDC.

Considerações e limitações

• Você deve criar usuários Linux na EC2 instância do nó primário de cada cluster Kerberizado que correspondam aos principais usuários, junto com os HDFS diretórios de cada KDC usuário.

• Os usuários principais devem usar um arquivo de chave EC2 privada e kinit credenciais para se conectar aos clusters Kerberizados usando. SSH

• Cada nó em cada EMR cluster deve ter uma rota de rede para KDC o.

• Cada EMR nó da Amazon em clusters Kerberizados coloca uma carga de autenticação no externoKDC, portanto, a configuração do KDC afeta o desempenho do cluster. Ao configurar o hardware do KDC servidor, considere o número máximo de EMR nós da Amazon a serem suportados simultaneamente.

• O desempenho do cluster depende da latência da rede entre os nós nos clusters e o. KDC

• A solução de problemas pode ser mais difícil devido a interdependências.

Externo KDC — cluster KDC em um cluster diferente com confiança entre regiões do Active Directory

Nessa configuração, primeiro você cria um cluster com um cluster dedicado KDC que tem uma relação de confiança unidirecional entre regiões com o Active Directory. Para ver um tutorial detalhado, consulte Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory. Em seguida, você executa clusters adicionais, referenciando o cluster KDC que tem a confiança como externoKDC. Para obter um exemplo, consulte Cluster externo KDC com confiança entre regiões do Active Directory. Isso permite que cada EMR cluster da Amazon que usa o externo KDC autentique os principais definidos e mantidos em um domínio do Microsoft Active Directory.

Vantagens

• O gerenciamento de principais é consolidado no domínio do Active Directory.

• A Amazon EMR se junta ao reino do Active Directory, o que elimina a necessidade de criar usuários Linux que correspondam aos usuários do Active Directory. Você ainda precisa criar HDFS diretórios para cada usuário.

• Vários clusters podem usar o mesmo KDC no mesmo reino Kerberos. Para obter mais informações, consulte Requisitos para usar vários clusters com o mesmo KDC.

• Os usuários principais no domínio do Active Directory podem acessar clusters Kerberizados usando kinit credenciais, sem o EC2 arquivo de chave privada. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.

• Somente um nó EMR primário da Amazon tem a responsabilidade de manter oKDC, e somente esse cluster deve ser criado com as credenciais do Active Directory para a confiança entre regiões entre o KDC e o Active Directory.

Considerações e limitações

• Cada nó em cada EMR cluster deve ter uma rota de rede para o KDC e para o controlador de domínio do Active Directory.

• Cada EMR nó da Amazon coloca uma carga de autenticação no externoKDC, portanto, a configuração do KDC afeta o desempenho do cluster. Ao configurar o hardware do KDC servidor, considere o número máximo de EMR nós da Amazon a serem suportados simultaneamente.

• O desempenho do cluster depende da latência da rede entre os nós nos clusters e o KDC servidor.

• A solução de problemas pode ser mais difícil devido a interdependências.

Requisitos para usar vários clusters com o mesmo KDC

Vários clusters podem usar o mesmo KDC no mesmo reino Kerberos. No entanto, se os clusters forem executados simultaneamente, eles poderão falhar se usarem ServicePrincipal nomes Kerberos conflitantes.

Se você tiver vários clusters simultâneos com o mesmo externoKDC, certifique-se de que os clusters usem realms Kerberos diferentes. Se os clusters precisarem usar o mesmo reino Kerberos, certifique-se de que os clusters estejam em sub-redes diferentes e que seus CIDR intervalos não se sobreponham.