Zephyrnet-logo

Diepe duik in Amazon EMR Kerberos-authenticatie geïntegreerd met Microsoft Active Directory

Datum:

Veel van onze klanten die gebruik maken van Amazon EMR omdat hun big data-platform moet worden geïntegreerd met hun bestaande Microsoft Active Directory (AD) voor gebruikersauthenticatie. Deze integratie vereist dat de Kerberos-daemon van Amazon EMR een vertrouwde verbinding tot stand brengt met een AD-domein, wat veel bewegende delen met zich meebrengt en moeilijk kan zijn om goed te krijgen.

Dit bericht beschrijft wat een eenrichtingsvertrouwen met Active Directory betekent en hoe de opdrachten werken die worden gebruikt bij het instellen ervan. We beschrijven hoe DNS-namen, Kerberos-realms en AD-domeinen verschillen, en wat de gevolgen daarvan zijn voor de Amazon EMR-beveiligingsconfiguratie en de eenrichtingsvertrouwensinstellingen voor clusters. We bespreken ook hoe je niet kunt gebruiken AWS beheerde Microsoft AD voor het vertrouwen van het Amazon EMR-sleuteldistributiecentrum (KDC), en moet een bestaande of nieuwe AD-server gebruiken.

AWS heeft al documentatie en blogberichten gepubliceerd die een deel van dit gebied bestrijken, en dit bericht is bedoeld om ze aan te vullen in plaats van ze te vervangen. Daarom raden we u aan het volgende te lezen voordat u verdergaat:

Is dit de juiste architectuur voor jou?

Er zijn verschillende opties voor het verifiëren van Amazon EMR met Kerberos, en het kiezen van de juiste aanpak hangt af van uw gebruiksscenario. Voor meer informatie, zie: Kerberos-architectuuropties. In dit bericht behandelen we het geval waarin uw gebruikers zich al in uw AD-domein bevinden en u die identiteiten wilt gebruiken om acties in Amazon EMR te autoriseren. Als je nog geen AD hebt, of als je een bestaande niet-AD Kerberos-realm wilt uitbreiden, dan is een van de andere opties beter geschikt. Maak niet meer werk voor jezelf dan nodig is!

Verbinding maken met Active Directory

Er zijn twee doelen bij het verbinden van Amazon EMR met AD:

  • Breng een eenrichtingsvertrouwen tot stand met van Kerberos naar AD, zodat gebruikers die in Amazon EMR werken, hun AD-referenties kunnen gebruiken om toegang te krijgen tot services. Hiervoor moeten poorten 88, 464 (voor Kerberos) en 139 (voor LDAP) toegankelijk zijn vanuit het EMR-cluster.
  • Verbind het EMR-cluster met AD zodat de servers waaruit het EMR-cluster bestaat, kunnen worden geregistreerd in het AD-domein. Dit vereist een gebruiker die is geconfigureerd in het AD-domein met voldoende rechten om die registraties uit te voeren, meestal a . genoemd bind gebruiker.

Typen Active Directory

De combinatie van de voorgaande vereisten betekent dat alleen een AD-server aan de doelen kan voldoen. U kunt geen door AWS beheerde Microsoft AD of Microsoft Azure AD gebruiken. Dit laat twee opties als de beste praktijk.

Ten eerste kunt u Amazon EMR rechtstreeks verbinden met een bestaande AD-server (on-premises of in de cloud), zoals weergegeven in het volgende diagram.

Als alternatief kunt u een nieuwe AD-server bouwen op: Amazon Elastic Compute-cloud (Amazon EC2), voeg het toe aan het bestaande zakelijke AD-forest en laat Amazon EMR verbinding maken met deze nieuwe cloudgebaseerde AD-server (zoals weergegeven in het volgende diagram).

Domeinen versus rijken

Het is van cruciaal belang om te begrijpen welke termen van toepassing zijn op welke technologie om verwarring te voorkomen.

