Logo Zephyrnet

Intelligenza generativa dei dati

Big Data

Semplifica l'autenticazione con l'integrazione LDAP nativa su Amazon EMR | Servizi Web di Amazon

Ripubblicato da Platone
Ripubblicato da Platone

Data:

Visualizzazioni: 83

Molte aziende hanno identità aziendali archiviate all'interno di provider di identità (IdP) come Active Directory (d.C.) o OpenLDAP. In precedenza, i clienti che utilizzavano Amazon EMR potrebbero integrare i propri cluster con Active Directory configurando un realm trust unidirezionale tra il proprio dominio AD e il realm Kerberos del cluster EMR. Per ulteriori dettagli, fare riferimento a Esercitazione: configurare un trust tra realm con un dominio Active Directory.

Questa configurazione è stata un fattore chiave per rendere disponibili gli utenti e i gruppi aziendali all'interno dei cluster EMR e definire policy di controllo degli accessi per controllare il loro accesso ai dati (ad esempio, attraverso Integrazione Apache Ranger nativa di Amazon EMR).

Sebbene questa opzione sia ancora disponibile, Amazon EMR è stata rilasciata supporto per l'autenticazione LDAP nativa, una nuova funzionalità di sicurezza che semplifica l'integrazione con OpenLDAP e Active Directory.

Questa funzionalità consente quanto segue:

  • configurazione automatica della sicurezza per le applicazioni supportate (HiveServer2, Trino, Presto e Livy) per utilizzare il protocollo Kerberos sotto il cofano e LDAP come autenticazione esterna. Ciò consente un'integrazione più diretta da parte di strumenti esterni che, per connettersi agli endpoint del cluster, non devono più impostare l'autenticazione kerberos ma, invece, possono semplicemente essere configurati per fornire un nome utente e una password LDAP
  • controllo degli accessi granulare (FGAC) su chi può accedere ai cluster EMR tramite SSH
  • policy di autorizzazione dettagliate sul database e sulle tabelle Hive Metastore se utilizzate in combinazione con l'integrazione nativa Amazon EMR Apache Ranger.

In questo post, approfondiamo l'autenticazione LDAP di Amazon EMR, mostrando come funziona il flusso di autenticazione, come recuperare e testare le configurazioni LDAP necessarie e come verificare che un cluster EMR sia correttamente integrato LDAP.

Utilizzando le informazioni su questo blog:

  • I team che gestiscono i cluster EMR possono migliorare il coordinamento con i propri amministratori IdP LDAP per richiedere le informazioni corrette ed eseguire correttamente i test di preconfigurazione
  • Gli utenti finali del cluster EMR possono comprendere quanto sia semplice connettersi da strumenti esterni ai cluster EMR abilitati LDAP rispetto alla precedente autenticazione basata su Kerberos

Come funziona l'integrazione LDAP di Amazon EMR

Quando si parla di autenticazione nel contesto dei framework EMR, possiamo distinguere tra due livelli:

  • Autenticazione esterna – Utilizzato da utenti e componenti esterni per interagire con i framework installati
  • Autenticazione interna – Utilizzato all'interno dei framework per autenticare le comunicazioni dei componenti interni

Con questa nuova funzionalità, l'autenticazione del framework interno è ancora gestita tramite Kerberos, ma questo è trasparente per gli utenti finali o per i servizi esterni che, d'altra parte, utilizzano un nome utente e una password per autenticarsi.

I framework EMR installati supportati implementano un metodo di autenticazione basato su LDAP che, dato un set di credenziali di nome utente e password, li convalida rispetto all'endpoint LDAP e, in caso di successo, abilita l'uso del framework.

Il diagramma seguente riepiloga il funzionamento del flusso di autenticazione.

Il flusso di lavoro include i seguenti passaggi:

  1. Un utente si connette a uno degli endpoint supportati (come HiveServer2, Trino/Presto Coordinator o Hue WebUI) e fornisce le proprie credenziali aziendali (nome utente e password).
  2. Il framework contattato utilizza un autenticatore personalizzato che esegue l'autenticazione utilizzando il servizio EMR Secret Agent in esecuzione all'interno delle istanze del cluster.
  3. Il servizio EMR Secret Agent convalida le credenziali fornite rispetto all'endpoint LDAP.
  4. In caso di successo si verifica quanto segue:
    • Viene creata un'entità Kerberos per l'utente specifico nel centro di distribuzione delle chiavi MIT (MIT KDC) del cluster in esecuzione all'interno del nodo primario.
    • La keytab principale Kerberos viene creata all'interno della directory home dell'utente sul nodo primario.

