Simplifique a autenticação com integração LDAP nativa no Amazon EMR | Amazon Web Services

Muitas empresas têm identidades corporativas armazenadas em provedores de identidade (IdPs), como Active Directory (AD) ou OpenLDAP. Anteriormente, os clientes que usavam Amazon EMR poderiam integrar seus clusters com o Active Directory configurando uma confiança de território unidirecional entre seu domínio AD e o domínio Kerberos do cluster EMR. Para mais detalhes, consulte Tutorial: Configurar uma relação de confiança entre domínios com um domínio do Active Directory.

Esta configuração tem sido um facilitador chave para disponibilizar usuários e grupos corporativos dentro de clusters EMR e definir políticas de controle de acesso para controlar seu acesso aos dados (por exemplo, através do Integração nativa do Amazon EMR com o Apache Ranger).

Embora esta opção ainda esteja disponível, o Amazon EMR lançou suporte para autenticação LDAP nativa, um novo recurso de segurança que simplifica a integração com OpenLDAP e Active Directory.

Este recurso permite o seguinte:

configuração automática de segurança para os aplicativos suportados (HiveServer2, Trino, Presto e Livy) para usar o protocolo Kerberos subjacente e LDAP como autenticação externa. Isso permite uma integração mais direta de ferramentas externas que, para se conectarem aos endpoints do cluster, não precisam mais configurar a autenticação Kerberos, mas, em vez disso, podem simplesmente ser configuradas para fornecer um nome de usuário e uma senha LDAP
controle de acesso refinado (FGAC) sobre quem pode acessar seus clusters EMR por meio de SSH
políticas de autorização refinadas sobre o banco de dados e tabelas do Hive Metastore, se usadas em combinação com a integração nativa do Amazon EMR Apache Ranger.

Nesta postagem, nos aprofundamos na autenticação LDAP do Amazon EMR, mostrando como funciona o fluxo de autenticação, como recuperar e testar as configurações LDAP necessárias e como confirmar se um cluster EMR está devidamente integrado ao LDAP.

Usando as informações deste blog:

As equipes que gerenciam clusters EMR podem melhorar a coordenação com seus administradores IdP LDAP para solicitar as informações adequadas e realizar testes de pré-configuração de maneira adequada.
Os usuários finais do cluster EMR podem entender como é simples conectar-se de ferramentas externas a clusters EMR habilitados para LDAP em comparação com a autenticação anterior baseada em Kerberos

Como funciona a integração LDAP do Amazon EMR

Ao falar sobre autenticação no contexto das estruturas EMR, podemos distinguir entre dois níveis:

Autenticação externa – Usado por usuários e componentes externos para interagir com os frameworks instalados
Autenticação interna – Usado dentro dos frameworks para autenticar as comunicações de componentes internos

Com este novo recurso, a autenticação da estrutura interna ainda é gerenciada através do Kerberos, mas isso é transparente para os usuários finais ou serviços externos que, por outro lado, utilizam um nome de usuário e senha para se autenticar.

As estruturas instaladas do EMR suportadas implementam um método de autenticação baseado em LDAP que, dado um conjunto de credenciais de nome de usuário e senha, os valida no endpoint LDAP e, em caso de sucesso, permite o uso da estrutura.

O diagrama a seguir resume como funciona o fluxo de autenticação.

O fluxo de trabalho inclui as seguintes etapas:

Um usuário se conecta a um dos endpoints suportados (como HiveServer2, Trino/Presto Coordinator ou Hue WebUI) e fornece suas credenciais corporativas (nome de usuário e senha).
A estrutura contatada usa um autenticador customizado que executa a autenticação usando o serviço EMR Secret Agent em execução dentro das instâncias do cluster.
O serviço EMR Secret Agent valida as credenciais fornecidas no endpoint LDAP.
Em caso de sucesso, ocorre o seguinte:
- Um principal Kerberos é criado para o usuário específico no centro de distribuição de chaves do MIT (MIT KDC) do cluster em execução dentro do nó primário.
- O keytab principal do Kerberos é criado dentro do diretório inicial do usuário no nó primário.

Após a conclusão da autenticação, o usuário pode começar a usar a estrutura.