Active Directory beheert domeinen, die veel geregistreerde entiteiten zoals gebruikers en computers bevatten. Ze worden meestal in kleine letters geschreven (bijvoorbeeld corp.mycompany.com) en lijken erg op internetdomeinen. Ze hoeven niet per se naar een IP-adres te worden omgezet, maar dat doen ze meestal wel.

Kerberos gebruikt rijken voor een soortgelijk concept, en de geregistreerde entiteiten worden aangeduid als opdrachtgevers. Realms worden meestal in hoofdletters geschreven en gebruiken vaak een naamgevingsstijl die eruitziet als een internetdomein, behalve de hoofdletters (bijvoorbeeld EMR.MYCOMPANY.COM). Ze hoeven niet naar een IP-adres te worden omgezet en doen dat meestal ook niet.

Bij het configureren van de realm voor de Kerberos-daemon van een EMR-cluster is de naam volledig willekeurig. Het dient als een naamruimte voor de principals die erin zijn gedefinieerd, maar het hoeft niet overeen te komen met de domeinnamen van de instanties in uw EMR-cluster. Als de privé-DNS-namen van uw EC2-machines bijvoorbeeld de standaard ec2.internal domein, hoeft uw EMR-realmnaam niet te zijn ec2.internal; het zou kunnen mykerberosrealm of wat je maar wilt.

Gebruiker binden

Een bind-gebruiker moet worden aangemaakt in Active Directory met toestemming om EMR-computers te registreren (“binden”) in het AD-domein. Amazon EMR registreert deze computers onder: CN=Computers.

De Kerberos-principals die Amazon EMR maakt voor gebruik met de componenten van Hadoop zijn strikt lokaal voor de Amazon EMR Kerberos-installatie - ze zijn niet geregistreerd in het AD-domein.

DNS

De EMR Kerberos-daemon moet de DNS-naam van uw AD-server kunnen omzetten om de onderlinge vertrouwensrelatie tot stand te brengen. Als die DNS-domeinen worden beheerd in uw zakelijke DNS-servers, moet u: Amazon Route 53 doorstuurservers naar uw zakelijke DNS-servers voor Amazon EMR om ze op te lossen. Omdat de vertrouwensrelatie slechts in één richting is, hoeft de AD-server de interne DNS-namen van de EMR-clusterknooppunten niet om te zetten.

Vestig vertrouwen

Het vertrouwen dat u moet opbouwen van Amazon EMR naar AD hoeft slechts eenrichtingsverkeer te zijn (Amazon EMR vertrouwt AD), niet tweerichtingsverkeer (ze vertrouwen elkaar). Om het eenrichtingsvertrouwen tot stand te brengen, gebruikt u de ksetup en netdom hulpprogramma's op de opdrachtregel van de AD-machine. Het aanbevolen coderingstypekenmerk (SetEncTypeAttr) voor het domein is een AES-256-cijfer. De volgende code gebruikt het voorbeeld van de EMR Kerberos-realm EMR.MYCOMPANY.COM en het AD-domein corp.mycompany.com:

C:UsersAdministrator> ksetup /addkdc EMR.MYCOMPANY.COM
C:UsersAdministrator> netdom trust EMR.MYCOMPANY.COM /Domain:corp.mycompany.com /add /realm /passwordt:MyVeryStrongPassword
C:UsersAdministrator> ksetup /SetEncTypeAttr EMR.MYCOMPANY.COM AES256-CTS-HMAC-SHA1-96

In de eerste ksetup commando, hoeft u niet de volledig gekwalificeerde domeinnaam van het cluster KDC op te geven als laatste argument. Dat is alleen nodig voor een tweerichtingsvertrouwen en is optioneel in een eenrichtingsvertrouwen.

Amazon EMR-beveiligingsconfiguratie

Voordat u het EMR-cluster start, moet u een beveiligingsconfiguratie maken die de details bevat van de AD-server en het domein waarmee u verbinding maakt. De volgende schermafbeelding toont een voorbeeld van die configuratie.