Una volta completata l'autenticazione, l'utente può iniziare a utilizzare il framework.

All'interno di tutte le istanze del cluster, il servizio SSSD è configurato per recuperare utenti e gruppi dall'endpoint LDAP e renderli disponibili come utenti di sistema.

Il flusso di autenticazione quando ci si connette con SSH è leggermente diverso ed è riepilogato nel diagramma seguente.

Il flusso di lavoro include i seguenti passaggi:

  1. Un utente si connette con SSH all'istanza primaria EMR, fornendo le credenziali aziendali (nome utente e password).
  2. Il servizio SSHD contattato utilizza il servizio SSSD per convalidare le credenziali fornite.
  3. Il servizio SSSD convalida le credenziali fornite rispetto all'endpoint LDAP. In caso di successo, l'utente accede alla relativa home directory. A questo punto l'utente può utilizzare le diverse CLI (beeline, trino-cli, presto-cli, curl) per accedere a Hive, Trino/Presto o Livy.
  4. Per utilizzare le CLI Spark (spark-submit, pyspark, spark-shell), l'utente deve invocare il file ldap-kinit script e fornire il nome utente e la password richiesti.
  5. L'autenticazione viene eseguita utilizzando il servizio EMR Secret Agent in esecuzione all'interno delle istanze del cluster.
  6. Il servizio EMR Secret Agent convalida le credenziali fornite rispetto all'endpoint LDAP.
  7. In caso di successo si verifica quanto segue:
    • Viene creata un'entità Kerberos per l'utente specifico sul cluster MIT KDC in esecuzione all'interno del nodo primario.
    • La keytab principale Kerberos viene creata all'interno della directory home dell'utente sul nodo primario.
    • Un ticket Kerberos viene ottenuto e archiviato nella cache dei ticket Kerberos dell'utente sul nodo primario.

Dopo il ldap-kinit viene completato lo script, l'utente può iniziare a utilizzare le CLI Spark.

Nelle sezioni seguenti mostriamo come recuperare i valori di impostazione LDAP richiesti e analizziamo come avviare un cluster con l'autenticazione EMR LDAP e testarlo.

Trova i parametri LDAP corretti

Per configurare l'autenticazione LDAP per Amazon EMR, il primo passaggio consiste nel recuperare le proprietà LDAP da utilizzare per configurare il cluster. Sono necessarie le seguenti informazioni:

  • Il nome DNS del server LDAP
  • Un certificato in formato PEM da utilizzare per interagire su Secure LDAP (LDAPS) con l'endpoint LDAP
  • La base di ricerca degli utenti LDAP, che è un percorso (o ramo) sull'albero LDAP da cui cercare gli utenti (verranno recuperati solo gli utenti appartenenti a questo ramo)
  • La base di ricerca dei gruppi LDAP, che è un percorso (o ramo) sull'albero LDAP da cui cercare i gruppi (verranno recuperati solo i gruppi appartenenti a questo ramo)
  • Le credenziali utente di associazione del server LDAP, ovvero il nome utente e la password per un utente del servizio (solitamente chiamato utente di associazione) da utilizzare per attivare query LDAP e recuperare informazioni sull'utente quali nome utente e appartenenza al gruppo.

Con Active Directory, un amministratore AD può recuperare queste informazioni direttamente dal file Active Directory Users and Computers attrezzo. Quando scegli un utente in questo strumento, puoi vedere i relativi attributi (ad esempio, distinguishedName). La schermata seguente mostra un esempio.

Dallo screenshot, possiamo vedere che il file distinguishedName per l'utente john è CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, il che significa che john appartiene alle seguenti basi di ricerca, ordinate dalla più stretta alla più ampia:

  • 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

A seconda della quantità di voci all'interno di una directory LDAP aziendale, l'utilizzo di un'ampia base di ricerca può comportare tempi di recupero e timeout lunghi. È buona norma configurare la base di ricerca in modo che sia la più ristretta possibile in modo da includere tutti gli utenti necessari. Nell'esempio precedente, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com può essere una buona base di ricerca se tutti gli utenti a cui desideri fornire l'accesso al cluster EMR fanno parte di quell'unità organizzativa.

