Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Opzioni di architettura di Kerberos
Quando usi Kerberos con AmazonEMR, puoi scegliere tra le architetture elencate in questa sezione. Indipendentemente dall'architettura scelta, Kerberos può essere configurato con la stessa procedura. Crei una configurazione di sicurezza, specifichi la configurazione di sicurezza e le opzioni Kerberos compatibili specifiche del cluster quando crei il cluster e crei HDFS directory per gli utenti Linux sul cluster che corrispondono ai principali utenti di. KDC Per una spiegazione delle opzioni di configurazione ed esempi di configurazione per ogni architettura, consulta Configurazione di Kerberos su Amazon EMR.
Dedicato al cluster (sul nodo primario) KDC KDC
Questa configurazione è disponibile con le EMR versioni di Amazon 5.10.0 e successive.
Vantaggi
-
Amazon EMR ha la piena proprietà diKDC.
-
Il KDC EMR cluster è indipendente da KDC implementazioni centralizzate come Microsoft Active Directory o AWS Managed Microsoft AD.
-
L'impatto sulle prestazioni è minimo perché KDC gestisce l'autenticazione solo per i nodi locali all'interno del cluster.
-
Facoltativamente, altri cluster Kerberizzati possono fare riferimento a tali cluster come esterni. KDC KDC Per ulteriori informazioni, consulta EsternoKDC: nodo primario su un cluster diverso.
Considerazioni e limitazioni
-
I cluster con Kerberos non possono eseguire l'autenticazione tra di loro, quindi le applicazioni non possono interagire. Se le applicazioni cluster devono interagire, è necessario stabilire un trust tra i cluster o configurare un cluster come esterno per altri cluster. KDC Se viene stabilito un trust tra più realm, deve avere realm Kerberos diversi. KDCs
-
È necessario creare utenti Linux sull'EC2istanza del nodo primario che corrispondono ai principali utenti, insieme alle directory per ogni KDC utente. HDFS
-
I principali utenti devono utilizzare un file di chiave EC2 privata e
kinitcredenziali per connettersi al cluster utilizzando. SSH
Fiducia tra realm
In questa configurazione, i principali (in genere gli utenti) di un altro realm Kerberos si autenticano sui componenti dell'applicazione su un cluster EMR Kerberized, che ne ha uno proprio. KDC Il KDC nodo primario stabilisce una relazione di trust con un altro KDC utilizzando un principio interrealm esistente in entrambi. KDCs Il nome principale e la password corrispondono esattamente in ciascuno di essi. KDC I trust tra realm sono più comuni nelle implementazioni con Active Directory, come illustrato nel seguente diagramma. Sono supportati anche i trust cross-realm con un EMR cluster Amazon esterno MIT KDC o su un KDC altro.
Vantaggi
-
Il EMR cluster su cui KDC è installato mantiene la piena proprietà di. KDC
-
Con Active Directory, Amazon crea EMR automaticamente utenti Linux che corrispondono ai principali utenti diKDC. È comunque necessario creare HDFS directory per ogni utente. Inoltre, i principali utenti nel dominio Active Directory possono accedere ai cluster Kerberized utilizzando
kinitle credenziali, senza il file della chiave privata. EC2 In questo modo viene meno la necessità di condividere il file di chiave privata tra gli utenti del cluster. -
Poiché ogni cluster KDC gestisce l'autenticazione per i nodi del cluster, gli effetti della latenza di rete e del sovraccarico di elaborazione per un gran numero di nodi tra i cluster sono ridotti al minimo.
Considerazioni e limitazioni
-
Se si sta creando un trust con un realm Active Directory, è necessario fornire un nome utente e una password di Active Directory con le autorizzazioni per l'aggiunta di principali al dominio in cui si crea il cluster.
-
Non è possibile stabilire trust tra realm Kerberos con lo stesso nome.
-
I trust tra realm devono essere stabiliti in modo esplicito. Ad esempio, se il Cluster A e il Cluster B stabiliscono entrambi un trust interrealm con aKDC, non si fidano intrinsecamente l'uno dell'altro e le loro applicazioni non possono autenticarsi tra loro per interagire.
-
KDCsdevono essere gestite in modo indipendente e coordinato in modo che le credenziali dei principali utenti corrispondano esattamente.
Esterno KDC
Le configurazioni con un dispositivo esterno KDC sono supportate con Amazon EMR 5.20.0 e versioni successive.
Esterno: KDC MIT KDC
Questa configurazione consente a uno o più EMR cluster di utilizzare i principi definiti e gestiti in un MIT KDC server.
Vantaggi
-
La gestione dei presidi è consolidata in un'unica soluzione. KDC
-
Più cluster possono utilizzare gli stessi KDC nello stesso realm Kerberos. Per ulteriori informazioni, consulta Requisiti per l'utilizzo di più cluster con lo stesso KDC.
-
Il nodo primario di un cluster Kerberized non ha l'onere prestazionale associato alla manutenzione di. KDC
Considerazioni e limitazioni
-
È necessario creare utenti Linux sull'EC2istanza di ogni nodo primario del cluster Kerberized che corrispondono ai principali utenti, insieme alle directory per ogni KDC utente. HDFS
-
I principali utenti devono utilizzare un file di chiave EC2 privata e
kinitcredenziali per connettersi ai cluster Kerberized utilizzando. SSH -
Ogni nodo nei EMR cluster Kerberized deve avere un percorso di rete verso. KDC
-
Ogni nodo nei cluster Kerberized impone un onere di autenticazione all'esternoKDC, quindi la configurazione dei cluster influisce sulle prestazioni del cluster. KDC Quando configuri l'hardware del KDC server, considera il numero massimo di EMR nodi Amazon da supportare contemporaneamente.
-
Le prestazioni del cluster dipendono dalla latenza di rete tra i nodi dei cluster Kerberized e il. KDC
-
La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
EsternoKDC: nodo primario su un cluster diverso
Questa configurazione è quasi identica all'MITKDCimplementazione esterna precedente, tranne per il fatto che KDC si trova sul nodo primario di un EMR cluster. Per ulteriori informazioni, consulta Dedicato al cluster (sul nodo primario) KDC KDC e Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory.
Vantaggi
-
La gestione dei principali è consolidata in un'unica soluzione. KDC
-
Più cluster possono utilizzare gli stessi KDC nello stesso realm Kerberos. Per ulteriori informazioni, consulta Requisiti per l'utilizzo di più cluster con lo stesso KDC.
Considerazioni e limitazioni
-
È necessario creare utenti Linux sull'EC2istanza del nodo primario di ogni cluster Kerberized che corrispondono ai principali utenti, insieme alle directory per ogni KDC utente. HDFS
-
I principali utenti devono utilizzare un file di chiave EC2 privata e
kinitcredenziali per connettersi ai cluster Kerberized utilizzando. SSH -
Ogni nodo di ogni EMR cluster deve avere un percorso di rete verso. KDC
-
Ogni EMR nodo Amazon nei cluster Kerberized impone un onere di autenticazione all'esternoKDC, quindi la configurazione del nodo KDC influisce sulle prestazioni del cluster. Quando configuri l'hardware del KDC server, considera il numero massimo di EMR nodi Amazon da supportare contemporaneamente.
-
Le prestazioni del cluster dipendono dalla latenza di rete tra i nodi dei cluster e il. KDC
-
La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
EsternoKDC: cluster KDC su un cluster diverso con trust cross-realm di Active Directory
In questa configurazione, si crea innanzitutto un cluster con un cluster dedicato KDC che dispone di un trust multirealm unidirezionale con Active Directory. Per un tutorial dettagliato, consulta Tutorial: Configurazione di un trust tra realm con un controller di dominio Active Directory. Si avviano quindi cluster aggiuntivi, facendo riferimento al cluster KDC che dispone del trust come elemento esterno. KDC Per vedere un esempio, consulta Cluster esterno KDC con trust cross-realm di Active Directory. Ciò consente a ciascun EMR cluster Amazon che utilizza l'esterno di KDC autenticare i principali definiti e gestiti in un dominio Microsoft Active Directory.
Vantaggi
-
La gestione dei principali è consolidata nel dominio Active Directory.
-
Amazon EMR entra a far parte del regno di Active Directory, che elimina la necessità di creare utenti Linux che corrispondano agli utenti di Active Directory. È comunque necessario creare HDFS directory per ogni utente.
-
Più cluster possono utilizzare le stesse KDC nello stesso realm Kerberos. Per ulteriori informazioni, consulta Requisiti per l'utilizzo di più cluster con lo stesso KDC.
-
I principali utenti nel dominio Active Directory possono accedere ai cluster Kerberized utilizzando
kinitle credenziali, senza il file della chiave privata. EC2 In questo modo viene meno la necessità di condividere il file di chiave privata tra gli utenti del cluster. -
Solo un nodo EMR primario di Amazon ha l'onere di mantenere il clusterKDC, e solo quel cluster deve essere creato con credenziali Active Directory per la fiducia tra i due KDC e Active Directory.
Considerazioni e limitazioni
-
Ogni nodo di ogni EMR cluster deve avere un percorso di rete verso KDC e il controller di dominio Active Directory.
-
Ogni EMR nodo Amazon impone un onere di autenticazione all'esternoKDC, quindi la configurazione del nodo KDC influisce sulle prestazioni del cluster. Quando configuri l'hardware del KDC server, considera il numero massimo di EMR nodi Amazon da supportare contemporaneamente.
-
Le prestazioni del cluster dipendono dalla latenza di rete tra i nodi dei cluster e il KDC server.
-
La risoluzione dei problemi può essere più difficile a causa delle interdipendenze.
Requisiti per l'utilizzo di più cluster con lo stesso KDC
Più cluster possono utilizzare gli stessi KDC nello stesso realm Kerberos. Tuttavia, se i cluster vengono eseguiti contemporaneamente, potrebbero fallire se utilizzano nomi Kerberos in conflitto. ServicePrincipal
Se disponi di più cluster simultanei con lo stesso ambiente esternoKDC, assicurati che i cluster utilizzino realm Kerberos diversi. Se i cluster devono utilizzare lo stesso realm Kerberos, assicurati che si trovino in sottoreti diverse e che i loro intervalli non si sovrappongano. CIDR
