As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Autenticação em nós de cluster do Amazon EMR
Os clientes SSH podem usar um par de chaves do Amazon EC2 para autenticar-se em instâncias de cluster. Como alternativa, com o Amazon EMR 5.10.0 ou versões posteriores, você pode configurar o Kerberos para autenticar usuários e conexões SSH para o nó primário. E com o Amazon EMR 5.12.0 e versões posteriores, você pode se autenticar com o LDAP.
**Topics**
+ [Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR](emr-plan-access-ssh.md)
+ [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md)
+ [Usar servidores Active Directory ou LDAP para autenticação com o Amazon EMR](ldap.md)
# Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR
Os nós de cluster do Amazon EMR são executados em instâncias do Amazon EC2. É possível se conectar a nós de cluster da mesma forma que você se conecta a instâncias do Amazon EC2. Você pode usar o Amazon EC2 para criar um par de chaves ou você pode importar um par de chaves. Ao criar um cluster, é possível especificar o par de chaves do Amazon EC2 que será usado nas conexões SSH para todas as instâncias de cluster. Também é possível criar um cluster sem par de chaves. Isso geralmente é feito com clusters transitórios que são iniciados, executam etapas e são encerrados automaticamente.
O cliente SSH que você usa para se conectar ao cluster precisa usar o arquivo de chave privada associado ao par de chaves. Esse é um arquivo .pem para clientes SSH que usam Linux, Unix e macOS. Você deve definir permissões para que apenas o proprietário da chave tenha permissão para acessar o arquivo. É um arquivo .ppk para clientes SSH que usam o Windows, e o arquivo .ppk geralmente é criado a partir do arquivo .pem.
+ Para obter mais informações sobre a criação de pares de chaves do Amazon EC2, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
+ *Para obter instruções sobre como usar o Pu TTYgen para criar um arquivo.ppk a partir de um arquivo.pem, consulte [Convertendo sua chave privada usando o Pu no Guia do usuário do TTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) Amazon EC2.*
+ Para obter mais informações sobre como definir permissões de arquivos.pem e como se conectar ao nó primário de um cluster do EMR usando métodos diferentes, inclusive do `ssh` Linux ou macOS, do PuTTY do Windows ou AWS CLI de qualquer sistema operacional compatível, consulte. [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md)
# Usar o Kerberos para autenticação com o Amazon EMR
O Amazon EMR 5.10.0 e versões posteriores oferecem suporte ao Kerberos. O Kerberos é um protocolo de autenticação de rede que usa criptografia segredo-chave para fornecer autenticação forte, de maneira que senhas ou outras credenciais não sejam enviadas pela rede em um formato não criptografado.
No Kerberos, os serviços e os usuários que precisam se autenticar são conhecidos como *entidades principais*. As entidades principais existem em um *realm* Kerberos. Dentro do realm, um servidor Kerberos conhecido como *Key Distribution Center (KDC)* oferece as entidades principais se autenticarem. O KDC faz isso emitindo *tíquetes* para autenticação. O KDC mantém um banco de dados das entidades principais no realm, as senhas e outras informações administrativas sobre cada entidade principal. Um KDC também pode aceitar credenciais de autenticação de entidades principais em outros realms, o que é conhecido como uma *relação de confiança entre realms*. Além disso, um cluster do EMR pode usar um KDC externo para autenticar principais.
Um cenário comum para estabelecer uma relação de confiança entre realms ou usar um KDC externo é autenticar usuários de um domínio do Active Directory. Isso permite que os usuários acessem um cluster do EMR com a conta do domínio quando eles usarem o SSH para se conectar a um cluster ou trabalhar com aplicações de big data.
Quando você usa autenticação do Kerberos, o Amazon EMR configura o Kerberos para as aplicações, os componentes e os subsistemas que ele instala no cluster, de maneira que eles sejam autenticados entre si.
**Importante**
O Amazon EMR não oferece suporte AWS Directory Service for Microsoft Active Directory em uma relação de confiança entre regiões ou como um KDC externo.
Antes de configurar o Kerberos usando o Amazon EMR, recomendamos que você se familiarize com os conceitos do Kerberos, os serviços executados em um KDC e as ferramentas para administrar serviços do Kerberos. Para obter mais informações, consulte a [documentação do MIT Kerberos](http://web.mit.edu/kerberos/krb5-latest/doc/), publicada pelo [Kerberos Consortium](http://kerberos.org/).
**Topics**
+ [Aplicações compatíveis com o Amazon EMR](emr-kerberos-principals.md)
+ [Opções de arquitetura do Kerberos com o Amazon EMR](emr-kerberos-options.md)
+ [Configurar o Kerberos no Amazon EMR](emr-kerberos-configure.md)
+ [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: configurar um KDC dedicado ao cluster com o Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md)
# Aplicações compatíveis com o Amazon EMR
Em um cluster do EMR, as entidades principais do Kerberos são os serviços de aplicações de big data e os subsistemas executados em todos os nós de cluster. O Amazon EMR pode configurar as aplicações e os componentes listados abaixo para usar o Kerberos. Cada aplicativo tem uma entidade principal de usuário Kerberos associada.
O Amazon EMR não oferece suporte a relações de confiança entre realms com AWS Directory Service for Microsoft Active Directory.
O Amazon EMR somente configura os recursos de autenticação do Kerberos de código aberto para as aplicações e os componentes listados abaixo. Todos os outros aplicativos instalados não são Kerberizados, o que pode resultar em uma incapacidade de se comunicar com componentes Kerberizados e causar erros de aplicativo. Os aplicativos e os componentes não Kerberizados não têm autenticação ativada. As aplicações e componentes compatíveis podem variar conforme as diferentes versões do Amazon EMR.
A interface de usuário do Livy é a única interface de usuário da Web hospedada no cluster que é kerberizada.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ Não habilite o Hive com autenticação LDAP. Isso pode causar problemas na comunicação com o YARN Kerberizado.
+ **Hue**
+ A autenticação de usuário do Hue não é definida automaticamente e pode ser configurada usando-se a API de configuração.
+ O servidor do Hue é Kerberizado. O front-end (UI) do Hue não está configurado para autenticação. A autenticação LDAP pode ser configurada para o Hue UI.
+ **Livy**
+ A representação do Livy com clusters kerberizados é compatível com as versões 5.22.0 e posteriores do Amazon EMR.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ O Presto oferece suporte à autenticação Kerberos no Amazon EMR 6.9.0 e versões posteriores.
+ Para usar a autenticação Kerberos com o Presto, é necessário habilitar a [criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ O Trino oferece suporte à autenticação Kerberos no Amazon EMR 6.11.0 e versões posteriores.
+ Para usar a autenticação Kerberos com o Trino, é necessário habilitar a [criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ O Zeppelin é configurado somente para usar o Kerberos com o intérprete do Spark. Ele não é configurado para outros intérpretes.
+ A representação de usuário não oferece suporte a intérpretes kerberizados do Zeppelin além do Spark.
+ **Zookeeper**
+ O cliente do Zookeeper não é compatível.
# Opções de arquitetura do Kerberos com o Amazon EMR
Ao usar o Kerberos com o Amazon EMR, 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 do Kerberos e as opções específicas do cluster compatíveis ao criar o cluster, e você cria diretórios do HDFS para usuários do Linux no cluster que correspondam aos usuários principais no KDC. Para obter uma explicação sobre as opções de configuração e configurações de exemplo para cada arquitetura, consulte [Configurar o Kerberos no Amazon EMR](emr-kerberos-configure.md).
## KDC dedicado ao cluster (KDC no nó primário)
Essa configuração está disponível no Amazon EMR 5.10.0 e versões posteriores.
![\[Amazon EMRcluster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Vantagens**
+ O Amazon EMR tem total propriedade do KDC.
+ O KDC no cluster do EMR é independente das implementações centralizadas do KDC, como o Microsoft Active Directory ou o AWS Managed Microsoft AD.
+ O impacto no desempenho é mínimo porque o KDC gerencia a autenticação somente para nós locais no cluster.
+ Opcionalmente, outros clusters Kerberizados pode fazer referência ao KDC como um KDC externo. Para obter mais informações, consulte [KDC externo: nó primário em um cluster diferente](#emr-kerberos-extkdc-cluster-summary).
**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 realms entre os clusters, ou configurar um cluster como o KDC externo 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 do Linux na instância do EC2 do nó primário que correspondam aos usuários principais do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar ao cluster usando SSH.
## Relação de confiança entre realms
Nessa configuração, os principais (normalmente usuários) de um realm do Kerberos diferente autenticam componentes do aplicativo em um cluster do EMR Kerberizado, que tem seu próprio KDC. O KDC no nó primário estabelece uma relação de confiança com outro KDC usando um *principal entre domínios que existe em ambos*. KDCs O nome do principal e a senha coincidem precisamente em cada KDC. Relações de confianças entre realms são mais comuns com implementações do Active Directory, conforme mostrado no diagrama a seguir. Relações de confiança entre realms com um MIT KDC externo ou um KDC em outro cluster do Amazon EMR também são compatíveis.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Vantagens**
+ O cluster do EMR no qual o KDC está instalado mantém a total propriedade do KDC.
+ Com o Active Directory, o Amazon EMR cria automaticamente usuários do Linux que correspondam aos usuários principais do KDC. Ainda assim é necessário criar diretórios do HDFS para cada usuário. Além disso, os usuário principais no domínio do Active Directory podem acessar clusters Kerberizados usando credenciais `kinit`, sem o arquivo de chave privada do EC2. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.
+ Como cada cluster do KDC gerencia a autenticação para os nós no cluster, os efeitos da latência da rede e da sobrecarga de processamento para um grande número de nós nos clusters é minimizado.
**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 realms com um KDC, eles não confiarão inerentemente um no outro e seus aplicativos não poderão se autenticar entre si para interoperar.
+ KDCs devem ser mantidas de forma independente e coordenada para que as credenciais dos usuários principais correspondam com precisão.
## KDC externo
Configurações com um KDC externo são compatíveis com o Amazon EMR 5.20.0 e posteriores.
+ [KDC externo: MIT KDC](#emr-kerberos-extkdc-mit-summary)
+ [KDC externo: nó primário em um cluster diferente](#emr-kerberos-extkdc-cluster-summary)
+ [KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC externo: MIT KDC
Essa configuração permite que um ou mais clusters do EMR usem principais definidos e mantidos em um servidor KDC MIT.
![\[Amazon EMRcluster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado em um único KDC.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
+ O nó primário em um cluster kerberizado não tem o ônus da performance associada com a manutenção do KDC.
**Considerações e limitações**
+ Você deve criar usuários do Linux na instância do EC2 de cada nó primário do cluster kerberizado que corresponda às entidades principais de usuário do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar aos clusters Kerberizados usando SSH.
+ Cada nó nos clusters do EMR Kerberizados deve ter uma rota de rede para o KDC.
+ Cada nó nos clusters Kerberizados coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta o desempenho do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters Kerberizados e no KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
### KDC externo: nó primário em um cluster diferente
Essa configuração é quase idêntica à implementação do MIT KDC externo acima, porém o KDC está no nó primário de um cluster do EMR. Para obter mais informações, consulte [KDC dedicado ao cluster (KDC no nó primário)](#emr-kerberos-localkdc-summary) e [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do 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/pt_br/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado em um único KDC.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
**Considerações e limitações**
+ Você deve criar usuários do Linux na instância do EC2 de cada nó primário do cluster kerberizado que corresponda às entidades principais de usuário do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar aos clusters Kerberizados usando SSH.
+ Cada nó nos clusters do EMR deve ter uma rota de rede para o KDC.
+ Cada nó do Amazon EMR nos clusters kerberizados coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta a performance do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters e no KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
### KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory
Nessa configuração, você primeiro cria um cluster com um KDC dedicado ao cluster que tenha uma relação de confiança entre realms unidirecional 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](emr-kerberos-cross-realm.md). Em seguida, inicie clusters adicionais, fazendo referência ao KDC do cluster que tem a confiança como um KDC externo. Para ver um exemplo, consulte [KDC externo do cluster com relação de confiança entre realms do Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). Isso permite que cada cluster do Amazon EMR que usa o KDC externo autentique as entidades principais definidas e mantidas em um domínio do Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado no domínio do Active Directory.
+ O Amazon EMR ingressa no realm do Active Directory, o que elimina a necessidade de criar usuários do Linux que correspondam aos usuários do Active Directory. Ainda assim é necessário criar diretórios do HDFS para cada usuário.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
+ Os usuário principais no domínio do Active Directory podem acessar clusters Kerberizados usando credenciais `kinit`, sem o arquivo de chave privada do EC2. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.
+ Somente um nó primário do Amazon EMR tem a carga para manter o KDC, e somente esse cluster deve ser criado com as credenciais do Active Directory para a relação de confiança entre realms entre o KDC e o Active Directory.
**Considerações e limitações**
+ Cada nó nos clusters do EMR deve ter uma rota de rede para o KDC e o controlador de domínio do Active Directory.
+ Cada nó do Amazon EMR coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta a performance do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters e no servidor KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
## Requisitos para usar múltiplos clusters com o mesmo KDC
Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. No entanto, se os clusters forem executados simultaneamente, eles poderão falhar se usarem ServicePrincipal nomes Kerberos conflitantes.
Se você tiver múltiplos clusters simultâneos com o mesmo KDC externo, certifique-se de que os clusters usem regiões Kerberos diferentes. Se os clusters precisarem usar o mesmo realm do Kerberos, certifique-se de que os clusters estejam em sub-redes diferentes e que os intervalos de CIDR não se sobreponham.
# Configurar o Kerberos no Amazon EMR
Esta seção fornece detalhes da configuração e exemplos para configurar o Kerberos com arquiteturas comuns. Independentemente da arquitetura escolhida, as noções básicas de configuração são as mesmas e a configuração é feita em três etapas. Se usar um KDC externo ou configurar uma relação de confiança entre realms, você deverá garantir que cada nó em um cluster tenha uma rota de rede para o KDC externo, incluindo a configuração aplicável de grupos de segurança para permitir o tráfego de entrada e saída do Kerberos.
## Etapa 1: Criar uma configuração de segurança com propriedades do Kerberos
A configuração de segurança especifica detalhes sobre o KDC do Kerberos e permite que a configuração do Kerberos seja reutilizada cada vez que você criar um cluster. Você pode criar uma configuração de segurança usando o console do Amazon EMR AWS CLI, o ou a API do EMR. A configuração de segurança também pode conter outras opções de segurança, como criptografia. Para obter mais informações sobre como criar configurações de segurança e especificar uma configuração de segurança ao criar um cluster, consulte [Uso de configurações de segurança para definir a segurança do cluster do Amazon EMR](emr-security-configurations.md). Para obter informações sobre as propriedades do Kerberos em uma configuração de segurança, consulte [Configurações do Kerberos para configurações de segurança](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Etapa 2: Criar um cluster e especificar os atributos do Kerberos específicos do cluster
Ao criar um cluster, você especifica uma configuração de segurança do Kerberos juntamente com e as opções do Kerberos específicas do cluster. Quando o console do Amazon EMR é usado, somente as opções do Kerberos compatíveis com a configuração de segurança especificada estão disponíveis. Ao usar a API AWS CLI ou o Amazon EMR, certifique-se de especificar as opções do Kerberos compatíveis com a configuração de segurança especificada. Por exemplo, se você especificar uma senha principal para uma relação de confiança entre realms ao criar um cluster usando a CLI e a configuração de segurança especificada não for configurada com os parâmetros da relação de confiança entre realms, ocorrerá um erro. Para obter mais informações, consulte [Configurações do Kerberos para clusters](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Etapa 3: configurar o nó primário do cluster
Dependendo dos requisitos de sua arquitetura e implantação, configuração adicional no cluster pode ser necessária. Você pode fazer isso depois de criá-lo ou usando etapas ou ações de bootstrap durante o processo de criação.
Para cada usuário autenticado pelo Kerberos que se conecta ao cluster usando SSH, você deve garantir que as contas do Linux criadas correspondam ao usuário do Kerberos. Se as entidades principais forem fornecidos por um controlador de domínio do Active Directory, como o KDC externo ou por meio de uma relação de confiança entre realms, o Amazon EMR criará contas de usuário do Linux automaticamente. Se o Active Directory não for usado, você deverá criar principais para cada usuário que correspondam ao usuário do Linux. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
Cada usuário também deve ter um diretório de usuário do HDFS que pertença a eles, que você deve criar. Além disso, o SSH deve ser configurado com GSSAPI habilitada para permitir conexões de usuários autenticados pelo Kerberos. A GSSAPI deve ser habilitada no nó primário, e a aplicação SSH cliente deve ser configurada para usar GSSAPI. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
# Configuração de segurança e configurações do cluster para Kerberos no Amazon EMR
Ao criar um cluster Kerberizado, você especifica a configuração de segurança com atributos do Kerberos específicos do cluster. Você não pode especificar um conjunto sem o outro, ou ocorrerá um erro.
Este tópico fornece uma visão geral dos parâmetros de configuração disponíveis para o Kerberos quando você cria uma configuração de segurança e um cluster. Além disso, exemplos da CLI para criar configurações de segurança e clusters compatíveis são fornecidos para arquiteturas comuns.
## Configurações do Kerberos para configurações de segurança
Você pode criar uma configuração de segurança que especifique os atributos do Kerberos usando o console do Amazon EMR, o AWS CLI ou a API do EMR. A configuração de segurança também pode conter outras opções de segurança, como criptografia. Para obter mais informações, consulte [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md).
Use as referências a seguir para compreender as definições de configuração de segurança disponíveis para a arquitetura do Kerberos que você escolher. As configurações do console do Amazon EMR são exibidas. Para opções da CLI correspondentes, consulte [Especificando as configurações do Kerberos usando o AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) ou [Exemplos de configuração](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Configurações do Kerberos para clusters
Você pode especificar as configurações do Kerberos ao criar um cluster usando o console do Amazon EMR, o AWS CLI ou a API do EMR.
Use as referências a seguir para compreender as definições de configuração de cluster disponíveis para a arquitetura do Kerberos que você escolher. As configurações do console do Amazon EMR são exibidas. Para opções da CLI correspondentes, consulte [Exemplos de configuração](emr-kerberos-config-examples.md).
| Parâmetro | Description |
| --- | --- |
| Realm | O nome do realm do Kerberos para o cluster. A convenção do Kerberos deve ser a mesma do nome de domínio, mas em maiúsculas. Por exemplo, para o domínio `ec2.internal`, usando `EC2.INTERNAL` como o nome do realm. |
| Senha admin do KDC | A senha usada dentro do cluster para `kadmin` ou `kadmin.local`. Essas são interfaces de linha de comando para o sistema de administração do Kerberos V5, que mantém os principais do Kerberos, as políticas de senha e os keytabs do cluster. |
| Senha do principal da relação de confiança entre realms (opcional) | Obrigatório quando se estabelece uma relação de confiança entre realms. A senha do principal entre realms, que deve ser idêntica em todos os realms. Use uma senha forte. |
| Usuário de inclusão no domínio do Active Directory (opcional) | Obrigatório ao usar o Active Directory em uma relação de confiança entre realms. Este é o nome de logon de usuário de uma conta do Active Directory com permissão para integrar computadores ao domínio. O Amazon EMR usa essa identidade para integrar o cluster ao domínio. Para obter mais informações, consulte [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Senha de inclusão no domínio do Active Directory (opcional) | A senha para o usuário de inclusão no domínio do Active Directory. Para obter mais informações, consulte [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Exemplos de configuração
Os exemplos a seguir demonstram configurações de segurança e configurações de cluster para cenários comuns. AWS CLI os comandos são mostrados para fins de concisão.
## KDC local
Os comandos a seguir criam um cluster com um KDC dedicado ao cluster em execução no nó primário. Configurações adicionais no cluster podem ser necessárias. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Criar cluster**
```
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 ao cluster com relação de confiança entre realms do Active Directory
Os comandos a seguir criam um cluster com um KDC dedicado ao cluster em execução no nó primário com uma relação de confiança entre realms para um domínio do Active Directory. Configuração adicional no cluster e no Active Directory é necessária. Para obter mais informações, consulte [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md).
**Criar configuração de segurança**
```
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"}}}}}'
```
**Criar cluster**
```
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 em um cluster diferente
Os comandos a seguir criam um cluster que referencia um KDC dedicado ao cluster no nó primário de um cluster diferente para autenticar entidades principais. Configurações adicionais no cluster podem ser necessárias. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Criar cluster**
```
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 do cluster com relação de confiança entre realms do Active Directory
Os comandos a seguir criam um cluster sem nenhum KDC. O cluster faz referência a um KDC dedicado ao cluster em execução no nó primário de outro cluster para autenticar entidades principais. Esse KDC tem uma relação de confiança entre realms com um controlador de domínio do Active Directory. A configuração adicional no nó primário com o KDC é obrigatória. Para obter mais informações, consulte [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md).
**Criar configuração de segurança**
```
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"}}}}}'
```
**Criar cluster**
```
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
```
# Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH
O Amazon EMR cria clientes de usuário autenticados pelo Kerberos para aplicações executadas no cluster. Por exemplo, o usuário `hadoop`, o usuário `spark` e outros. Você também pode adicionar usuários autenticados em processos de cluster usando o Kerberos. Os usuários autenticados podem se conectar ao cluster usando as credenciais do Kerberos e trabalhar com os aplicativos. Para que um usuário faça autenticação no cluster, as seguintes configurações são necessárias:
+ Deve haver uma conta Linux que corresponda à entidade principal do Kerberos no KDC no cluster. O Amazon EMR faz isso automaticamente em arquiteturas que se integram ao Active Directory.
+ Você deve criar um diretório de usuário do HDFS no nó primário para cada usuário e conceder as permissões ao usuário para o diretório.
+ É necessário configurar o serviço SSH para que GSSAPI esteja habilitada no nó primário. Além disso, os usuários devem ter um cliente SSH com GSSAPI habilitada.
## Adicionar usuários do Linux e entidades principais do Kerberos ao nó primário
Se não usar o Active Directory, você deverá criar contas do Linux no nó primário do cluster e adicionar entidades principais a esses usuários do Linux para o KDC. Isso inclui uma entidade principal no KDC para o nó primário. Além dos usuários principais, o KDC em execução no nó primário precisa de uma entidade principal para o host local.
Quando sua arquitetura inclui integração com o Active Directory, os usuários do Linux e os principais no KDC local, se aplicável, são criados automaticamente. Você pode ignorar esta etapa. Para obter mais informações, consulte [Relação de confiança entre realms](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) e [KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**Importante**
O KDC, junto com o banco de dados de entidades principais, é perdido quando o nó primário é terminado porque o nó primário usa armazenamento temporário. Se você criar usuários para conexões SSH, é recomendável estabelecer uma relação de confiança entre regiões com um KDC externo configurado para alta disponibilidade. Como alternativa, se você criar usuários para conexões SSH usando contas Linux, automatize o processo de criação da conta usando ações e scripts de bootstrap de modo que possa ser repetido ao criar um novo cluster.
Enviar uma etapa ao cluster depois de criá-lo ou ao criar o cluster é a maneira mais fácil de adicionar usuários e principais do KDC. Como alternativa, você pode se conectar ao nó primário usando um par de chaves do EC2 como o usuário `hadoop` padrão para executar os comandos. Para obter mais informações, consulte [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md).
O exemplo a seguir envia um script bash `configureCluster.sh` para um cluster que já existe, fazendo referência ao ID do cluster. O script é salvo no 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"]
```
O exemplo a seguir demonstra o conteúdo do script `configureCluster.sh`. O script também trata da criação de diretórios do usuário do HDFS e habilita GSSAPI para SSH, que são abordados nas seções a seguir.
```
#!/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
```
## Adicionar diretórios do usuário do HDFS
Para permitir que os usuários façam login no cluster para executar trabalhos do Hadoop, você deve adicionar diretórios do usuário HDFS para contas do Linux e conceder a cada um a propriedade do diretório.
Enviar uma etapa ao cluster depois de criá-lo ou ao criar o cluster é a maneira mais fácil de criar diretórios do HDFS. Como alternativa, você pode se conectar ao nó primário usando um par de chaves do EC2 como o usuário `hadoop` padrão para executar os comandos. Para obter mais informações, consulte [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md).
O exemplo a seguir envia um script bash `AddHDFSUsers.sh` para um cluster que já existe, fazendo referência ao ID do cluster. O script é salvo no 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"]
```
O exemplo a seguir demonstra o conteúdo do 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
```
## Habilitar GSSAPI para SSH
Para usuários autenticados pelo Kerberos se conectarem ao nó primário usando o SSH, o serviço SSH deve ter a autenticação GSSAPI habilitada. Para habilitar GSSAPI, execute os seguintes comandos na linha de comando do nó primário ou use uma etapa para executá-lo como um script. Depois de reconfigurar o SSH, você deverá reiniciar o serviço.
```
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 se conectar a clusters kerberizados com o Amazon EMR
Esta seção demonstra as etapas para que um usuário autenticado pelo Kerberos se conecte ao nó primário de um cluster do EMR.
Cada computador que é usado para uma conexão SSH deve ter aplicativos cliente SSH e cliente Kerberos instalados. Os computadores Linux provavelmente incluem esses aplicativos por padrão. Por exemplo, a OpenSSH está instalada na maioria dos sistemas operacionais Unix, Linux e MacOS X. É possível verificar se existe um cliente SSH digitando **ssh** na linha de comando. Se o computador não reconhecer o comando, instale um cliente SSH para se conectar ao nó primário. O projeto OpenSSH fornece uma implementação grátis do pacote completo de ferramentas SSH. Para obter mais informações, consulte o site do [OpenSSH](http://www.openssh.org/). Os usuários do Windows podem usar aplicativos, como o [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/), como um cliente SSH.
Para obter mais informações sobre conexões SSH, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
O SSH usa GSSAPI para autenticar os clientes Kerberos, e você deve habilitar a autenticação GSSAPI para o serviço SSH no nó primário do cluster. Para obter mais informações, consulte [Habilitar GSSAPI para SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Os clientes SSH também devem usar GSSAPI.
Nos exemplos a seguir, *MasterPublicDNS* use o valor que aparece para **Master public DNS** na guia **Resumo** do painel de detalhes do cluster — por exemplo,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Pré-requisito para krb5.conf (que não é do Active Directory)
Ao usar uma configuração sem integração com o Active Directory, além das aplicações cliente SSH e cliente Kerberos, cada computador cliente deve ter uma cópia do arquivo `/etc/krb5.conf` que corresponde ao arquivo `/etc/krb5.conf` no nó primário do cluster.
**Para copiar o arquivo krb5.conf**
1. Use o SSH para se conectar ao nó primário usando um par de chaves do EC2 e o usuário `hadoop` padrão; por exemplo, `hadoop@MasterPublicDNS`. Para obter instruções detalhadas, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
1. No nó primário, copie o conteúdo do arquivo `/etc/krb5.conf`. Para obter mais informações, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
1. Em cada computador cliente que será usado para se conectar ao cluster, crie um arquivo `/etc/krb5.conf` idêntico com base na cópia feita na etapa anterior.
## Usar Kinit e SSH
Cada vez que um usuário se conecta a partir de um computador cliente usando credenciais do Kerberos, o usuário deve primeiro renovar tíquetes Kerberos para seu usuário no computador cliente. Além disso, o cliente SSH deve estar configurado para usar a autenticação GSSAPI.
**Para usar o SSH para se conectar a um cluster do EMR Kerberizado**
1. Use `kinit` para renovar os tíquetes Kerberos, conforme mostrado no exemplo a seguir
```
kinit user1
```
1. Use um cliente `ssh` juntamente com o principal que você criou no KDC dedicado ao cluster ou o nome de usuário do Active Directory. Certifique-se de que a autenticação GSSAPI esteja habilitada, conforme mostrado nos exemplos a seguir.
**Exemplo: usuários do Linux**
A opção `-K ` especifica a autenticação de GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Exemplo: usuários do Windows (PuTTY)**
Certifique-se de que a opção de autenticação GSSAPI para a sessão esteja habilitada conforme mostrado:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: configurar um KDC dedicado ao cluster com o Amazon EMR
Este tópico orienta você na criação de um cluster com um *centro de distribuição de chaves (KDC)* dedicado ao cluster, adicionando manualmente contas do Linux a todos os nós do cluster, adicionando entidades principais do Kerberos ao KDC no nó primário e garantindo que os computadores cliente tenham um cliente Kerberos instalado.
Para obter mais informações sobre o suporte do Amazon EMR para Kerberos e KDC, bem como links para a documentação do MIT Kerberos, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md).
## Etapa 1: criar o cluster kerberizado
1. Crie uma configuração de segurança que permita o Kerberos. O exemplo a seguir demonstra um `create-security-configuration` comando usando o AWS CLI que especifica a configuração de segurança como uma estrutura JSON embutida. Você também pode fazer referência a um arquivo salvo localmente.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Crie um cluster que faça referência à configuração de segurança, estabeleça os atributos do Kerberos para o cluster e adicione contas do Linux usando uma ação de bootstrap. O exemplo a seguir demonstra um comando `create-cluster ` usando a AWS CLI. O comando faz referência à configuração de segurança criada por você acima, `MyKerberosConfig`. Ele também faz referência a um script simples, `createlinuxusers.sh`, como uma ação de bootstrap, que você cria e carrega no Amazon S3 antes de criar o cluster.
```
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
```
O código a seguir demonstra o conteúdo do script `createlinuxusers.sh`, que adiciona user1, user2 e user3 a cada nó no cluster. Na próxima etapa, você adicionará esses usuários como principais do KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Etapa 2: adicionar entidades principais ao KDC, criar diretórios de usuário do HDFS e configurar o SSH
O KDC em execução no nó primário precisa de uma entidade principal adicionada para o host local e para cada usuário criado por você no cluster. Você também poderá criar diretórios do HDFS para cada usuário se eles precisarem se conectar ao cluster e executar trabalhos do Hadoop. Da mesma maneira, configure o SSH para habilitar a autenticação GSSAPI, necessária para o Kerberos. Depois de habilitar GSSAPI, reinicie o serviço SSH.
A maneira mais fácil de realizar essas tarefas é enviar uma etapa para o cluster. O exemplo a seguir envia um `configurekdc.sh` de script bash para o cluster que você criou na etapa anterior, referenciando o ID do cluster. O script é salvo no Amazon S3. Você também pode se conectar ao nó primário usando um par de chaves do EC2 para executar os comandos ou enviar a etapa durante a criação do cluster.
```
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"]
```
O código a seguir demonstra o conteúdo do 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
```
Os usuários que você adicionou agora devem poder se conectar ao cluster usando SSH. Para obter mais informações, consulte [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory
Ao configurar uma relação de confiança entre realms, você permite que os principais (normalmente usuários) de um realm do Kerberos diferente se autentiquem em componentes do aplicativo no cluster do EMR. O *centro de distribuição de chaves (KDC)* dedicado ao cluster estabelece uma relação de confiança com outro KDC usando um princípio *entre* domínios que existe em ambos. KDCs O nome do principal e a senha coincidem precisamente.
Uma relação de confiança entre realms exige que os KDCs possam se alcançar um ao outro pela rede e resolver os nomes de domínio um do outro. As etapas para estabelecer uma relação de confiança entre realms com um controlador de domínio do Microsoft AD em execução como uma instância do EC2 são apresentadas abaixo com uma configuração de rede de exemplo que oferece a conectividade e a resolução de nomes de domínio necessárias. Qualquer configuração de rede que permita o tráfego de rede necessário KDCs é aceitável.
Opcionalmente, depois de estabelecer uma relação de confiança entre realms com o Active Directory usando um KDC em um cluster, você poderá criar outro cluster usando uma configuração de segurança diferente para fazer referência ao KDC no primeiro cluster como um KDC externo. Para obter um exemplo de configuração de segurança e a configuração do cluster, consulte [KDC externo do cluster com relação de confiança entre realms do Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Para obter mais informações sobre o suporte do Amazon EMR para Kerberos e KDC, bem como links para a documentação do MIT Kerberos, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md).
**Importante**
O Amazon EMR não oferece suporte a relações de confiança entre regiões com. AWS Directory Service for Microsoft Active Directory
[Etapa 1: configurar a VPC e a sub-rede](#emr-kerberos-ad-network)
[Etapa 2: iniciar e instalar o controlador de domínio do Active Directory](#emr-kerberos-ad-dc)
[Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](#emr-kerberos-ad-users)
[Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory](#emr-kerberos-ad-configure-trust)
[Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC](#emr-kerberos-ad-DHCP)
[Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster)
[Etapa 7: criar usuários HDFS e definir permissões no cluster para contas do Active Directory](#emr-kerberos-ad-hadoopuser)
## Etapa 1: configurar a VPC e a sub-rede
As etapas a seguir demonstram como criar uma VPC e uma sub-rede, de maneira que o KDC dedicado ao cluster possa alcançar o controlador de domínio do Active Directory e resolver o nome de domínio. Nessas etapas, a resolução de nomes de domínio é fornecida referenciando-se o controlador de domínio do Active Directory como o servidor de nomes de domínio no conjunto de opções DHCP. Para obter mais informações, consulte [Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC](#emr-kerberos-ad-DHCP).
O KDC e o controlador de domínio do Active Directory devem poder resolver os nomes de domínio um do outro. Isso permite ao Amazon EMR adicionar computadores ao domínio e configurar automaticamente as contas do Linux correspondentes e os parâmetros SSH em instâncias de cluster.
Se o Amazon EMR não conseguir resolver o nome de domínio, você poderá referenciar a relação de confiança usando o endereço IP do controlador de domínio do Active Directory. No entanto, você deve adicionar manualmente contas do Linux, adicionar entidades principais correspondentes ao KDC dedicado ao cluster e configurar o SSH.
**Para configurar a VPC e a sub-rede**
1. Crie uma Amazon VPC com uma única sub-rede pública. Para obter mais informações, consulte [Step 1: Create the VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) no *Amazon VPC Getting Started Guide*.
**Importante**
Ao usar um controlador de domínio do Microsoft Active Directory, escolha um bloco CIDR para o cluster do EMR de forma que IPv4 todos os endereços tenham menos de nove caracteres (por exemplo, 10.0.0.0/16). Isso ocorre porque os nomes DNS dos computadores de cluster são usados quando os computadores ingressam no diretório do Active Directory. AWS atribui [nomes de host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) com base no IPv4 endereço de forma que endereços IP mais longos possam resultar em nomes DNS com mais de 15 caracteres. O Active Directory tem um limite de 15 caracteres para registrar nomes de computador adicionados e trunca nomes mais longos, o que pode causar erros imprevisíveis.
1. Remova o conjunto de opções DHCP padrão atribuído à VPC. Para obter mais informações, consulte [Changing a VPC to use No DHCP options](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Posteriormente, você adicionará um novo especificando o controlador de domínio do Active Directory como o servidor DNS.
1. Confirme se o suporte DNS está habilitado para a VPC, ou seja, se os nomes de host e a resolução DNS estão habilitados. Por padrão, as transições estão ativadas. Para obter mais informações, consulte [Updating DNS support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Confirme se a VPC tem um gateway da Internet anexado, que é o padrão. Para mais informações, consulte [Criar e anexar um gateway da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**nota**
Um gateway da Internet é usado neste exemplo porque você está estabelecendo um novo controlador de domínio para a VPC. O gateway da Internet talvez não seja necessário para o aplicativo. O único requisito é que o KDC dedicado ao cluster possa acessar o controlador de domínio do Active Directory.
1. Crie uma tabela de rotas personalizada, adicione uma rota com o gateway da Internet como destino e a anexe à sub-rede. Para obter mais informações, consulte [Criar uma tabela de rotas personalizada](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Quando você executa a instância do EC2 para o controlador de domínio, ela deve ter um IPv4 endereço público estático para que você possa se conectar a ela usando o RDP. A maneira mais fácil de fazer isso é configurar sua sub-rede para atribuir endereços públicos IPv4 automaticamente. Não se trata da configuração padrão quando uma sub-rede é criada. Para obter mais informações, consulte [Modificação do atributo de IPv4 endereçamento público da sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Você também pode atribuir o endereço ao iniciar a instância. Para obter mais informações, consulte [Atribuição de um IPv4 endereço público durante a execução da instância](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Ao terminar, anote sua VPC e sua sub-rede. IDs Você os usará depois quando iniciar o controlador de domínio do Active Directory e o cluster.
## Etapa 2: iniciar e instalar o controlador de domínio do Active Directory
1. Inicie uma instância do EC2 com base na AMI Microsoft Windows Server 2016 Base. Recomendamos um tipo de instância m4.xlarge ou melhor. Para obter mais informações, consulte [Executar uma instância do AWS Marketplace](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) no *Guia do usuário do Amazon EC2*.
1. Anote o ID do grupo de segurança associado à instância do EC2. Você precisa dele para o [Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster). Nós usamos*sg-012xrlmdomain345*. Opcionalmente, você pode especificar grupos de segurança diferentes para o cluster do EMR e essa instância que permite o tráfego entre eles. Para obter mais informações, consulte [Grupos de segurança do Amazon EC2 para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) no *Guia do usuário do Amazon EC2*.
1. Conecte-se à instância do EC2 usando o RDP. Para obter mais informações, consulte [Conectar-se à sua instância baseada no Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) no *Guia do usuário do Amazon EC2*.
1. Inicie o **Server Manager** para instalar e configurar o perfil Active Directory Domain Services no servidor. Promova o servidor para um controlador de domínio e atribua um nome de domínio (o exemplo que usamos aqui é `ad.domain.com`). Anote o nome de domínio porque você vai precisar dele depois ao criar a configuração de segurança do EMR e o cluster. Se estiver começando a configurar o Active Directory, você poderá seguir as instruções em [How to setup Active Directory (AD) In Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
A instância será reiniciada quando você terminar.
## Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR
Use o RDP para o controlador de domínio do Active Directory para criar contas em usuários e computadores do Active Directory para cada usuário do cluster. Para obter mais informações, consulte [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) no site *Microsoft Learn*. Anote o **User logon name (Nome de logon do usuário)** de cada usuário. Você precisará dele mais tarde ao configurar o cluster.
Além disso, crie uma conta com privilégios suficientes para integrar computadores ao domínio. Você especifica essa conta ao criar um cluster. O Amazon EMR a usa para integrar instâncias de cluster ao domínio. Você especifica essa conta e a senha em [Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster). Para delegar privilégios de integração do computador à conta, recomendamos criar um grupo com privilégios de junção e, em seguida, atribuir o usuário ao grupo. Para obter instruções, consulte [Delegating directory join privileges](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) no *Guia de administração AWS Directory Service *.
## Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory
Os comandos de exemplo abaixo criam uma relação de confiança no Active Directory, que é uma relação de confiança de realm unidirecional, de entrada e não transitiva com o KDC dedicado ao cluster. O exemplo que usamos para no realm do cluster é `EC2.INTERNAL`. *KDC-FQDN*Substitua o pelo nome **DNS público** listado para o nó primário do Amazon EMR que hospeda o KDC. O parâmetro `passwordt` especifica a **cross-realm principal password (senha da entidade principal entre realms)**, determinada por você com o **realm** do cluster ao criar um cluster. O nome do realm deriva do nome de domínio padrão em `us-east-1` para o cluster. O `Domain` é o domínio do Active Directory no qual você está criando a confiança, que é em minúscula por convenção. O exemplo usa `ad.domain.com`
Abra o prompt de comando do Windows com privilégios de administrador e digite os seguintes comandos para criar a relação de confiança no controlador de domínio do 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
```
## Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC
Agora que o controlador de domínio do Active Directory está configurado, você deve configurar a VPC para usá-lo como um servidor de nomes de domínio para resolução de nomes em sua VPC. Para isso, anexe um conjunto de opções DHCP. Especifique o **Nome do domínio** como o nome de domínio do cluster. Por exemplo, `ec2.internal` caso o cluster esteja em us-east-1 ou `region.compute.internal` para outras regiões. Para **servidores de nomes de domínio**, você deve especificar o endereço IP do controlador de domínio do Active Directory (que deve ser acessível a partir do cluster) como a primeira entrada, seguido pelo **AmazonProvidedDNS** (por exemplo ***xx.xx.xx.xx*, AmazonProvided** DNS). Para obter mais informações, consulte [Changing DHCP option sets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Etapa 6: Iniciar um cluster EMR Kerberizado
1. No Amazon EMR, crie uma configuração de segurança que especifique o controlador de domínio do Active Directory criado por você nas etapas anteriores. Um comando de exemplo é mostrado abaixo. Substitua o domínio, `ad.domain.com`, pelo nome do domínio especificado por você em [Etapa 2: iniciar e instalar o controlador de domínio do 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. Crie o cluster com os seguintes atributos:
+ Use a opção `--security-configuration` para especificar a configuração de segurança que você criou. Usamos *MyKerberosConfig* no exemplo.
+ Use a propriedade `SubnetId` da `--ec2-attributes option` para especificar a sub-rede que você criou em [Etapa 1: configurar a VPC e a sub-rede](#emr-kerberos-ad-network). Usamos *step1-subnet* no exemplo.
+ Use `AdditionalMasterSecurityGroups` e `AdditionalSlaveSecurityGroups` da opção `--ec2-attributes` para especificar que o grupo de segurança associado ao controlador de domínio AD do [Etapa 2: iniciar e instalar o controlador de domínio do Active Directory](#emr-kerberos-ad-dc) está associado ao nó primário do cluster, bem como aos nós centrais e de tarefa. Usamos *sg-012xrlmdomain345* no exemplo.
Use `--kerberos-attributes` para especificar os seguintes atributos Kerberos específicos ao cluster:
+ O realm do cluster especificado por você ao configurar o controlador de domínio do Active Directory.
+ A senha da entidade principal da relação de confiança entre realms especificada por você como `passwordt` em [Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory](#emr-kerberos-ad-configure-trust).
+ Um `KdcAdminPassword`, que você pode usar para administrar o KDC dedicado ao cluster.
+ O nome de logon do usuário e a senha da conta do Active Directory com privilégios de ingresso no computador criados por você em [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](#emr-kerberos-ad-users).
O exemplo a seguir inicia um cluster kerberizado.
```
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
```
## Etapa 7: criar usuários HDFS e definir permissões no cluster para contas do Active Directory
Ao configurar uma relação de confiança com o Active Directory, o Amazon EMR cria usuários do Linux no cluster para cada conta do Active Directory. Por exemplo, o nome de logon de usuário `LiJuan` no Active Directory tem uma conta do Linux de `lijuan`. Os nomes de usuário do Active Directory podem conter letras maiúsculas, mas o Linux não segue o uso de maiúsculas e minúsculas do Active Directory.
Para permitir que os usuários façam login no cluster para executar trabalhos do Hadoop, você deve adicionar diretórios do usuário HDFS para contas do Linux e conceder a cada um a propriedade do diretório. Para isso, recomendamos executar um script salvo no Amazon S3 como uma etapa de cluster. Você também pode executar os comandos no script abaixo da linha de comando no nó primário. Use o par de chaves do EC2 especificado por você quando criou o cluster para se conectar ao nó primário via SSH como o usuário do Hadoop. Para obter mais informações, consulte [Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR](emr-plan-access-ssh.md).
Execute o comando a seguir para adicionar uma etapa ao cluster que executa um 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"]
```
O conteúdo do arquivo *AddHDFSUsers.sh* é o seguinte.
```
#!/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 do Active Directory mapeados para grupos do Hadoop
O Amazon EMR usa o Daemon do System Security Services (SSD) para mapear grupos do Active Directory para grupos do Hadoop. Para confirmar mapeamentos de grupos, depois de fazer login no nó primário, conforme descrito em [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md), você poderá usar o comando `hdfs groups` para confirmar que os grupos do Active Directory aos quais sua conta do Active Directory pertence foram mapeados para os grupos do Hadoop para o usuário correspondente do Hadoop no cluster. Você também pode verificar mapeamentos de grupos de outros usuários especificando um ou mais nomes de usuário usando, por exemplo, o comando `hdfs groups lijuan`. Para obter mais informações, consulte [grupos](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) no [Guia de comandos HDFS do Apache](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Usar servidores Active Directory ou LDAP para autenticação com o Amazon EMR
Com o Amazon EMR 6.12.0 e versões posteriores, você pode usar o protocolo LDAP sobre SSL (LDAPS) para iniciar um cluster que se integra de forma nativa ao servidor de identidade corporativo. O Lightweight Directory Access Protocol (LDAP) é um protocolo de aplicação aberto e independente de fornecedor que acessa e mantém dados. O LDAP é bastante usado para autenticação de usuários em servidores de identidade corporativa hospedados em aplicações como o Active Directory (AD) e o OpenLDAP. Com essa integração nativa, você pode usar o servidor LDAP para autenticar usuários no Amazon EMR.
Os destaques da integração do LDAP do Amazon EMR incluem:
+ O Amazon EMR configura as aplicações compatíveis para se autenticarem com a autenticação LDAP em seu nome.
+ O Amazon EMR configura e mantém a segurança das aplicações compatíveis com o protocolo Kerberos. Não é necessário inserir nenhum comando ou script.
+ Você recebe controle de acesso refinado (FGAC) por meio da autorização do Apache Ranger para bancos de dados e tabelas do Hive Metastore. Consulte [Integrar o Amazon EMR com o Apache Ranger](emr-ranger.md) para obter mais informações.
+ Ao necessitar de credenciais LDAP para acessar um cluster, você recebe controle de acesso refinado (FGAC) sobre quem pode acessar seus clusters do EMR por meio de SSH.
As páginas a seguir fornecem uma visão geral conceitual, os pré-requisitos e as etapas para iniciar um cluster do EMR com a integração LDAP do Amazon EMR.
**Topics**
+ [Visão geral do LDAP com o Amazon EMR](ldap-overview.md)
+ [Componentes LDAP para Amazon EMR](ldap-components.md)
+ [Suporte de aplicações e considerações com o LDAP para Amazon EMR](ldap-considerations.md)
+ [Configurar e iniciar um cluster do EMR com LDAP](ldap-setup.md)
+ [Exemplos usando o LDAP com Amazon EMR](ldap-examples.md)
# Visão geral do LDAP com o Amazon EMR
O Lightweight Directory Access Protocol (LDAP) é um protocolo de software que os administradores de rede usam para gerenciar e controlar o acesso aos dados por meio da autenticação de usuários na rede de uma empresa. O protocolo LDAP armazena informações em uma estrutura hierárquica de diretórios em árvore. Para obter mais informações, consulte [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/) no *LDAP.com*.
Na rede de uma empresa, muitas aplicações podem usar o protocolo LDAP para autenticar usuários. Com a integração LDAP do Amazon EMR, os clusters do EMR podem usar o mesmo protocolo LDAP de maneira nativa com uma configuração de segurança adicionada.
Há duas implementações principais do protocolo LDAP compatíveis com o Amazon EMR: **Active Directory** e **OpenLDAP**. Há outras implementações possíveis, mas a maioria se encaixa nos mesmos protocolos de autenticação do Active Directory ou do OpenLDAP.
## Active Directory (AD)
O Active Directory (AD) é um serviço de diretório da Microsoft para redes de domínio Windows. O AD está incluído na maioria dos sistemas operacionais Windows Server e pode se comunicar com clientes pelos protocolos LDAP e LDAPS. Para autenticação, o Amazon EMR tenta usar a associação do usuário com a instância do AD com o nome da entidade principal do usuário (UPN) como nome e senha distintos. O UPN usa o formato padrão `username@domain_name`.
## OpenLDAP
O OpenLDAP é uma implementação gratuita e de código aberto do protocolo LDAP. Para autenticação, o Amazon EMR tenta usar a associação do usuário com a instância do OpenLDAP com o nome de domínio totalmente qualificado (FQDN) como nome distinto e senha. O FQDN usa o formato padrão `username_attribute=username,LDAP_user_search_base`. Normalmente, o valor de `username_attribute` é `uid`, e o valor de `LDAP_user_search_base` contém os atributos da árvore que leva ao usuário. Por exemplo, .`ou=People,dc=example,dc=com`
Outras implementações gratuitas e de código aberto do protocolo LDAP normalmente seguem um FQDN semelhante ao OpenLDAP para os nomes distintos dos respectivos usuários.
# Componentes LDAP para Amazon EMR
Você pode usar seu servidor LDAP para se autenticar no Amazon EMR e em qualquer aplicação que o usuário utilize diretamente no cluster do EMR por meio dos componentes a seguir.
**Agente secreto**
O *agente secreto* é um processo no cluster que autentica todas as solicitações do usuário. O agente secreto cria a associação do usuário para o servidor LDAP em nome das aplicações compatíveis com o cluster do EMR. O agente secreto é executado como o usuário `emrsecretagent` e grava logs no diretório `/emr/secretagent/log`. Esses logs fornecem detalhes sobre o estado da solicitação de autenticação de cada usuário e os erros que possam surgir durante a autenticação do usuário.
**System Security Services Daemon (SSSD)**
O *SSSD* é um daemon executado em cada nó de um cluster do EMR habilitado para LDAP. O SSSD cria e gerencia um usuário UNIX para sincronizar sua identidade corporativa remota com cada nó. Aplicações baseadas em YARN, como o Hive e o Spark, exigem que haja um usuário UNIX local em cada nó que executa uma consulta para um usuário.
# Suporte de aplicações e considerações com o LDAP para Amazon EMR
Este tópico lista aplicações compatíveis, recursos compatíveis e recursos não compatíveis.
## Aplicações compatíveis com LDAP para Amazon EMR
**Importante**
As aplicações listadas nesta página são as únicas com suporte do Amazon EMR para LDAP. Para garantir a segurança do cluster, só é possível incluir aplicações compatíveis com LDAP ao criar um cluster do EMR com o LDAP habilitado. Se você tentar instalar outras aplicações sem suporte, o Amazon EMR rejeitará a solicitação de um novo cluster.
O Amazon EMR 6.12 e versões posteriores oferece suporte à integração LDAP com as seguintes aplicações:
+ Apache Livy
+ Apache Hive até HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
Também é possível instalar as seguintes aplicações em um cluster do EMR e configurá-las para atender a suas necessidades de segurança:
+ Apache Spark
+ Apache Hadoop
## Atributos compatíveis com LDAP para Amazon EMR
É possível usar os seguintes recursos do Amazon EMR com a integração do LDAP:
**nota**
Para manter as credenciais LDAP seguras, é necessário usar criptografia em trânsito para proteger o fluxo de dados dentro e fora do cluster. Para obter mais informações sobre criptografia em trânsito, consulte [Criptografia de dados em repouso e em trânsito com o Amazon EMR](emr-data-encryption.md).
+ Criptografia em trânsito (obrigatório) e em repouso
+ Grupos de instâncias, frotas de instâncias e instâncias spot
+ Reconfiguração de aplicações em um cluster em execução
+ Criptografia do lado do servidor (SSE) do EMRFS
## Atributos não compatíveis
Considere as seguintes limitações ao usar a integração do LDAP com Amazon EMR:
+ O Amazon EMR desabilita etapas para clusters com o LDAP habilitado.
+ O Amazon EMR não oferece suporte a funções e AWS Lake Formation integrações de tempo de execução para clusters com LDAP habilitado.
+ O Amazon EMR não oferece suporte a LDAP com StartTLS.
+ O Amazon EMR não oferece suporte ao modo de alta disponibilidade (clusters com múltiplos nós primários) para clusters com LDAP habilitado.
+ Não é possível alternar credenciais ou certificados de vinculação para clusters com LDAP habilitado. Se algum desses campos tiver sido alternado, é recomendável iniciar um novo cluster com as credenciais ou certificados de vinculação atualizados.
+ Você deve usar bases de pesquisa exatas com o LDAP. A base de pesquisa de usuários e grupos do LDAP não oferece suporte aos filtros de pesquisa do LDAP.
# Configurar e iniciar um cluster do EMR com LDAP
Esta seção aborda como configurar o Amazon EMR para uso com autenticação LDAP.
**Topics**
+ [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md)
+ [Criar a configuração de segurança do Amazon EMR para integração com LDAP](ldap-setup-security.md)
+ [Iniciar um cluster do EMR que se autentique com LDAP](ldap-setup-launch.md)
# Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR
O Amazon EMR usa um perfil de serviço do IAM para realizar ações a seu favor a fim de provisionar e gerenciar clusters. O perfil de serviço para instâncias do EC2 do cluster, também chamada de *perfil de instância do EC2 para Amazon EMR*, é um tipo especial de perfil de serviço que o Amazon EMR atribui ao iniciar cada instância do EC2 do cluster.
Para definir permissões para que um cluster do EMR interaja com dados do Amazon S3 e outros serviços da AWS , defina um perfil de instância personalizado do Amazon EC2 no lugar de `EMR_EC2_DefaultRole` ao executar o cluster. Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md) e [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md).
Adicione as seguintes instruções ao perfil de instância padrão do EC2 para permitir que o Amazon EMR marque sessões e acesse AWS Secrets Manager aquelas que armazenam certificados LDAP.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**nota**
Suas solicitações de cluster falharão se você esquecer o caractere curinga `*` no final do nome do segredo ao definir as permissões do Secrets Manager. O curinga representa as versões do segredo.
Você também deve limitar o escopo da AWS Secrets Manager política somente aos certificados que seu cluster precisa para provisionar instâncias.
# Criar a configuração de segurança do Amazon EMR para integração com LDAP
Antes de iniciar um cluster do EMR com integração com LDAP, use as etapas descritas em [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md) para criar uma configuração de segurança do Amazon EMR para o cluster. Complete as seguintes configurações no bloco de `LDAPConfiguration` em `AuthenticationConfiguration` ou nos campos correspondentes na seção **Configurações de segurança** do console do Amazon EMR:
**`EnableLDAPAuthentication`**
Opção do console: **Protocolo de autenticação: LDAP**
Para usar a integração com LDAP, defina essa opção como `true` ou selecione-a como protocolo de autenticação ao criar um cluster no console. Por padrão, `EnableLDAPAuthentication` é `true` ao criar uma configuração de segurança no console do Amazon EMR.
**`LDAPServerURL`**
Opção do console: **local do servidor LDAP**
A localização do servidor LDAP, incluindo o prefixo: `ldaps://location_of_server`.
**`BindCertificateARN`**
Opção do console: **certificado SSL LDAP**
O AWS Secrets Manager ARN que contém o certificado para assinar o certificado SSL que o servidor LDAP usa. Se seu servidor LDAP for assinado por uma Autoridade Certificadora (CA) pública, você poderá fornecer um AWS Secrets Manager ARN com um arquivo em branco. Para obter mais informações sobre como armazenar seu certificado no Secrets Manager, consulte [Armazene certificados TLS em AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opção do console: **credenciais de vinculação do servidor LDAP**
Um AWS Secrets Manager ARN que contém as credenciais de associação do usuário administrador do LDAP. As credenciais são armazenadas como objeto JSON. Há somente um par de chave-valor nesse segredo; a chave no par é o nome de usuário e o valor é a senha. Por exemplo, .`{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}` Esse é um campo opcional, a menos que você habilite o login SSH para o cluster do EMR. Em muitas configurações, as instâncias do Active Directory exigem credenciais de vinculação para permitir que o SSSD sincronize usuários.
**`LDAPAccessFilter`**
Opção do console: **filtro de acesso LDAP**
Especifica o subconjunto de objetos no servidor LDAP que podem ser autenticados. Por exemplo, para conceder acesso a todos os usuários com a classe de objeto `posixAccount` no servidor LDAP, defina o filtro de acesso como `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opção do console: **base de pesquisa de usuários LDAP**
A base de pesquisa à qual seus usuários pertencem no servidor LDAP. Por exemplo, .`cn=People,dc=example,dc=com`
**`LDAPGroupSearchBase`**
Opção de console: **base de pesquisa de grupos LDAP**
A base de pesquisa à qual seus grupos pertencem no servidor LDAP. Por exemplo, .`cn=Groups,dc=example,dc=com`
**`EnableSSHLogin`**
Opção do console: **login SSH**
Especifica se a autenticação por senha com credenciais LDAP deverá ou não ser permitida. Não é recomendável habilitar essa opção. Os pares de chaves são uma rota mais segura para permitir o acesso aos clusters do EMR. Esse campo é opcional e usa o padrão `false`.
**`LDAPServerType`**
Opção de console: **tipo de servidor LDAP**
Especifica o tipo de servidor LDAP ao qual o Amazon EMR se conectará. As opções compatíveis são Active Directory e OpenLDAP. Outros tipos de servidor LDAP podem funcionar, mas o Amazon EMR não é oficialmente compatível com outros tipos de servidor. Para obter mais informações, consulte [Componentes LDAP para Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Um sub-bloco necessário para configurações de segurança que utilizam o tipo de servidor Active Directory.
**`ADDomain`**
Opção do console: **domínio do Active Directory**
O nome de domínio usado para criar o nome da entidade principal do usuário (UPN) para autenticação do usuário com configurações de segurança que usam o tipo de servidor Active Directory.
## Considerações sobre configurações de segurança com LDAP e Amazon EMR
+ Para criar uma configuração de segurança com a integração LDAP do Amazon EMR, é necessário usar criptografia em trânsito. Para obter informações sobre criptografia em trânsito, consulte [Criptografia de dados em repouso e em trânsito com o Amazon EMR](emr-data-encryption.md).
+ Não é possível definir a configuração do Kerberos na mesma configuração de segurança. O Amazon EMR provisiona um KDC que é dedicado automaticamente e gerencia a senha de administrador para o KDC. Os usuários não poderão acessar essa senha de administrador.
+ Você não pode definir funções de tempo de execução do IAM e AWS Lake Formation na mesma configuração de segurança.
+ `LDAPServerURL` deve ter o protocolo `ldaps://` em seu valor.
+ `LDAPAccessFilter` não pode estar vazio.
## Usar o LDAP com a integração do Apache Ranger para Amazon EMR
Com a integração LDAP para Amazon EMR, é possível se integrar ainda mais com o Apache Ranger. Ao inserir seus usuários LDAP no Ranger, você pode associar esses usuários a um servidor de políticas Apache Ranger para integração com o Amazon EMR e outras aplicações. Para isso, defina o campo `RangerConfiguration` em `AuthorizationConfiguration` na configuração de segurança que você usa com o cluster do LDAP. Para obter mais informações sobre como definir a configuração de segurança, consulte [Criar a configuração de segurança do EMR](emr-ranger-security-config.md).
Ao usar o LDAP com o Amazon EMR, não é necessário fornecer uma `KerberosConfiguration` com a integração com o Amazon EMR para Apache Ranger.
# Iniciar um cluster do EMR que se autentique com LDAP
Realize as etapas a seguir para iniciar um cluster do EMR com LDAP ou Active Directory.
1. Configure o ambiente:
+ Certifique-se de que os nós em seu cluster do EMR possam se comunicar com o Amazon S3 e. AWS Secrets Manager Para obter mais informações sobre como modificar seu perfil do perfil de instância do EC2 para se comunicar com esses serviços, consulte [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md).
+ Se você planeja executar seu cluster do EMR em uma sub-rede privada, você deve usar endpoints da AWS PrivateLink Amazon VPC ou usar a tradução de endereços de rede (NAT) para configurar a VPC para se comunicar com o S3 e o Secrets Manager. Para obter mais informações, consulte [AWS PrivateLink and VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) e [NAT instances](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) no *Amazon VPC Getting Started Guide*.
+ Verifique se há conectividade de rede entre o cluster do EMR e o servidor LDAP. Seus clusters do EMR devem acessar o servidor LDAP pela rede. Os nós primário, central e de tarefa do cluster se comunicam com o servidor LDAP para sincronizar os dados do usuário. Se o servidor LDAP for executado no Amazon EC2, atualize o grupo de segurança do EC2 para aceitar o tráfego do cluster do EMR. Para obter mais informações, consulte [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md).
1. Criar uma configuração de segurança do Amazon EMR para integração com LDAP. Para obter mais informações, consulte [Criar a configuração de segurança do Amazon EMR para integração com LDAP](ldap-setup-security.md).
1. Agora que você está configurado, use as etapas descritas em [Inicialização de um cluster do Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) para iniciar o cluster com as seguintes configurações:
+ Selecione Amazon EMR versão 6.12 ou posterior. É recomendável usar a versão mais recente do Amazon EMR.
+ Especifique ou selecione somente aplicações para o cluster compatíveis com LDAP. Para obter uma lista de aplicações compatíveis com LDAP com o Amazon EMR, consulte [Suporte de aplicações e considerações com o LDAP para Amazon EMR](ldap-considerations.md).
+ Aplique a configuração de segurança criada na etapa anterior.
# Exemplos usando o LDAP com Amazon EMR
Depois de [provisionar um cluster do EMR que usa a integração com LDAP](ldap-setup-launch.md), você pode fornecer suas credenciais LDAP para qualquer [aplicação compatível](ldap-considerations.md#ldap-considerations-apps) por meio de seu mecanismo de autenticação de nome de usuário e senha incorporado. Esta página mostra alguns exemplos.
## Usar a autenticação LDAP com o Apache Hive
**Example - Apache Hive**
O comando de exemplo a seguir inicia uma sessão do Apache Hive por meio de HiveServer 2 e Beeline:
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Usar a autenticação LDAP com o Apache Livy
**Example - Apache Livy**
O comando de exemplo a seguir inicia uma sessão do Livy por cURL. Substitua `ENCODED-KEYPAIR` com uma string codificada em Base64 por `username:password`.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Usar autenticação do LDAP com o Presto
**Example - Presto**
O comando de exemplo a seguir inicia uma sessão do Presto pela CLI do Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Após executar esse comando, digite a senha do LDAP no prompt.
## Usar a autenticação LDAP com o Trino
**Example - Trino**
O comando de exemplo a seguir inicia uma sessão do Trino pela CLI do Trino:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Após executar esse comando, digite a senha do LDAP no prompt.
## Usar a autenticação LDAP com o Hue
Você pode acessar a interface do usuário do Hue por um túnel SSH criado no cluster ou pode configurar um servidor proxy para transmitir publicamente a conexão com o Hue. Como o Hue não é executado no modo HTTPS por padrão, é recomendável usar uma camada de criptografia adicional para garantir que a comunicação entre os clientes e a interface do usuário do Hue seja criptografada com HTTPS. Isso reduz a chance de expor acidentalmente as credenciais do usuário em texto sem formatação.
Para usar a interface do usuário do Hue, abra a interface do usuário do Hue no navegador e digite a senha do nome de usuário LDAP para fazer login. Se as credenciais estiverem corretas, o Hue fará login e usará sua identidade para autenticar você em todas as aplicações compatíveis.
## Usar SSH para autenticação por senha e tíquetes do Kerberos para outras aplicações
**Importante**
Não é recomendável usar a autenticação por senha com um cluster do EMR.
Você pode usar suas credenciais LDAP para fazer SSH em um cluster do EMR. Para isso, defina a configuração `EnableSSHLogin` como `true` na configuração de segurança do Amazon EMR usada para iniciar o cluster. Depois, use o comando a seguir para SSH no cluster depois que ele for iniciado:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Após executar esse comando, digite a senha do LDAP no prompt.
O Amazon EMR inclui um script no cluster que permite aos usuários gerar um arquivo keytab e um tíquete do Kerberos para usar com aplicações compatíveis que não aceitam credenciais LDAP diretamente. Alguns desses aplicativos incluem `spark-submit` Spark SQL e. PySpark
Execute `ldap-kinit` e siga as instruções. Se a autenticação tiver êxito, o arquivo keytab do Kerberos será exibido no diretório inicial com um tíquete do Kerberos válido. Use o tíquete do Kerberos para executar aplicações como você faria em qualquer ambiente kerberizado.