Un altro modo per recuperare gli attributi utente è utilizzare il file ldapsearch attrezzo. Puoi utilizzare questo metodo sia per Active Directory che per OpenLDAP ed è estremamente utile testare la connettività con l'endpoint LDAP.

Quello che segue è un esempio con Active Directory (OpenLDAP è simile).

L'endpoint LDAP deve essere risolvibile e raggiungibile da Cloud di calcolo elastico di Amazon (Amazon EC2) Istanze del cluster EMR tramite TCP sulla porta 636. Si consiglia di eseguire il test da un'istanza Amazon Linux 2 EC2 appartenente alla stessa sottorete del cluster EMR e con lo stesso gruppo di sicurezza EMR associato alle istanze del cluster EMR.

Dopo aver avviato un'istanza EC2, installa il file nc strumento e testare la risoluzione DNS e la connettività. Supponendo che DC1.awsemr.com è il nome DNS per l'endpoint LDAP, esegui i seguenti comandi:

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

Se la risoluzione DNS non funziona correttamente, dovresti ricevere un errore simile al seguente:

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

Se l'endpoint non è raggiungibile, dovresti ricevere un errore simile al seguente:

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

In entrambi questi casi, il team di rete e DNS dovrebbe essere coinvolto per individuare e risolvere i problemi.

In caso di successo, l'output dovrebbe essere simile al seguente:

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 tutto funziona, procedi con il test e installa il openldap clienti come segue:

sudo yum install openldap-clients

Quindi corri ldapsearch comandi per recuperare informazioni su utenti e gruppi dall'endpoint LDAP. I seguenti sono esempi ldapsearch comandi:

#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}"

Utilizziamo i seguenti parametri:

  • -x – Ciò consente una semplice autenticazione.
  • -D – Indica all'utente di eseguire la ricerca.
  • -w – Indica la password dell'utente.
  • -H – Indica l'URL del server LDAP.
  • -b – Questa è la ricerca di base.
  • LDAPTLS_CACERT – Indica il certificato pubblico PEM SSL dell'endpoint LDAPS o il certificato pubblico PEM SSL dell'autorità di certificazione radice dell'endpoint LDAPS. Questo può essere ottenuto da un utente amministratore AD o OpenLDAP.

Quello che segue è un esempio di output del comando precedente:

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

Come possiamo vedere dall'output di esempio, il file user Giovanni è identificato dal nome distinto CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, e il data-engineers gruppo a cui appartiene l'utente (memberOf valore) è identificato dal nome distinto CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Possiamo eseguire il nostro ldapsearch query per recuperare le informazioni sull'utente e sul gruppo utilizzando una base di ricerca ristretta:

#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})" "*"

Puoi anche applicare altri filtri durante la ricerca. Per ulteriori informazioni su come creare filtri LDAP, fare riferimento a Filtri LDAP.

Correre ldapsearch comandi, è possibile testare la connettività LDAP e le proprietà LDAP e determinare la configurazione necessaria.

Prova la soluzione

Dopo aver verificato che la connettività all'endpoint LDAP è aperta e che le configurazioni LDAP sono corrette, procedere con la configurazione dell'ambiente per avviare un cluster EMR abilitato per LDAP.

Crea segreti AWS Secret Manager

Prima di creare la configurazione di sicurezza EMR, è necessario crearne due Gestore segreto AWS segreti. Utilizzi queste credenziali per interagire con l'endpoint LDAP e recuperare i dettagli dell'utente come il nome utente e l'appartenenza al gruppo.

  1. Nella console di Secrets Manager, selezionare Segreti nel pannello di navigazione.
  2. Scegli Memorizza un nuovo segreto.
  3. Nel Tipo segreto, selezionare Altro tipo di segreto.
  4. Crea un nuovo segreto specificando il file binduser nome distinto come la chiave e il binduser password come valore.
  5. Crea un secondo segreto specificando in testo non crittografato il certificato pubblico SSL dell'endpoint LDAPS o il certificato pubblico dell'autorità di certificazione radice LDAPS.
    Questo certificato è affidabile e consente una comunicazione sicura tra il cluster EMR e l'endpoint LDAPS.

Creare la configurazione di sicurezza EMR

