Molti dei nostri clienti che utilizzano Amazon EMR poiché la loro piattaforma per big data deve integrarsi con la Microsoft Active Directory (AD) esistente per l'autenticazione degli utenti. Questa integrazione richiede che il daemon Kerberos di Amazon EMR stabilisca una connessione affidabile con un dominio AD, che comporta molti spostamenti e può essere difficile da ottenere correttamente.

Questo post descrive cosa significa un trust unidirezionale con Active Directory e come funzionano i comandi utilizzati per configurarlo. Descriviamo in che modo i nomi DNS, gli ambiti Kerberos e i domini AD sono diversi e le conseguenze di ciò per la configurazione della sicurezza Amazon EMR e le impostazioni di attendibilità unidirezionale del cluster. Discutiamo anche di come non è possibile utilizzare Microsoft AD gestito da AWS per il trust del centro di distribuzione delle chiavi (KDC) Amazon EMR e deve utilizzare un server AD esistente o nuovo.

AWS ha già pubblicato documentazione e post di blog che trattano parte di quest'area e questo post intende integrarli anziché sostituirli. Pertanto, ti consigliamo di leggere quanto segue prima di continuare:

È questa l’architettura giusta per te?

Esistono diverse opzioni per autenticare Amazon EMR con Kerberos e la scelta dell'approccio giusto dipenderà dal caso d'uso. Per ulteriori informazioni, fare riferimento a Opzioni dell'architettura Kerberos. In questo post, trattiamo il caso in cui i tuoi utenti si trovano già nel tuo dominio AD e desideri utilizzare tali identità per autorizzare azioni in Amazon EMR. Se non disponi già di un AD o desideri estendere un ambito Kerberos esistente non AD, una delle altre opzioni sarà più adatta. Non lavorare per te stesso più del necessario!

Connessione ad Active Directory

Esistono due obiettivi quando si connette Amazon EMR ad AD:

• Stabilisci un trust unidirezionale da Kerberos ad AD in modo che gli utenti che lavorano in Amazon EMR possano utilizzare le proprie credenziali AD per accedere ai servizi. Ciò richiede che le porte 88, 464 (per Kerberos) e 139 (per LDAP) siano accessibili dal cluster EMR.
• Connettere il cluster EMR con AD in modo che i server che compongono il cluster EMR possano essere registrati nel dominio AD. Ciò richiede un utente configurato nel dominio AD con privilegi sufficienti per effettuare tali registrazioni, in genere chiamato a vincolare l'utente.

Tipi di Active Directory

La combinazione dei requisiti precedenti significa che solo un server AD può soddisfare gli obiettivi. Non puoi utilizzare AWS Managed Microsoft AD né Microsoft Azure AD. Ciò lascia due opzioni come migliore pratica.

Innanzitutto, puoi connettere Amazon EMR direttamente a un server AD esistente (on-premise o nel cloud), come mostrato nel diagramma seguente.

In alternativa, puoi creare un nuovo server AD su Cloud di calcolo elastico di Amazon (Amazon EC2), aggiungerlo alla foresta AD aziendale esistente e fare in modo che Amazon EMR si connetta a questo nuovo server AD basato su cloud (come mostrato nel diagramma seguente).

Domini contro regni

È fondamentale capire quali termini si applicano a quale tecnologia per evitare confusione.

Active Directory gestisce domini, che contengono molte entità registrate come utenti e computer. Solitamente sono scritti in minuscolo (ad esempio, corp.mycompany.com) e sono molto simili ai domini Internet. Non devono necessariamente risolversi in un indirizzo IP, ma in genere lo fanno.

Kerberos utilizza regni per un concetto simile, e le sue entità registrate sono indicate come presidi. I regni sono generalmente scritti in maiuscolo e spesso utilizzano uno stile di denominazione che assomiglia a un dominio Internet tranne che per le maiuscole (ad esempio, EMR.MYCOMPANY.COM). Non è necessario che si risolvano in un indirizzo IP e in genere non lo fanno.

Quando si configura l'area per il demone Kerberos di un cluster EMR, il nome è completamente arbitrario. Funziona come spazio dei nomi per le entità definite al suo interno, ma non deve corrispondere ai nomi di dominio delle istanze nel cluster EMR. Ad esempio, se i nomi DNS privati ​​delle tue macchine EC2 utilizzano il valore predefinito ec2.internal dominio, il nome del tuo realm EMR non deve esserlo ec2.internal; potrebbe essere mykerberosrealm o qualsiasi cosa ti piaccia.

Associa l'utente

È necessario creare un utente di associazione in Active Directory con l'autorizzazione per registrare ("associare") i computer EMR nel dominio AD. Amazon EMR registra questi computer con CN=Computers.

I principi Kerberos creati da Amazon EMR per l'utilizzo con i componenti di Hadoop sono strettamente locali all'installazione Kerberos di Amazon EMR e non sono registrati nel dominio AD.

DNS