Dentro de todas as instâncias de cluster, o serviço SSSD é configurado para recuperar usuários e grupos do endpoint LDAP e disponibilizá-los como usuários do sistema.

O fluxo de autenticação ao conectar-se com SSH é um pouco diferente e está resumido no diagrama a seguir.

O fluxo de trabalho inclui as seguintes etapas:

Um usuário se conecta via SSH à instância primária do EMR, fornecendo as credenciais corporativas (nome de usuário e senha).
O serviço SSHD contatado usa o serviço SSSD para validar as credenciais fornecidas.
O serviço SSSD valida as credenciais fornecidas no terminal LDAP. Em caso de sucesso, o usuário acessa o diretório inicial relacionado. Neste ponto, o usuário pode usar os diferentes CLIs (beeline, trino-cli, presto-cli, curl) para acessar Hive, Trino/Presto ou Livy.
Para usar as CLIs do Spark (spark-submit, pyspark, spark-shell), o usuário deve invocar o ldap-kinit script e forneça o nome de usuário e a senha solicitados.
A autenticação é realizada usando o serviço EMR Secret Agent em execução nas instâncias do cluster.
O serviço EMR Secret Agent valida as credenciais fornecidas no endpoint LDAP.
Em caso de sucesso, ocorre o seguinte:
- Um principal Kerberos é criado para o usuário específico no cluster MIT KDC em execução dentro do nó primário.
- O keytab principal do Kerberos é criado dentro do diretório inicial do usuário no nó primário.
- Um ticket Kerberos é obtido e armazenado no cache de tickets Kerberos do usuário no nó primário.

Após ldap-kinit o script for concluído, o usuário poderá começar a usar as CLIs do Spark.

Nas seções a seguir, mostramos como recuperar os valores de configuração LDAP necessários e investigamos como iniciar um cluster com autenticação LDAP EMR e testá-lo.

Encontre os parâmetros LDAP adequados

Para configurar a autenticação LDAP para Amazon EMR, a primeira etapa é recuperar as propriedades LDAP a serem usadas para configurar seu cluster. Você precisa das seguintes informações:

O nome DNS do servidor LDAP
Um certificado no formato PEM a ser usado para interagir por meio de LDAP seguro (LDAPS) com o terminal LDAP
A base de pesquisa de usuários LDAP, que é um caminho (ou ramificação) na árvore LDAP de onde pesquisar usuários (somente usuários pertencentes a esta ramificação serão recuperados)
A base de pesquisa de grupos LDAP, que é um caminho (ou ramificação) na árvore LDAP de onde pesquisar grupos (somente grupos pertencentes a esta ramificação serão recuperados)
As credenciais do usuário de ligação do servidor LDAP, que são o nome de usuário e a senha de um usuário de serviço (geralmente chamado de usuário de ligação) a serem usadas para acionar consultas LDAP e recuperar informações do usuário, como nome de usuário e associação ao grupo.

Com o Active Directory, um administrador do AD pode recuperar essas informações diretamente do Active Directory Users and Computers ferramenta. Ao escolher um usuário nesta ferramenta, você pode ver os atributos relacionados (por exemplo, distinguishedName). A captura de tela a seguir mostra um exemplo.

Pela captura de tela, podemos ver que o distinguishedName para o usuário john é CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, o que significa que john pertence às seguintes bases de pesquisa, ordenadas da mais restrita para a mais ampla:

OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
OU=italy,OU=emr,DC=awsemr,DC=com
OU=emr,DC=awsemr,DC=com
DC=awsemr,DC=com

Dependendo da quantidade de entradas dentro de um diretório LDAP da empresa, o uso de uma ampla base de pesquisa pode levar a longos tempos de recuperação e limites de tempo. É uma boa prática configurar a base de pesquisa para ser a mais restrita possível, a fim de incluir todos os usuários necessários. No exemplo anterior, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com pode ser uma boa base de pesquisa se todos os usuários aos quais você deseja fornecer acesso ao cluster EMR fizerem parte dessa unidade organizacional.

Outra maneira de recuperar atributos do usuário é usando o ldapsearch ferramenta. Você pode usar esse método para o Active Directory e também para o OpenLDAP, e é extremamente útil para testar a conectividade com o endpoint LDAP.