Completare i seguenti passaggi per creare la configurazione di sicurezza EMR:

  1. Sulla console Amazon EMR, scegli Configurazioni di sicurezza per EMR su EC2 nel pannello di navigazione.
  2. Scegli Creare.
  3. Nel Nome della configurazione di sicurezza, inserisci un nome.
  4. Nel Opzioni di configurazione della configurazione di sicurezza, selezionare Scegli le impostazioni personalizzate.
  5. Nel crittografia, selezionare Attiva la crittografia in transito.
  6. Nel Tipo di fornitore di certificatiSelezionare PEM.
  7. Nel Scegli la posizione del certificato PEM, inserisci un bundle PEM situato in Servizio di archiviazione semplice Amazon (Amazon S3) o un fornitore di certificati personalizzati Java.
    Tieni presente che la crittografia in transito è obbligatoria per poter utilizzare la funzione di autenticazione LDAP. Per ulteriori informazioni sulla crittografia in transito, fare riferimento a Fornitura di certificati per la crittografia dei dati in transito con la crittografia Amazon EMR.
  8. Scegli Avanti.
  9. Seleziona LDAP per Protocollo di autenticazione.
  10. Nel Posizione del server LDAP, inserisci l'endpoint LDAPS (ldaps://<ldap_endpoint_DNS_name>).
  11. Nel Certificato SSL LDAP, inserisci il secondo segreto che hai creato in Secrets Manager.
  12. Nel Filtro di accesso LDAP, inserisci un filtro LDAP da applicare per limitare l'accesso a un sottoinsieme di utenti recuperati dalla base di ricerca utenti LDAP. Se il campo viene lasciato vuoto, non viene applicato alcun filtro e tutti gli utenti appartenenti alla base di ricerca utenti LDAP possono accedere agli endpoint EMR protetti da LDAP con le proprie credenziali aziendali. Di seguito sono riportati esempi di filtri e le relative funzioni:
    • (classeoggetto=persona) – Filtra gli utenti con l'attributo objectClass impostato come person
    • (membro=CN=amministratori,OU=gruppi,OU=italia,OU=emr,DC=awsemr,DC=com) – Filtra gli utenti appartenenti a admins gruppo
    • (|(memberof=CN=data-engineers,OU=gruppi,OU=italia,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=gruppi,OU=italia,OU=emr, DC=awsemr,DC=com)) – Filtra gli utenti appartenenti a data-engineers oppure admins gruppo (che utilizziamo per questo post)
  13. Immettere i valori per Base di ricerca utenti LDAP ed Base di ricerca del gruppo LDAP. Tieni presente che le due basi di ricerca non supportano i filtri in linea (ad esempio, quanto segue non è supportato: 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))).
  14. Seleziona Attiva l'accesso SSH. Ciò è necessario solo se desideri che i tuoi utenti LDAP possano accedere tramite SSH all'interno delle istanze del cluster con le loro credenziali aziendali. Se l'accesso SSH è abilitato, è necessario il filtro di accesso LDAP, altrimenti l'autenticazione SSH fallirà.
  15. Nel Credenziali di associazione del server LDAP, inserisci il primo segreto che hai creato in Secrets Manager.
  16. Nel Autorizzazione sezione, mantenere selezionate le impostazioni predefinite:
    • Nel Ruolo IAM per le applicazioni, selezionare Profilo dell'istanza.
    • Nel Metodo di controllo degli accessi a grana fine, selezionare Nessuna.
  17. Scegli Avanti.
  18. Esamina il riepilogo della configurazione e scegli Creare.

Avviare il cluster EMR

È possibile avviare il cluster EMR utilizzando il file Console di gestione AWS, le Interfaccia della riga di comando di AWS (AWS CLI) o qualsiasi altro SDK AWS.

Quando crei l'EMR sul cluster EC2, assicurati di specificare le seguenti configurazioni:

  • Versione EMR – Utilizza Amazon EMR 6.12.0 o versione successiva.
  • Applicazioni – Seleziona Hadoop, Spark, Hive, Hue, Livy e Presto/Trino.
  • Configurazione di sicurezza – Specificare la configurazione di sicurezza creata nel passaggio precedente.
  • Coppia di chiavi EC2 – Utilizzare una coppia di chiavi esistente.
  • Gruppi di rete e di sicurezza – Utilizzare una configurazione che consenta alle istanze EMR EC2 di interagire con l'endpoint LDAPS. Nel Trova i parametri LDAP corretti sezione, dovresti aver confermato una configurazione valida.