Deze velden zijn hoofdlettergevoelig, dus zorg ervoor dat u alles correct invoert. Merk op dat het domein en de realm in deze configuratie beide verwijzen naar de AD-server en niet naar het EMR-cluster! Omdat AD zowel als Kerberos-daemon als Active Directory kan fungeren, worden beide velden hier geconfigureerd. In beide gevallen verwijzen ze echter naar de AD-server en niet naar het Kerberos-domein van het EMR-cluster.

Amazon EMR-beveiligingsopties bij het starten van een cluster

Wanneer u een EMR-cluster start, configureert u de beveiligingsopties zoals weergegeven in de volgende schermafbeelding.

Hier gebruikt u de beveiligingsconfiguratie die u zojuist hebt gemaakt en geeft u de details van de EMR Kerberos-realm op, evenals de parameters die nodig zijn om de vertrouwensrelatie met het AD-domein in de beveiligingsconfiguratie tot stand te brengen. U geeft informatie op voor de volgende velden:

  • Rijk – De Kerberos-realm die u opgeeft, is geheel aan u, maar moet dezelfde zijn als degene die u hebt gebruikt bij het tot stand brengen van de vertrouwensrelatie op de AD-machine.
  • KDC-beheerderswachtwoord – Dit wordt nergens anders in de clusterconfiguratie gebruikt, dus u kunt het instellen op iets unieks en veiligs, specifiek voor dit cluster. Het is alleen nodig voor toekomstig beheer van het clusterspecifieke KDC.
  • Cross-realm trust-principal wachtwoord – Dit is het wachtwoord dat u instelt met de netdom opdracht.
  • Active Directory-domein lid worden van gebruiker –Dit is de bind-gebruiker die uw AD-beheerder heeft gemaakt.
  • Wachtwoord voor deelname aan Active Directory-domein – Dit is het wachtwoord voor de bind-gebruiker van AD.

Opruimen

Wanneer u klaar bent met het testen van deze oplossing, vergeet dan niet om de bronnen op te schonen. Als je de CloudFormation-sjablonen hebt gebruikt om de bronnen te maken, gebruik dan de AWS CloudFormation-console om de stapel te verwijderen. Als alternatief kunt u de AWS-opdrachtregelinterface (AWS CLI) of SDK's. Raadpleeg voor instructies: Een stapel verwijderen. Als u een stapel verwijdert, worden ook de bronnen verwijderd die door die stapel zijn gemaakt.

Als een van uw stapels niet wordt verwijderd, moet u ervoor zorgen dat er geen afhankelijkheden zijn van de bronnen die door die stapel zijn gemaakt. Als u bijvoorbeeld een Amazon VPC hebt geïmplementeerd met AWS CloudFormation en vervolgens een domeincontroller in die VPC hebt geïmplementeerd met een andere CloudFormation-stack, moet u eerst de domeincontrollerstack verwijderen voordat u de VPC-stack kunt verwijderen.

Conclusie

De stappen in dit bericht hebben u begeleid bij het creëren van vertrouwen tussen de Kerberos-daemon van Amazon EMR en een Active Directory-domein. We hopen dat dit het proces heeft gedemystificeerd en het voor u gemakkelijk maakt om in de toekomst veilige, AD-geïntegreerde EPD-clusters te creëren.


Over de auteurs

Anandkumar Kaliaperumal is Senior Data Architect bij de Professional Services SDT, waar hij zich richt op het helpen van klanten met hun Hadoop- en datalakemigraties. Hij woont met zijn groeiende gezin in Dallas.

Bharat Kumar Boggarapu is een Data Architect bij AWS Professional Services met expertise in big data-technologieën. Hij heeft een passie voor het helpen van klanten bij het bouwen van performante en robuuste datagestuurde oplossingen en het realiseren van hun data- en analysepotentieel. Zijn interessegebieden zijn open-source frameworks, automatisering en data-architecting. In zijn vrije tijd brengt hij graag tijd door met het gezin, tennist en reist hij graag.

Oliver Mein was Senior Data Architect in het Canadian Professional Services Shared Delivery Team, waar hij klanten hielp met het migreren van hun data en workflows naar AWS. Hij woont in Toronto met zijn gezin en veel te veel fietsen.

spot_img

Laatste intelligentie

spot_img