A seguir está um exemplo com o Active Directory (OpenLDAP é semelhante).

O endpoint LDAP deve ser solucionável e acessível por Amazon Elastic Compute Nuvem (Amazon EC2) Instâncias de cluster EMR via TCP na porta 636. Sugere-se executar o teste a partir de uma instância Amazon Linux 2 EC2 pertencente à mesma sub-rede do cluster EMR e tendo o mesmo grupo de segurança EMR associado às instâncias de cluster EMR.

Depois de executar uma instância do EC2, instale o nc ferramenta e teste a resolução e conectividade do DNS. Assumindo que DC1.awsemr.com é o nome DNS do endpoint LDAP, execute os seguintes comandos:

sudo yum install nc
nc -vz DC1.awsemr.com 636

Se a resolução DNS não estiver funcionando corretamente, você deverá receber um erro como este:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Could not resolve hostname "DC1.awsemr.com": Name or service not known. QUITTING.

Se o endpoint não estiver acessível, você deverá receber um erro como este:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

Em qualquer um desses casos, a equipe de rede e DNS deve estar envolvida para solucionar problemas.

Em caso de sucesso, a saída deverá ser semelhante a esta:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.1.235:636.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Se tudo funcionar, prossiga com os testes e instale o openldap clientes da seguinte forma:

sudo yum install openldap-clients

Então corra ldapsearch comandos para recuperar informações sobre usuários e grupos do terminal LDAP. A seguir estão exemplos ldapsearch comandos:

#Customize these 6 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_TO_SEARCH=john
FILTER=(sAMAccountName=${USER_TO_SEARCH})
INFO_TO_SEARCH="*"

#Search user
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${SEARCH_BASE}" "${FILTER}" "${INFO_TO_SEARCH}"

Usamos os seguintes parâmetros:

-x – Isso permite autenticação simples.
-D – Indica o usuário para realizar a pesquisa.
-w – Isso indica a senha do usuário.
-H – Indica o URL do servidor LDAP.
-b – Esta é a pesquisa básica.
LDAPTLS_CACERT – Isso indica o certificado público SSL PEM do terminal LDAPS ou o certificado público SSL PEM da autoridade de certificação raiz do terminal LDAPS. Isso pode ser obtido com um usuário administrador do AD ou OpenLDAP.

Veja a seguir um exemplo de saída do comando anterior:

filter: (sAMAccountName=john)
requesting: *
dn: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: john
givenName: john
distinguishedName: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
instanceType: 4
whenCreated: 20230804094021.0Z
whenChanged: 20230804094021.0Z
displayName: john
uSNCreated: 262459
memberOf: CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
uSNChanged: 262466
name: john
objectGUID:: gTxn8qYvy0SVL+mYAAbb8Q==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 133356156212864439
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAIKyNe7Dn3azp7Sh+rgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: john
sAMAccountType: 805306368
userPrincipalName: john@awsemr.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=awsemr,DC=com
dSCorePropagationData: 20230804094021.0Z
dSCorePropagationData: 16010101000000.0Z

Como podemos ver no exemplo de saída, o usuário banheiro é identificado pelo nome distinto CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, e as data-engineers grupo ao qual o usuário pertence (memberOf valor) é identificado pelo nome distinto CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Podemos executar nosso ldapsearch consultas para recuperar as informações do usuário e do grupo usando uma base de pesquisa restrita:

#Customize these 9 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_SEARCH_BASE=OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
GROUPS_SEARCH_BASE=OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
USER_TO_SEARCH=john
GROUP_TO_SEARCH=data-engineers

#Search User
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${USER_SEARCH_BASE}" "(sAMAccountName=${USER_TO_SEARCH})" "*"

#Search Group
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${GROUPS_SEARCH_BASE}" "(sAMAccountName=${GROUP_TO_SEARCH})" "*"

Você também pode aplicar outros filtros durante a pesquisa. Para obter mais informações sobre como criar filtros LDAP, consulte Filtros LDAP.

Correndo ldapsearch comandos, você pode testar a conectividade LDAP e as propriedades LDAP e determinar a configuração necessária.

Teste a solução