Conferma che l'autenticazione LDAP funziona

Quando il cluster è attivo e in esecuzione, puoi verificare che l'autenticazione LDAP funzioni correttamente.

If Accesso SSH è stato abilitato come parte di Autenticazione LDAP all'interno Configurazione della sicurezza EMR, puoi accedere tramite SSH al tuo cluster specificando un utente LDAP e richiedendo la relativa password quando richiesta:

ssh myldapuser@<emr_primary_node>

Se l'accesso SSH è stato disabilitato, puoi utilizzare SSH all'interno del cluster utilizzando la coppia di chiavi EC2 specificata durante la creazione del cluster:

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

Un modo alternativo per accedere all'istanza primaria, se preferisci, è utilizzare Session Manager, una capacità di Gestore di sistemi AWS. Per ulteriori informazioni, fare riferimento a Connettiti alla tua istanza Linux con AWS Systems Manager Session Manager.

Quando ti trovi all'interno dell'istanza primaria, puoi verificare che gli utenti e i gruppi LDAP vengano recuperati correttamente utilizzando il file id comando. Di seguito è riportato un comando di esempio per verificare se l'utente john viene recuperato correttamente con i relativi gruppi:

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

È quindi possibile testare l'autenticazione sui diversi framework installati.

Per prima cosa, recuperiamo il certificato pubblico del framework e memorizziamolo in un truststore. Tutti i framework condividono lo stesso certificato pubblico (quello che abbiamo utilizzato per impostare la crittografia in transito), quindi puoi utilizzare uno qualsiasi degli endpoint protetti SSL (porta Hive 10000, porta Presto/Trino 8446, porta Livy 8998) per recuperarlo . Prendi il certificato dall'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

Quindi utilizza questo truststore per comunicare in modo sicuro con i diversi framework.

Utilizzare il codice seguente per testare l'autenticazione HiveServer2 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 si utilizza Presto, testare l'autenticazione Presto con il file presto CLI (fornire la password utente quando richiesta):

#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 usi Trino, prova l'autenticazione Trino con il file trino CLI (fornire la password utente quando richiesta):

#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 autenticazione con 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: "]}

Prova i comandi Spark con 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()

Tieni presente che qui abbiamo testato l'autenticazione dall'interno del cluster, ma possiamo interagire con Trino, Hive, Presto e Livy anche dall'esterno del cluster purché la connettività e la risoluzione DNS siano configurate correttamente. Le CLI Spark sono le uniche che possono essere utilizzate solo dall'interno del cluster.

Per testare l'autenticazione Hue, completa i seguenti passaggi:

  1. Passare all'interfaccia utente Web di Hue ospitata su http://<emr_primary_node>:8888/ e fornire un nome utente e una password LDAP.
  2. Testa le query SQL negli editor Hive e Trino/Presto.

Per testare con uno strumento SQL esterno (come DBeaver connessione a Trino), completare i seguenti passaggi. Assicurati di configurare il gruppo di sicurezza del nodo primario EMR in modo che consenta il traffico TCP dall'IP DBeaver alla porta dell'endpoint del framework desiderato (ad esempio, 10000 per HiveServer2, 8446 per Trino/Presto) e di configurare correttamente la risoluzione DNS sul client DBeaver macchina per risolvere correttamente il nome host del nodo primario EMR.

  1. Dall'istanza primaria del cluster EMR, copia i file in un bucket S3 truststore.jks (precedentemente creato) e /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (cambia versione XXX a seconda della versione EMR).
  2. Scarica sul tuo computer client DBeaver il file truststore.jks ed trino-jdbc-XXX-amzn-0.jar File.
  3. Apri DBeaver e scegli Banca Dati, Quindi scegliere Driver Manager.
  4. Scegli New per creare un nuovo driver.
  5. Sulla Impostazioni profilo scheda, fornire le seguenti informazioni:
    • Nel Nome del driver, accedere EMR Trino.
    • Nel Nome della classe, accedere io.trino.jdbc.TrinoDriver.
    • Nel Modello di URL, accedere jdbc:trino://{host}:{port}.
  6. Sulla Biblioteche scheda, completare i seguenti passaggi:
    • Scegli Aggiungi File.
    • Scegliere il file JAR del driver JDBC Trino dal file system locale (trino-jdbc-XXX-amzn-0.jar).
  7. Scegli OK per creare il driver.
  8. Scegli Banca Dati ed Nuova connessione al database.
  9. Sulla Principale scheda, specificare quanto segue:
    • Nel Connettiti tramite, selezionare ospite.
    • Nel ospite, accedere al nodo primario EMR.
    • Nel Porto, inserisci la porta Trino (8446 per impostazione predefinita).
  10. Sulla Proprietà del driver scheda, aggiungi le seguenti proprietà:
    • Aggiungi SSL con True come valore.
    • Aggiungi SSLTrustStorePath con la truststore.jks percorso del file come valore.
    • Aggiungi SSLTrustStorePassword con la truststore.jks password che hai utilizzato per crearlo come valore.
  11. Scegli Fine.
  12. Scegli la connessione creata e scegli il file Connettiti icona.
  13. Inserisci il nome utente e la password LDAP, quindi scegli OK.

