Zephyrnet-logo

Generatieve data-intelligentie

Big data

Vereenvoudig authenticatie met native LDAP-integratie op Amazon EMR | Amazon-webservices

Heruitgegeven door Plato
Heruitgegeven door Plato

Datum:

Aantal keer bekeken: 83

Veel bedrijven hebben bedrijfsidentiteiten opgeslagen in identiteitsproviders (IdP's), zoals Active Directory (ADVERTENTIE) of OpenLDAP. Vroeger gebruikten klanten Amazon EMR zouden hun clusters kunnen integreren met Active Directory door een eenrichtingsvertrouwensrelatie tussen hun AD-domein en het Kerberos-domein van het EMR-cluster te configureren. Voor meer details, zie Zelfstudie: Configureer een cross-realm-vertrouwensrelatie met een Active Directory-domein.

Deze opzet is van cruciaal belang geweest om zakelijke gebruikers en groepen beschikbaar te maken binnen EMR-clusters en om toegangscontrolebeleid te definiëren om hun gegevenstoegang te controleren (bijvoorbeeld via de Amazon EMR-native Apache Ranger-integratie).

Hoewel deze optie nog steeds beschikbaar is, heeft Amazon EMR vrijgegeven ondersteuning voor native LDAP-authenticatie, een nieuwe beveiligingsfunctie die de integratie met OpenLDAP en Active Directory vereenvoudigt.

Deze functie maakt het volgende mogelijk:

  • automatische configuratie van de beveiliging voor de ondersteunde applicaties (HiveServer2, Trino, Presto en Livy) om het Kerberos-protocol onder de motorkap en LDAP als externe authenticatie te gebruiken. Dit maakt een eenvoudigere integratie mogelijk van externe tools die, om verbinding te maken met clustereindpunten, geen kerberos-authenticatie meer hoeven in te stellen, maar in plaats daarvan eenvoudigweg kunnen worden geconfigureerd om een ​​LDAP-gebruikersnaam en -wachtwoord op te geven
  • fijnmazige toegangscontrole (FGAC) over wie toegang heeft tot uw EMR-clusters via SSH
  • fijnmazig autorisatiebeleid bovenop de Hive Metastore-database en -tabellen, indien gebruikt in combinatie met de native Amazon EMR Apache Ranger-integratie.

In dit bericht duiken we diep in de Amazon EMR LDAP-authenticatie, waarbij we laten zien hoe de authenticatiestroom werkt, hoe je de benodigde LDAP-configuraties kunt ophalen en testen, en hoe je kunt bevestigen dat een EMR-cluster correct LDAP-geïntegreerd is.

Met behulp van de informatie op deze blog:

  • Teams die EMR-clusters beheren, kunnen de coördinatie met hun LDAP IdP-beheerders verbeteren om de juiste informatie op te vragen en pre-configuratietests correct uit te voeren
  • Eindgebruikers van EMR-clusters kunnen begrijpen hoe eenvoudig het is om vanuit externe tools verbinding te maken met voor LDAP geschikte EMR-clusters, vergeleken met de vorige, op Kerberos gebaseerde authenticatie

Hoe Amazon EMR LDAP-integratie werkt

Als we het hebben over authenticatie in de context van EMR-frameworks, kunnen we onderscheid maken tussen twee niveaus:

  • Externe authenticatie – Gebruikt door gebruikers en externe componenten om te communiceren met de geïnstalleerde frameworks
  • Interne authenticatie – Wordt binnen de kaders gebruikt om de communicatie van interne componenten te authenticeren

Met deze nieuwe functie wordt de interne raamwerkauthenticatie nog steeds beheerd via Kerberos, maar dit is transparant voor de eindgebruikers of externe diensten die aan de andere kant een gebruikersnaam en wachtwoord gebruiken om te authenticeren.

De ondersteunde, door EMR geïnstalleerde raamwerken implementeren een op LDAP gebaseerde authenticatiemethode die, gegeven een set gebruikersnaam en wachtwoord, deze valideert tegen het LDAP-eindpunt en, in het geval van succes, het gebruik van het raamwerk mogelijk maakt.

In het volgende diagram wordt samengevat hoe de authenticatiestroom werkt.

De workflow omvat de volgende stappen:

  1. Een gebruiker maakt verbinding met een van de ondersteunde eindpunten (zoals HiveServer2, Trino/Presto Coordinator of Hue WebUI) en geeft zijn bedrijfsreferenties op (gebruikersnaam en wachtwoord).
  2. Het gecontacteerde raamwerk maakt gebruik van een aangepaste authenticator die de authenticatie uitvoert met behulp van de EMR Secret Agent-service die binnen de clusterinstanties wordt uitgevoerd.
  3. De EMR Secret Agent-service valideert de verstrekte inloggegevens tegen het LDAP-eindpunt.
  4. Bij succes gebeurt het volgende:
    • Er wordt een Kerberos-principal gemaakt voor de specifieke gebruiker op het cluster MIT Key Distribution Center (MIT KDC) dat binnen het primaire knooppunt wordt uitgevoerd.
    • Het Kerberos-hoofdsleuteltabblad wordt gemaakt in de thuismap van de gebruiker op het primaire knooppunt.

Nadat de authenticatie is voltooid, kan de gebruiker het raamwerk gaan gebruiken.

Binnen alle clusterinstances is de SSSD-service geconfigureerd om gebruikers en groepen op te halen van het LDAP-eindpunt en deze beschikbaar te maken als systeemgebruikers.

De authenticatiestroom bij het verbinden met SSH is iets anders en wordt samengevat in het volgende diagram.

De workflow omvat de volgende stappen:

  1. Een gebruiker maakt via SSH verbinding met de primaire EMR-instantie en verstrekt de bedrijfsreferenties (gebruikersnaam en wachtwoord).
  2. De gecontacteerde SSHD-service gebruikt de SSSD-service om de opgegeven inloggegevens te valideren.
  3. De SSSD-service valideert de opgegeven referenties tegen het LDAP-eindpunt. Bij succes komt de gebruiker terecht in de bijbehorende homedirectory. Op dit punt kan de gebruiker de verschillende CLI's gebruiken (beeline, trino-cli, presto-cli, curl) om toegang te krijgen tot Hive, Trino/Presto of Livy.
  4. De Spark CLI's gebruiken (spark-submit, pyspark, spark-shell), moet de gebruiker een beroep doen op de ldap-kinit script en geef de gevraagde gebruikersnaam en het wachtwoord op.
  5. De authenticatie wordt uitgevoerd met behulp van de EMR Secret Agent-service die binnen de clusterinstanties wordt uitgevoerd.
  6. De EMR Secret Agent-service valideert de verstrekte inloggegevens tegen het LDAP-eindpunt.
  7. Bij succes gebeurt het volgende:
    • Er wordt een Kerberos-principal gemaakt voor de specifieke gebruiker op het cluster MIT KDC dat binnen het primaire knooppunt wordt uitgevoerd.
    • Het Kerberos-hoofdsleuteltabblad wordt gemaakt in de thuismap van de gebruiker op het primaire knooppunt.
    • Er wordt een Kerberos-ticket verkregen en opgeslagen in de Kerberos-ticketcache van de gebruiker op het primaire knooppunt.

Na het ldap-kinit script is voltooid, kan de gebruiker de Spark CLI's gaan gebruiken.

In de volgende secties laten we zien hoe u de vereiste LDAP-instellingswaarden kunt ophalen en onderzoeken we hoe u een cluster met EMR LDAP-authenticatie kunt starten en testen.

Zoek de juiste LDAP-parameters

Om LDAP-authenticatie voor Amazon EMR te configureren, bestaat de eerste stap uit het ophalen van de LDAP-eigenschappen die moeten worden gebruikt om uw cluster in te stellen. U heeft de volgende informatie nodig:

  • De DNS-naam van de LDAP-server
  • Een certificaat in PEM-indeling dat moet worden gebruikt voor interactie via Secure LDAP (LDAPS) met het LDAP-eindpunt
  • De zoekbasis voor LDAP-gebruikers, een pad (of vertakking) in de LDAP-structuur van waaruit gebruikers kunnen worden gezocht (alleen gebruikers die tot deze vertakking behoren, worden opgehaald)
  • De zoekbasis voor LDAP-groepen, dit is een pad (of vertakking) in de LDAP-structuur van waaruit naar groepen moet worden gezocht (alleen groepen die tot deze vertakking behoren, worden opgehaald)
  • De LDAP-server bindt gebruikersreferenties, dit zijn de gebruikersnaam en het wachtwoord voor een servicegebruiker (meestal een bindgebruiker genoemd) die moeten worden gebruikt om LDAP-query's te activeren en gebruikersinformatie op te halen, zoals gebruikersnaam en groepslidmaatschap.

Met Active Directory kan een AD-beheerder deze informatie rechtstreeks ophalen uit de Active Directory Users and Computers hulpmiddel. Wanneer u in deze tool een gebruiker kiest, kunt u de gerelateerde kenmerken zien (bijvoorbeeld distinguishedName). De volgende schermafbeelding toont een voorbeeld.

Uit de schermafbeelding kunnen we zien dat de distinguishedName voor de gebruiker john is CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, wat betekent dat john tot de volgende zoekbases behoort, gerangschikt van de meest smalle naar de meest brede:

  • 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

Afhankelijk van het aantal vermeldingen in een bedrijfs-LDAP-directory kan het gebruik van een brede zoekbasis leiden tot lange ophaaltijden en time-outs. Het is een goede gewoonte om de zoekbasis zo smal mogelijk te configureren om alle benodigde gebruikers te omvatten. In het voorgaande voorbeeld OU=users,OU=italy,OU=emr,DC=awsemr,DC=com kan een goede zoekbasis zijn als alle gebruikers die u toegang wilt geven tot het EMR-cluster deel uitmaken van die organisatie-eenheid.

Een andere manier om gebruikerskenmerken op te halen is door gebruik te maken van de ldapzoeken hulpmiddel. U kunt deze methode zowel voor Active Directory als voor OpenLDAP gebruiken, en het is uiterst handig om de connectiviteit met het LDAP-eindpunt te testen.

Het volgende is een voorbeeld met Active Directory (OpenLDAP is vergelijkbaar).

Het LDAP-eindpunt moet oplosbaar en bereikbaar zijn Amazon Elastic Compute-cloud (Amazon EC2) EMR-clusterinstanties via TCP op poort 636. Er wordt voorgesteld om de test uit te voeren vanaf een Amazon Linux 2 EC2-instantie die tot hetzelfde subnet behoort als de EMR-cluster en waaraan dezelfde EMR-beveiligingsgroep is gekoppeld als de EMR-clusterinstanties.

Nadat u een EC2-exemplaar hebt gestart, installeert u het nc tool en test de DNS-resolutie en connectiviteit. In de veronderstelling dat DC1.awsemr.com de DNS-naam is voor het LDAP-eindpunt, voert u de volgende opdrachten uit:

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

Als de DNS-resolutie niet goed werkt, ontvangt u een foutmelding zoals de volgende:

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

Als het eindpunt niet bereikbaar is, ontvangt u een foutmelding zoals de volgende:

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

In beide gevallen moet het netwerk- en DNS-team betrokken worden om de problemen op te lossen en op te lossen.

In geval van succes zou de uitvoer er als volgt uit moeten zien:

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.

Als alles werkt, ga dan verder met testen en installeer het openldap klanten als volgt:

sudo yum install openldap-clients

Ren dan ldapsearch opdrachten om informatie over gebruikers en groepen op te halen van het LDAP-eindpunt. De volgende zijn voorbeelden ldapsearch commando's:

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

Wij gebruiken de volgende parameters:

  • -x – Dit maakt eenvoudige authenticatie mogelijk.
  • -D – Hiermee wordt aangegeven welke gebruiker de zoekopdracht moet uitvoeren.
  • -w – Dit geeft het gebruikerswachtwoord aan.
  • -H – Dit geeft de URL van de LDAP-server aan.
  • -b – Dit is de basiszoekopdracht.
  • LDAPTLS_CACERT – Dit geeft het openbare SSL PEM-certificaat van het LDAPS-eindpunt of het openbare SSL PEM-certificaat van de basiscertificeringsinstantie van het LDAPS-eindpunt aan. Dit kan worden verkregen bij een AD- of OpenLDAP-beheerder.

Het volgende is een voorbeelduitvoer van de voorgaande opdracht:

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

Zoals we kunnen zien aan de hand van de voorbeelduitvoer, is de user John wordt geïdentificeerd door de DN-naam CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=comEn data-engineers groep waartoe de gebruiker behoort (memberOf waarde) wordt geïdentificeerd door de DN-naam CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Wij kunnen onze ldapsearch zoekopdrachten om de gebruikers- en groepsinformatie op te halen met behulp van een beperkte zoekbasis:

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

Tijdens het zoeken kunt u ook andere filters toepassen. Voor meer informatie over het maken van LDAP-filters raadpleegt u LDAP-filters.

Door rennen ldapsearch opdrachten kunt u de LDAP-connectiviteit en LDAP-eigenschappen testen en de benodigde instellingen bepalen.

Test de oplossing

Nadat u hebt gecontroleerd of de connectiviteit met het LDAP-eindpunt open is en de LDAP-configuraties correct zijn, gaat u verder met het instellen van de omgeving om een ​​EMR LDAP-cluster te starten.

Creëer AWS Secret Manager-geheimen

Voordat u de EMR-beveiligingsconfiguratie maakt, moet u er twee maken AWS geheime manager geheimen. U gebruikt deze inloggegevens voor interactie met het LDAP-eindpunt en voor het ophalen van gebruikersgegevens, zoals gebruikersnaam en groepslidmaatschap.

  1. Kies op de Secrets Manager-console Secrets in het navigatievenster.
  2. Kies Bewaar een nieuw geheim.
  3. Voor Geheim typeselecteer Ander soort geheim.
  4. Maak een nieuw geheim aan waarin u de binduser voorname naam als de sleutel en de binduser wachtwoord als waarde.
  5. Maak een tweede geheim en specificeer in leesbare tekst het openbare SSL-certificaat van het LDAPS-eindpunt of het openbare certificaat van de LDAPS-basiscertificeringsinstantie.
    Dit certificaat wordt vertrouwd, waardoor een veilige communicatie tussen het EMR-cluster en het LDAPS-eindpunt mogelijk is.

De EMR-beveiligingsconfiguratie maken

Voer de volgende stappen uit om de EMR-beveiligingsconfiguratie te maken:

  1. Kies op de Amazon EMR-console: Beveiligingsconfiguraties voor EMR op EC2 in het navigatievenster.
  2. Kies creëren.
  3. Voor Naam beveiligingsconfiguratie, voer een naam in.
  4. Voor Instellingsopties voor beveiligingsconfiguratieselecteer Kies aangepaste instellingen.
  5. Voor Encryptieselecteer Schakel encryptie tijdens verzending in.
  6. Voor Type certificaatprovider¸ selecteren PEM.
  7. Voor Kies PEM-certificaatlocatie, voert u een PEM-bundel in die zich in Amazon eenvoudige opslagservice (Amazon S3) of een aangepaste Java-certificaatprovider.
    Houd er rekening mee dat codering tijdens het transport verplicht is om de LDAP-authenticatiefunctie te kunnen gebruiken. Voor meer informatie over encryptie tijdens de overdracht raadpleegt u Het verstrekken van certificaten voor het versleutelen van gegevens die onderweg zijn met Amazon EMR-versleuteling.
  8. Kies Volgende.
  9. kies LDAP For authenticatie protocol.
  10. Voor LDAP-serverlocatie, voer het LDAPS-eindpunt in (ldaps://<ldap_endpoint_DNS_name>).
  11. Voor LDAP SSL-certificaat, voer het tweede geheim in dat u in Secrets Manager hebt gemaakt.
  12. Voor LDAP-toegangsfilterVoer een LDAP-filter in dat wordt toegepast om de toegang te beperken tot een subset van gebruikers die zijn opgehaald uit de LDAP-gebruikerszoekbasis. Als het veld leeg wordt gelaten, worden er geen filters toegepast en hebben alle gebruikers die tot de zoekbasis van LDAP-gebruikers behoren, toegang tot de door EMR LDAP beveiligde eindpunten met hun bedrijfsreferenties. Hieronder volgen voorbeeldfilters en hun functies:
    • (objectKlasse=persoon) – Filter gebruikers met het attribuut objectClass ingesteld als person
    • (memberOf=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com) – Filter gebruikers die behoren tot de admins groep
    • (|(lidvan=CN=data-engineers,OU=groepen,OU=italy,OU=emr,DC=awsemr,DC=com)(lidvan=CN=admins,OU=groepen,OU=italy,OU=emr, DC=awsemr,DC=com)) – Filter gebruikers die behoren tot de data-engineers of de admins groep (die we gebruiken voor dit bericht)
  13. Voer waarden in voor Zoekbasis voor LDAP-gebruikers en Zoekbasis voor LDAP-groepen. Houd er rekening mee dat de twee zoekbases geen inlinefilters ondersteunen (het volgende wordt bijvoorbeeld niet ondersteund: 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. kies Schakel SSH-aanmelding in. Dit is alleen nodig als u wilt dat uw LDAP-gebruikers SSH kunnen gebruiken binnen clusterinstances met hun bedrijfsreferenties. Als SSH-aanmelding is ingeschakeld, is het LDAP-toegangsfilter nodig. Anders mislukt de SSH-authenticatie.
  15. Voor LDAP-serverbindingsreferenties, voer het eerste geheim in dat u in Secrets Manager hebt gemaakt.
  16. In het autorisatie sectie, laat de standaardinstellingen geselecteerd:
    • Voor IAM-rol voor toepassingenselecteer Instantieprofiel.
    • Voor Fijnmazige toegangscontrolemethodeselecteer Geen.
  17. Kies Volgende.
  18. Bekijk het configuratieoverzicht en maak uw keuze creëren.

Lanceer het EMR-cluster

U kunt het EMR-cluster starten met behulp van de AWS-beheerconsole AWS-opdrachtregelinterface (AWS CLI), of een ander AWS-SDK.

Wanneer u het EMR op het EC2-cluster maakt, zorg er dan voor dat u de volgende configuraties opgeeft:

  • EMR-versie – Gebruik Amazon EMR 6.12.0 of hoger.
  • Toepassingen – Selecteer Hadoop, Spark, Hive, Hue, Livy en Presto/Trino.
  • Beveiligingsconfiguratie – Geef de beveiligingsconfiguratie op die u in de vorige stap hebt gemaakt.
  • EC2-sleutelpaar – Gebruik een bestaand sleutelpaar.
  • Netwerk- en beveiligingsgroepen – Gebruik een configuratie waarmee de EMR EC2-instanties kunnen communiceren met het LDAPS-eindpunt. In de Zoek de juiste LDAP-parameters sectie, zou u een geldige configuratie moeten hebben bevestigd.

Controleer of de LDAP-authenticatie werkt

Wanneer het cluster actief is, kunt u controleren of de LDAP-authenticatie goed werkt.

If SSH-login is ingeschakeld als onderdeel van LDAP-authenticatie in de EMR-beveiligingsconfiguratie, kunt u een SSH-verbinding maken met uw cluster door een LDAP-gebruiker op te geven, waarbij u om het bijbehorende wachtwoord wordt gevraagd wanneer daarom wordt gevraagd:

ssh myldapuser@<emr_primary_node>

Als SSH-aanmelding is uitgeschakeld, kunt u binnen het cluster SSH gebruiken met behulp van het EC2-sleutelpaar dat is opgegeven tijdens het maken van het cluster:

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

Een alternatieve manier om toegang te krijgen tot het primaire exemplaar, als u dat wilt, is door gebruik te maken van Session Manager, een vermogen van AWS-systeembeheerder. Voor meer informatie, zie: Maak verbinding met uw Linux-instantie met AWS Systems Manager Session Manager.

Wanneer u zich in de primaire instantie bevindt, kunt u testen of de LDAP-gebruikers en -groepen correct worden opgehaald met behulp van de id commando. Het volgende is een voorbeeldopdracht om te controleren of de user john wordt correct opgehaald met de gerelateerde groepen:

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

Vervolgens kunt u de authenticatie testen op de verschillende geïnstalleerde frameworks.

Laten we eerst het openbare certificaat van het framework ophalen en opslaan in een truststore. Alle frameworks delen hetzelfde openbare certificaat (het certificaat dat we hebben gebruikt om de in-transit-codering in te stellen), zodat u elk van de SSL-beveiligde eindpunten (Hive-poort 10000, Presto/Trino-poort 8446, Livy-poort 8998) kunt gebruiken om het op te halen. . Neem het certificaat van het HiveServer2-eindpunt (poort 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

Gebruik dan deze truststore om veilig te communiceren met de verschillende frameworks.

Gebruik de volgende code om HiveServer2-verificatie te testen 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

Als u Presto gebruikt, test dan de Presto-authenticatie met de presto CLI (geef het gebruikerswachtwoord op wanneer daarom wordt gevraagd):

#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

Als u Trino gebruikt, test dan de Trino-authenticatie met de trino CLI (geef het gebruikerswachtwoord op wanneer daarom wordt gevraagd):

#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 authenticatie met krul:

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

Test Spark-opdrachten met 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()

Merk op dat we hier de authenticatie vanuit het cluster hebben getest, maar we kunnen zelfs van buiten het cluster communiceren met Trino, Hive, Presto en Livy, voor zover de connectiviteit en DNS-resolutie correct zijn geconfigureerd. Spark CLI's zijn de enige die alleen vanuit het cluster kunnen worden gebruikt.

Voer de volgende stappen uit om Hue-authenticatie te testen:

  1. Navigeer naar de Hue-webinterface waarop wordt gehost http://<emr_primary_node>:8888/ en geef een LDAP-gebruikersnaam en wachtwoord op.
  2. Test SQL-query's in de Hive- en Trino/Presto-editors.

Om te testen met een externe SQL-tool (zoals dbeaver verbinden met Trino), voer de volgende stappen uit. Zorg ervoor dat u de EMR-beveiligingsgroep voor het primaire knooppunt zo configureert dat TCP-verkeer van het DBeaver IP naar de gewenste framework-eindpuntpoort wordt toegestaan ​​(bijvoorbeeld 10000 voor HiveServer2, 8446 voor Trino/Presto) en dat u de DNS-resolutie op de DBeaver-client correct configureert machine om de hostnaam van het primaire EMR-knooppunt correct om te zetten.

  1. Kopieer de bestanden vanuit de primaire instantie van uw EMR-cluster naar een S3-bucket truststore.jks (eerder gemaakt) en /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (wijzig de versie XXX afhankelijk van de EMR-versie).
  2. Download op uw DBeaver-clientmachine het truststore.jks en trino-jdbc-XXX-amzn-0.jar bestanden.
  3. Open DBeaver en kies Database, kies dan Driver Manager.
  4. Kies New om een ​​nieuw stuurprogramma te maken.
  5. Op de Instellingen tabblad, geef de volgende informatie op:
    • Voor driver Naam, ga naar binnen EMR Trino.
    • Voor Naam van de klasse, ga naar binnen io.trino.jdbc.TrinoDriver.
    • Voor URL-sjabloon, ga naar binnen jdbc:trino://{host}:{port}.
  6. Op de bibliotheken tabblad, voert u de volgende stappen uit:
    • Kies Bestand toevoegen.
    • Kies het JAR-bestand van het Trino JDBC-stuurprogramma uit het lokale bestandssysteem (trino-jdbc-XXX-amzn-0.jar).
  7. Kies OK om het stuurprogramma te maken.
  8. Kies Database en Nieuwe databaseverbinding.
  9. Op de Hoofd tabblad, geef het volgende op:
    • Voor Maak verbinding viaselecteer gastheer.
    • Voor gastheer, voer het primaire EMR-knooppunt in.
    • Voor Haven, voer de Trino-poort in (standaard 8446).
  10. Op de Eigenschappen stuurprogramma tabblad, voeg de volgende eigenschappen toe:
    • Toevoegen SSL Met True als de waarde.
    • Toevoegen SSLTrustStorePath met de truststore.jks bestandslocatie als waarde.
    • Toevoegen SSLTrustStorePassword met de truststore.jks wachtwoord dat u hebt gebruikt om het te maken, als waarde.
  11. Kies Finish.
  12. Kies de gemaakte verbinding en kies de Verbinden icoon.
  13. Voer uw LDAP-gebruikersnaam en wachtwoord in en kies vervolgens OK.

Als alles werkt, zou u in het navigatievenster door de Trino-catalogi, databases en tabellen moeten kunnen bladeren. Als u query's wilt uitvoeren, kiest u SQL-editor, kies dan Open de SQL-editor.

Vanuit de SQL-editor kunt u uw tabellen opvragen.

Volgende stappen

De nieuwe Amazon EMR LDAP-authenticatiefunctie vereenvoudigt de manier waarop gebruikers toegang kunnen krijgen tot door EMR geïnstalleerde frameworks. Wanneer gebruikers een raamwerk gebruiken, wilt u wellicht bepalen tot welke gegevens zij toegang hebben. Voor dit specifieke onderwerp kunt u LDAP-authenticatie gebruiken in combinatie met de native EMR Apache Ranger-integratie. Voor meer informatie, zie Integreer Amazon EMR met Apache Ranger.

Opruimen

Voer de volgende opruimacties uit om de bronnen te verwijderen die u na dit bericht hebt gemaakt en om extra kosten te voorkomen. Voor dit bericht ruimen we op met behulp van de AWS CLI. Je kunt ook opruimen met soortgelijke acties via de console.

  1. Als u een EC2-instantie hebt gestart om de LDAP-connectiviteit te controleren en deze niet meer nodig hebt, verwijdert u deze met de volgende opdracht (geef uw instantie-ID op): 
    aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>

  2. Als u een EC2-instantie hebt gestart om DBeaver te testen en deze niet meer nodig hebt, kunt u de voorgaande opdracht gebruiken om deze te verwijderen.
  3. Verwijder het EMR-cluster met de volgende opdracht (geef uw EMR-cluster-ID op): 
    aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>

    Houd er rekening mee dat als het EMR-cluster dit heeft Beëindigingsbescherming ingeschakeld, voordat u het voorgaande uitvoert terminate-clusters commando, moet je het uitschakelen. U kunt dit doen met de volgende opdracht (geef uw EMR-cluster-ID op):

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

  4. Verwijder de EMR-beveiligingsconfiguratie met de volgende opdracht: 
    aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

  5. Verwijder de Secrets Manager-geheimen met de volgende opdrachten: 
    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>

Conclusie

In dit bericht hebben we besproken hoe u LDAP-authenticatie op EMR op EC2-clusters kunt configureren en testen. We hebben besproken hoe u de benodigde LDAP-instellingen kunt ophalen, de connectiviteit met het LDAP-eindpunt kunt testen, uw EMR-beveiligingsconfiguratie kunt configureren en kunt testen of de LDAP-authenticatie goed werkt. In dit bericht werd ook benadrukt hoe de authenticatiestroom wordt vereenvoudigd in vergelijking met de standaard Active Directory cross-realm-vertrouwensconfiguratie. Voor meer informatie over deze functie raadpleegt u Gebruik Active Directory- of LDAP-servers voor authenticatie met Amazon EMR.

Over de auteurs

Stefano Sandona is een Senior Big Data Solution Architect bij AWS. Hij houdt van data, gedistribueerde systemen en beveiliging. Hij helpt klanten over de hele wereld bij het ontwerpen van veilige, schaalbare en betrouwbare big data-platforms.

Adnan Hemani is een Software Development Engineer bij AWS en werkt samen met het EMR-team. Hij richt zich op de beveiligingshouding van applicaties die op EMR-clusters draaien. Hij is geïnteresseerd in moderne Big Data-toepassingen en de manier waarop klanten daarmee omgaan.

spot_img

Laatste intelligentie

spot_img

Copyright @ 2024 Plato Technologies Inc.