Depois de verificar se a conectividade com o endpoint LDAP está aberta e se as configurações LDAP estão corretas, prossiga com a configuração do ambiente para iniciar um cluster EMR habilitado para LDAP.

Criar segredos do AWS Secret Manager

Antes de criar a configuração de segurança do EMR, você precisa criar dois Gerenciador secreto da AWS segredos. Você usa essas credenciais para interagir com o terminal LDAP e recuperar detalhes do usuário, como nome de usuário e associação ao grupo.

No console do Secrets Manager, escolha Segredos no painel de navegação.
Escolha Guarde um novo segredo.
Escolha Tipo de segredo, selecione Outro tipo de segredo.
Crie um novo segredo especificando o binduser nome distinto como a chave e o binduser senha como o valor.
Crie um segundo segredo especificando em texto simples o certificado público SSL do terminal LDAPS ou o certificado público da autoridade de certificação raiz LDAPS.
Este certificado é confiável, permitindo uma comunicação segura entre o cluster EMR e o endpoint LDAPS.

Crie a configuração de segurança do EMR

Conclua as etapas a seguir para criar a configuração de segurança do EMR:

No console do Amazon EMR, escolha Configurações de segurança para EMR no EC2 no painel de navegação.
Escolha Crie.
Escolha Nome da configuração de segurança, Insira o nome.
Escolha Opções de configuração de configuração de segurança, selecione Escolha as configurações personalizadas.
Escolha Criptografia, selecione Ative a criptografia em trânsito.
Escolha Tipo de provedor de certificado¸ selecionar PEM.
Escolha Escolha o local do certificado PEM, insira um pacote PEM localizado em Serviço de armazenamento simples da Amazon (Amazon S3) ou um provedor de certificados personalizados Java.
Observe que a criptografia em trânsito é obrigatória para usar o recurso de autenticação LDAP. Para obter mais informações sobre criptografia em trânsito, consulte Fornecimento de certificados para criptografia de dados em trânsito com criptografia do Amazon EMR.
Escolha Próximo.
Selecionar LDAP para Protocolo de autenticação.
Escolha Localização do servidor LDAP, insira o terminal LDAPS (ldaps://<ldap_endpoint_DNS_name>).
Escolha Certificado SSL LDAP, insira o segundo segredo que você criou no Secrets Manager.
Escolha Filtro de acesso LDAP, insira um filtro LDAP que seja aplicado para restringir o acesso a um subconjunto de usuários recuperados da base de procura de usuários LDAP. Se o campo for deixado vazio, nenhum filtro será aplicado e todos os usuários pertencentes à base de pesquisa de usuários LDAP poderão acessar os endpoints protegidos por LDAP do EMR com suas credenciais corporativas. A seguir estão exemplos de filtros e suas funções:
- (objetoClass=pessoa) – Filtrar usuários com o atributo objectClass definido como person
- (memberOf=CN=admins,OU=grupos,OU=itália,OU=emr,DC=awsemr,DC=com) – Filtrar usuários pertencentes ao admins grupo
- (|(memberof=CN=engenheiros de dados,OU=grupos,OU=itália,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=grupos,OU=itália,OU=emr, DC=awsemr,DC=com)) – Filtrar usuários pertencentes ao data-engineers ou de admins grupo (que usamos para esta postagem)
Insira valores para Base de pesquisa de usuários LDAP e Base de pesquisa de grupo LDAP. Observe que as duas bases de pesquisa não suportam filtros embutidos (por exemplo, o seguinte não é suportado: OU=users,OU=italy,OU=emr,DC=awsemr,DC=com?subtree?(|(memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com))).
Selecionar Ative o login SSH. Isso será necessário apenas se você quiser que seus usuários LDAP possam fazer SSH dentro de instâncias de cluster com suas credenciais corporativas. Se o login SSH estiver ativado, o filtro de acesso LDAP será necessário; caso contrário, a autenticação SSH falhará.
Escolha Credenciais de ligação do servidor LDAP, insira o primeiro segredo que você criou no Secrets Manager.
No Autorização seção, mantenha os padrões selecionados:
- Escolha Função do IAM para aplicativos, selecione Perfil da instância.
- Escolha Método de controle de acesso refinado, selecione nenhum.
Escolha Próximo.
Revise o resumo da configuração e escolha Crie.

Inicie o cluster EMR

Você pode iniciar o cluster EMR usando o Console de gerenciamento da AWS, Interface de linha de comando da AWS (AWS CLI) ou qualquer SDK AWS.

Ao criar o EMR no cluster EC2, certifique-se de especificar as seguintes configurações:

Versão EMR – Use o Amazon EMR 6.12.0 ou superior.
Aplicações – Selecione Hadoop, Spark, Hive, Hue, Livy e Presto/Trino.
Configuração de segurança – Especifique a configuração de segurança criada na etapa anterior.
Par de chaves EC2 – Use um par de chaves existente.
Grupos de rede e segurança – Use uma configuração que permita que as instâncias do EMR EC2 interajam com o endpoint LDAPS. No Encontre os parâmetros LDAP adequados seção, você deve ter confirmado uma configuração válida.

Confirme se a autenticação LDAP está funcionando

Quando o cluster estiver instalado e funcionando, você poderá verificar se a autenticação LDAP está funcionando corretamente.

If Login SSH foi ativado como parte de Autenticação LDAP no interior da Configuração de segurança EMR, você pode usar SSH em seu cluster especificando um usuário LDAP e solicitando a senha relacionada quando solicitado:

ssh myldapuser@<emr_primary_node>

Se o login SSH tiver sido desabilitado, você poderá usar SSH dentro do cluster usando o par de chaves do EC2 especificado durante a criação do cluster:

ssh -i mykeypair.pem ec2-user@<emr_primary_node>

Uma forma alternativa de acessar a instância primária, se preferir, é usar Session Manager, uma capacidade de Gerente de Sistemas AWS. Para obter mais informações, consulte Conecte-se à sua instância Linux com o AWS Systems Manager Session Manager.

Quando estiver dentro da instância primária, você poderá testar se os usuários e grupos LDAP foram recuperados corretamente usando o comando id comando. A seguir está um exemplo de comando para verificar se o usuário john é recuperado corretamente com os grupos relacionados:

[ec2-user@ip-10-0-2-237 ~]# id john
uid=941601122(john) gid=941600513(users-group) groups=941600513(users-group),941601123(data-engineers)

Você pode então testar a autenticação nas diferentes estruturas instaladas.

Primeiro, vamos recuperar o certificado público das estruturas e armazená-lo em um armazenamento confiável. Todas as estruturas compartilham o mesmo certificado público (aquele que usamos para configurar a criptografia em trânsito), então você pode usar qualquer um dos endpoints protegidos por SSL (porta Hive 10000, porta Presto/Trino 8446, porta Livy 8998) para recuperá-lo . Obtenha o certificado do endpoint HiveServer2 (porta 10000):

#Export Hive Server 2 public SSL certificate to a PEM file
openssl s_client -showcerts -connect $(hostname -f):10000 </dev/null 2>/dev/null|openssl x509 -outform PEM > certificate.pem

#Import the PEM certificate inside a truststore
echo "yes" | keytool -import -alias hive_cert -file certificate.pem -storetype JKS -keystore truststore.jks -storepass myStrongPassword

Em seguida, use esse armazenamento confiável para se comunicar com segurança com as diferentes estruturas.

Use o código a seguir para testar a autenticação HiveServer2 com beeline:

#Use the truststore to connect to the Hive Server 2
beeline -u "jdbc:hive2://$(hostname -f):10000/default;ssl=true;sslTrustStore=truststore.jks;trustStorePassword=myStrongPassword" -n john -p johnPassword

Se estiver usando Presto, teste a autenticação Presto com o presto CLI (forneça a senha do usuário quando solicitado):

#Use the truststore to connect to the Presto coordinator
presto-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Se estiver usando Trino, teste a autenticação Trino com o trino CLI (forneça a senha do usuário quando solicitado):

#Use the truststore to connect to the Trino coordinator
trino-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

Test Livy autenticação com curl:

#Trust the PEM certificte to connect to the Livy server

#Start session
curl --cacert certificate.pem -X POST 
-u "john:johnPassword" 
--data '{"kind": "spark"}' 
-H "Content-Type: application/json" 
https://$(hostname -f):8998/sessions 
-c cookies.txt

#Example of output
#{"id":0,"name":null,"appId":null,"owner":"john","proxyUser":"john","state":"starting","kind":"spark","appInfo":{"driverLogUrl":null,"sparkUiUrl":null},"log":["stdout: ","nstderr: ","nYARN Diagnostics: "]}

Teste comandos do Spark com pyspark:

#SSH inside the primary instance with the specific user
ssh john@<emr-primary-node>
#Or impersonate the user
sudo su - john

#Create a keytab and obtain a kerberos ticket running the ldap-kinit tool
$ ldap-kinit
Username: john
Password: 

#Output
{"message":"ok","contents":{"username":"john","expirationTime":"2023-09-14T15:24:06.303Z[UTC]"}}

#Check the kerberos ticket has been created
$ klist

# Test spark CLIs
$ pyspark

>>> spark.sql("show databases").show()
>>> quit()

Observe que aqui testamos a autenticação de dentro do cluster, mas podemos interagir com Trino, Hive, Presto e Livy mesmo de fora do cluster, desde que a conectividade e a resolução de DNS estejam configuradas corretamente. Spark CLIs são os únicos que podem ser usados somente de dentro do cluster.

Para testar a autenticação Hue, execute as seguintes etapas:

Navegue até a IU da web do Hue hospedada em http://<emr_primary_node>:8888/ e forneça um nome de usuário e senha LDAP.
Teste consultas SQL dentro dos editores Hive e Trino/Presto.

Para testar com uma ferramenta SQL externa (como DBeaver conectando ao Trino), conclua as etapas a seguir. Certifique-se de configurar o grupo de segurança do nó primário do EMR para que ele permita o tráfego TCP do IP do DBeaver para a porta do endpoint da estrutura desejada (por exemplo, 10000 para HiveServer2, 8446 para Trino/Presto) e para configurar corretamente a resolução DNS no cliente DBeaver máquina para resolver corretamente o nome do host do nó primário do EMR.

Na instância primária do cluster EMR, copie para um bucket do S3 os arquivos truststore.jks (criado anteriormente) e /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (mudar a versão XXX dependendo da versão do EMR).
Baixe em sua máquina cliente DBeaver o truststore.jks e trino-jdbc-XXX-amzn-0.jar arquivos.
Abra o DBeaver e escolha banco de dados, Em seguida, escolha Gerenciador de Driver.
Escolha Novo para criar um novo driver.
No Configurações guia, forneça as seguintes informações:
- Escolha Nome do motorista, entrar EMR Trino.
- Escolha Nome da classe, entrar io.trino.jdbc.TrinoDriver.
- Escolha Modelo de URL, entrar jdbc:trino://{host}:{port}.
No bibliotecas guia, conclua as seguintes etapas:
- Escolha Adicionar Arquivo.
- Escolha o arquivo JAR do driver Trino JDBC no sistema de arquivos local (trino-jdbc-XXX-amzn-0.jar).
Escolha OK para criar o driver.
Escolha banco de dados e Nova conexão de banco de dados.
No a Principal guia, especifique o seguinte:
- Escolha Conectar por, selecione Proprietário.
- Escolha Proprietário, insira o nó primário do EMR.
- Escolha Porta, insira a porta Trino (8446 por padrão).
No Propriedades do driver guia, adicione as seguintes propriedades:
- Adicionar SSL com True como o valor
- Adicionar SSLTrustStorePath com o truststore.jks localização do arquivo como o valor.
- Adicionar SSLTrustStorePassword com o truststore.jks senha que você usou para criá-lo como o valor.
Escolha Acabamento.
Escolha a conexão criada e escolha o CONTATE-NOS ícone.
Digite seu nome de usuário e senha LDAP e escolha OK.

Se tudo estiver funcionando, você poderá navegar pelos catálogos, bancos de dados e tabelas do Trino no painel de navegação. Para executar consultas, escolha Editor SQL, Em seguida, escolha Abra o Editor SQL.

No Editor SQL, você pode consultar suas tabelas.

Próximos passos

O novo recurso de autenticação LDAP do Amazon EMR simplifica a maneira como os usuários podem obter acesso às estruturas instaladas do EMR. Quando os usuários usam uma estrutura, talvez você queira controlar os dados que eles podem acessar. Para este tópico específico, você pode usar a autenticação LDAP em combinação com a integração nativa do EMR Apache Ranger. Para obter mais informações, consulte Integre o Amazon EMR ao Apache Ranger.

limpar

Conclua as ações de limpeza a seguir para remover os recursos criados após esta postagem e evitar incorrer em custos adicionais. Para esta postagem, limpamos usando a AWS CLI. Você também pode limpar usando ações semelhantes por meio do console.

Se você executou uma instância do EC2 para verificar a conectividade LDAP e não precisa mais dela, exclua-a com o seguinte comando (especifique o ID da sua instância):
```
aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>
```
Se você iniciou uma instância do EC2 para testar o DBeaver e não precisa mais dela, você pode usar o comando anterior para excluí-la.
Exclua o cluster EMR com o seguinte comando (especifique o ID do cluster EMR):
```
aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>
```
Observe que se o cluster EMR tiver Proteção contra rescisão ativado, antes de executar o procedimento anterior terminate-clusters comando, você deve desativá-lo. Você pode fazer isso com o seguinte comando (especifique o ID do cluster EMR):
```
aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1
```

Exclua a configuração de segurança do EMR com o seguinte comando:

aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

Exclua os segredos do Secrets Manager com os seguintes comandos:

aws secretsmanager delete-secret 
--secret-id <first-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

aws secretsmanager delete-secret 
--secret-id <second-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

Conclusão

Nesta postagem, discutimos como você pode configurar e testar a autenticação LDAP no EMR em clusters EC2. Discutimos como recuperar as configurações LDAP necessárias, testar a conectividade com o endpoint LDAP, definir a configuração de segurança do EMR e testar se a autenticação LDAP está funcionando corretamente. Esta postagem também destacou como o fluxo de autenticação é simplificado em comparação com a configuração padrão de confiança entre domínios do Active Directory. Para saber mais sobre esse recurso, consulte Use servidores Active Directory ou LDAP para autenticação com Amazon EMR.

Sobre os autores

Stefano Sandona é arquiteto sênior de soluções de Big Data na AWS. Ele adora dados, sistemas distribuídos e segurança. Ele ajuda clientes em todo o mundo a arquitetar plataformas de big data seguras, escaláveis e confiáveis.

Adnan Hemani é engenheiro de desenvolvimento de software na AWS e trabalha com a equipe EMR. Ele se concentra na postura de segurança de aplicativos executados em clusters EMR. Ele está interessado em aplicações modernas de Big Data e em como os clientes interagem com elas.

Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
Fonte: https://aws.amazon.com/blogs/big-data/simplify-authentication-with-native-ldap-integration-on-amazon-emr/

Inteligência de dados generativa

Simplifique a autenticação com integração LDAP nativa no Amazon EMR | Amazon Web Services

Como funciona a integração LDAP do Amazon EMR

Encontre os parâmetros LDAP adequados

Teste a solução

Criar segredos do AWS Secret Manager

Crie a configuração de segurança do EMR

Inicie o cluster EMR

Confirme se a autenticação LDAP está funcionando

Próximos passos

limpar

Conclusão

Sobre os autores

🔴ETFs Ethereum atrasados | Esta semana na criptografia – 11 de março de 2024

Na doença e na saúde: um guia do cuidador para encontrar força e esperança – World News Report – Conexão do Programa de Maconha Medicinal

Inteligência mais recente

Clean Group anuncia novo local de escritório em Sydney CBD e serviços aprimorados de limpeza comercial – World News Report – Conexão do programa de maconha medicinal

Maximizando os lucros em 2024: uma visão abrangente da ValueZone.AI

Secretário de Defesa do Reino Unido revela fornecimento italiano de mísseis Storm Shadow para a Ucrânia

Cobertura ao vivo: SpaceX lançará 23 satélites Starlink no voo Falcon 9 do Cabo Canaveral

Três chaves para os ilhéus vencerem o jogo cinco

Lakers obtém vitória cobiçada contra Denver, agora perdendo por 3-1 na série