Se tutto funziona, dovresti essere in grado di sfogliare i cataloghi, i database e le tabelle di Trino nel riquadro di navigazione. Per eseguire query, scegli Editor SQL, Quindi scegliere Apri l'editor SQL.

Dall'editor SQL puoi interrogare le tue tabelle.

Prossimi passi

La nuova funzionalità di autenticazione LDAP di Amazon EMR semplifica il modo in cui gli utenti possono accedere ai framework EMR installati. Quando gli utenti utilizzano un framework, potresti voler governare i dati a cui possono accedere. Per questo argomento specifico, puoi utilizzare l'autenticazione LDAP in combinazione con l'integrazione nativa EMR Apache Ranger. Per ulteriori informazioni, fare riferimento a Integra Amazon EMR con Apache Ranger.

ripulire

Completa le seguenti azioni di pulizia per rimuovere le risorse che hai creato in seguito a questo post ed evitare di incorrere in costi aggiuntivi. Per questo post, puliamo utilizzando l'AWS CLI. Puoi anche ripulire utilizzando azioni simili tramite la console.

  1. Se hai avviato un'istanza EC2 per verificare la connettività LDAP e non ne hai più bisogno, eliminala con il seguente comando (specifica l'ID dell'istanza): 
    aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>

  2. Se hai avviato un'istanza EC2 per testare DBeaver e non ne hai più bisogno, puoi utilizzare il comando precedente per eliminarla.
  3. Elimina il cluster EMR con il seguente comando (specifica l'ID del cluster EMR): 
    aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>

    Tieni presente che se il cluster EMR ha Protezione dalla cessazione abilitato, prima di eseguire il comando precedente terminate-clusters comando, devi disabilitarlo. Puoi farlo con il seguente comando (specifica il tuo ID cluster EMR):

    aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1

  4. Elimina la configurazione di sicurezza EMR con il seguente comando: 
    aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

  5. Elimina i segreti di Secrets Manager con i seguenti comandi: 
    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>

Conclusione

In questo post abbiamo discusso di come configurare e testare l'autenticazione LDAP su EMR sui cluster EC2. Abbiamo discusso di come recuperare le impostazioni LDAP necessarie, testare la connettività con l'endpoint LDAP, configurare la configurazione di sicurezza EMR e testare che l'autenticazione LDAP funzioni correttamente. Questo post ha inoltre evidenziato come il flusso di autenticazione sia semplificato rispetto alla configurazione standard di trust tra realm di Active Directory. Per ulteriori informazioni su questa funzionalità, fare riferimento a Utilizza Active Directory o server LDAP per l'autenticazione con Amazon EMR.

Informazioni sugli autori

Stefano Sandona è un Senior Big Data Solution Architect presso AWS. Ama i dati, i sistemi distribuiti e la sicurezza. Aiuta i clienti di tutto il mondo a progettare piattaforme Big Data sicure, scalabili e affidabili.

Adnan Hemani è un ingegnere di sviluppo software presso AWS che lavora con il team EMR. Si concentra sullo stato di sicurezza delle applicazioni in esecuzione su cluster EMR. È interessato alle moderne applicazioni Big Data e al modo in cui i clienti interagiscono con esse.

spot_img

L'ultima intelligenza

spot_img

Copyright @ 2024 Plato Technologies Inc.