Il demone EMR Kerberos deve essere in grado di risolvere il nome DNS del tuo server AD per stabilire la fiducia tra loro. Se questi domini DNS sono gestiti nei server DNS aziendali, è necessario Amazon percorso 53 forwarder ai server DNS aziendali affinché Amazon EMR li risolva. Poiché l'attendibilità è solo unidirezionale, non è necessario che il server AD sia in grado di risolvere i nomi DNS interni dei nodi del cluster EMR.

Stabilire la fiducia

La fiducia che devi stabilire da Amazon EMR ad AD deve essere solo unidirezionale (Amazon EMR si fida di AD), non bidirezionale (si fidano l'uno dell'altro). Per stabilire la fiducia unidirezionale, utilizzare il file ksetup ed netdom utilità sulla riga di comando della macchina AD. L'attributo del tipo di crittografia consigliato (SetEncTypeAttr) per il dominio è un codice AES-256. Il codice seguente utilizza l'esempio dell'ambito EMR Kerberos EMR.MYCOMPANY.COM e il dominio AD 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

Nel primo ksetup comando, non è necessario fornire il nome di dominio completo del KDC del cluster come argomento finale. Ciò è necessario solo per un trust bidirezionale ed è facoltativo in un trust unidirezionale.

Configurazione della sicurezza di Amazon EMR

Prima di avviare il cluster EMR, devi creare una configurazione di sicurezza che contenga i dettagli del server AD e del dominio a cui ti stai connettendo. Lo screenshot seguente mostra un esempio di tale configurazione.

Questi campi fanno distinzione tra maiuscole e minuscole, quindi assicurati di inserire tutto correttamente. Tieni presente che il dominio e l'area di autenticazione in questa configurazione si riferiscono entrambi al server AD e non al cluster EMR! Poiché AD può agire sia come demone Kerberos che come Active Directory, entrambi i campi vengono configurati qui. In entrambi i casi, però, si riferiscono al server AD e non al dominio Kerberos del cluster EMR.

Opzioni di sicurezza di Amazon EMR all'avvio di un cluster

Quando avvii un cluster EMR, configuri le opzioni di sicurezza come mostrato nello screenshot seguente.

Qui puoi utilizzare la configurazione di sicurezza appena creata e specificare i dettagli del realm EMR Kerberos nonché i parametri necessari per stabilire la fiducia con il dominio AD nella configurazione di sicurezza. Fornisci informazioni per i seguenti campi:

• Regno – Il realm Kerberos che specifichi dipende interamente da te, ma deve essere lo stesso che hai utilizzato quando hai stabilito il trust sulla macchina AD.
• Password dell'amministratore KDC – Questo non viene utilizzato in nessun'altra parte della configurazione del cluster, quindi puoi impostarlo su qualcosa di unico e sicuro specificamente per questo cluster. È necessario solo per qualsiasi gestione futura del KDC dedicato al cluster.
• Password principale di trust tra realm – Questa è la password impostata con netdom comando.
• Utente aggiunto al dominio Active Directory –Questo è l'utente di associazione creato dall'amministratore AD.
• Password di aggiunta al dominio Active Directory – Questa è la password per l'utente di associazione da AD.

ripulire

Una volta terminato il test di questa soluzione, ricordati di ripulire le risorse. Se hai utilizzato i modelli CloudFormation per creare le risorse, utilizza la console AWS CloudFormation per eliminare lo stack. In alternativa è possibile utilizzare il Interfaccia della riga di comando di AWS (AWS CLI) o SDK. Per istruzioni, fare riferimento a Eliminazione di una pila. L'eliminazione di uno stack elimina anche le risorse create da quello stack.

Se uno dei tuoi stack non viene eliminato, assicurati che non vi siano dipendenze dalle risorse create da quello stack. Ad esempio, se hai distribuito un Amazon VPC utilizzando AWS CloudFormation e quindi distribuito un controller di dominio in quel VPC utilizzando uno stack CloudFormation diverso, devi prima eliminare lo stack del controller di dominio prima di poter eliminare lo stack VPC.

Conclusione

I passaggi descritti in questo post ti hanno guidato nella creazione del trust tra il daemon Kerberos di Amazon EMR e un dominio Active Directory. Ci auguriamo che questo abbia demistificato il processo e semplifichi la creazione futura di cluster EMR sicuri e integrati con AD.

Informazioni sugli autori

Anandkumar Kaliaperumal è un Senior Data Architect presso Professional Services SDT, dove si concentra sull'aiutare i clienti con le migrazioni di Hadoop e data Lake. Vive con la sua famiglia in crescita a Dallas.

Bharath Kumar Boggarapu è un Data Architect presso AWS Professional Services con esperienza nelle tecnologie Big Data. La sua passione è aiutare i clienti a creare soluzioni basate sui dati robuste e performanti e a realizzare il loro potenziale di dati e analisi. Le sue aree di interesse sono i framework open source, l'automazione e l'architettura dei dati. Nel tempo libero ama stare con la famiglia, giocare a tennis e viaggiare.

Oliver Mayn è stato Senior Data Architect nel team canadese di distribuzione condivisa dei servizi professionali, dove ha aiutato i clienti a migrare i propri dati e flussi di lavoro su AWS. Vive a Toronto con la sua famiglia e troppe biciclette.