Plugin EMRFS S3 per l'integrazione di Ranger con Amazon EMR

Per semplificare la fornitura di controlli degli accessi agli oggetti in S3 in un cluster multi-tenant, il plug-in EMRFS S3 fornisce controlli degli accessi ai dati all'interno di S3 quando vi si accede tramite EMRFS. È possibile consentire l'accesso alle risorse S3 a livello di utente e gruppo.

Per raggiungere questo obiettivo, quando l'applicazione tenta di accedere ai dati all'interno di S3, EMRFS invia una richiesta di credenziali al processo Secret Agent, in cui la richiesta viene autenticata e autorizzata rispetto a un plug-in Apache Ranger. Se la richiesta è autorizzata, l'agente segreto assume il ruolo IAM per Apache Ranger Engines con una policy limitata per generare credenziali che hanno accesso solo alla policy Ranger che ha consentito l'accesso. Le credenziali vengono quindi passate a EMRFS per accedere a S3.

Funzionalità supportate

Il plug-in EMRFS S3 fornisce l'autorizzazione a livello di archiviazione. È possibile creare policy che consentano l'accesso di utenti e gruppi a bucket e prefissi S3. L'autorizzazione è gestita solo rispetto a EMRFS.

Installazione della configurazione del servizio

Per installare la definizione del servizio EMRFS, devi configurare il server di amministrazione Ranger. Per configurare il server, vedere. Configura un server di amministrazione Ranger per l'integrazione con Amazon EMR

Attenersi alla seguente procedura per installare la definizione del servizio EMRFS.

Fase 1: SSH nel server Admin Apache Ranger.

Per esempio:

ssh [e-mail]

Fase 2: Scarica la definizione del servizio EMRFS.

In una directory temporanea, scarica la definizione del servizio Amazon EMR. Questa definizione del servizio è supportata dalle versioni Ranger 2.x.

wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json

Fase 3: Registrare la definizione del servizio EMRFS S3.

curl -u *<admin users login>*:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://*<RANGER SERVER ADDRESS>*:6182/service/public/v2/api/servicedef'

Se questo comando viene eseguito correttamente, viene visualizzato un nuovo servizio nell'interfaccia utente del server Admin Ranger denominato "AMAZON-EMR-S3", come mostrato nell'immagine seguente (Ranger versione 2.0).

Fase 4: Creare un'istanza dell'applicazione. AMAZON-EMR-EMRFS

Crea un'istanza della definizione del servizio.

• Fai clic sul segno + accanto a AMAZON-EMR-EMRFS.

Riempi i seguenti campi:

Nome del servizio (se visualizzato): il valore suggerito èamazonemrs3. Prendi nota di questo nome del servizio dal momento che sarà necessario quando crei una configurazione di sicurezza EMR.

Nome visualizzato: immetti il nome da visualizzare per il servizio. Il valore suggerito è amazonemrs3.

Nome comune per certificato: il campo CN all'interno del certificato utilizzato per connettersi al server Admin da un plug-in client. Questo valore deve corrispondere al campo CN nel certificato TLS creato per il plug-in.

Nota

Il certificato TLS per questo plug-in dovrebbe essere stato registrato nel truststore sul server Admin Ranger. Per ulteriori dettagli, consulta Certificati TLS per l'integrazione di Apache Ranger con Amazon EMR.

Quando viene creato il servizio, il Service Manager include "AMAZON-EMR-EMRFS", come mostrato nell'immagine seguente.

Creazione di policy EMRFS S3

Per creare una nuova policy, nella pagina Create Policy (Crea policy) del Service Manager compila i campi riportati di seguito.

Nome policy: il nome della policy.

Etichetta policy: un'etichetta che è possibile inserire in questa policy.

Risorsa S3: una risorsa che inizia con il bucket e il prefisso facoltativo. Per ulteriori informazioni sulle best practice, consulta Note sull'utilizzo delle policy EMRFS S3. Le risorse nel server Admin Ranger non devono contenere s3://, s3a:// o s3n://.

È possibile specificare utenti e gruppi per concedere le autorizzazioni. È inoltre possibile specificare delle esclusioni per consentire e negare le condizioni.

Nota

Sono consentite al massimo tre risorse per ogni policy. L'aggiunta di più di tre risorse può causare un errore quando questa policy viene utilizzata in un cluster EMR. L'aggiunta di più di tre policy consente di visualizzare un promemoria relativo al limite di policy.

Note sull'utilizzo delle policy EMRFS S3

Quando si creano policy S3 all'interno di Apache Ranger, occorre tenere a mente alcune considerazioni sull'utilizzo.

Autorizzazioni a più oggetti S3

È possibile utilizzare policy ricorrenti ed espressioni con caratteri jolly per concedere autorizzazioni a più oggetti S3 con prefissi comuni. Le policy ricorrenti forniscono autorizzazioni a tutti gli oggetti con un prefisso comune. Le espressioni con caratteri jolly selezionano più prefissi. Insieme, forniscono le autorizzazioni a tutti gli oggetti con più prefissi comuni, come mostrato nei seguenti esempi.

Esempio Utilizzo di una policy ricorrente

Supponiamo che necessiti di autorizzazioni per elencare tutti i file parquet in un bucket S3 organizzato come segue.

s3://sales-reports/americas/
    +- year=2000
    |      +- data-q1.parquet
    |      +- data-q2.parquet
    +- year=2019
    |      +- data-q1.json
    |      +- data-q2.json
    |      +- data-q3.json
    |      +- data-q4.json
    |
    +- year=2020
    |      +- data-q1.parquet
    |      +- data-q2.parquet
    |      +- data-q3.parquet
    |      +- data-q4.parquet
    |      +- annual-summary.parquet    
    +- year=2021

Innanzitutto, considera i file parquet con il prefisso s3://sales-reports/americas/year=2000. Puoi concedere GetObject le autorizzazioni a tutti in due modi:

Utilizzo di policy non ricorrenti: un'opzione consiste nell'utilizzare due policy non ricorrenti separate, una per la directory e l'altra per i file.

La prima policy concede l'autorizzazione al prefisso s3://sales-reports/americas/year=2020 (non è presente il / finale).

- S3 resource = "sales-reports/americas/year=2000"
- permission = "GetObject"
- user = "analyst"

La seconda policy utilizza l'espressione jolly per concedere autorizzazioni a tutti i file con prefisso sales-reports/americas/year=2020/ (nota il / finale).

- S3 resource = "sales-reports/americas/year=2020/*"
- permission = "GetObject"
- user = "analyst"

Utilizzo di una policy ricorrente: un'alternativa più conveniente consiste nell'utilizzare una singola policy ricorrente e concedere l'autorizzazione ricorrente al prefisso.

 - S3 resource = "sales-reports/americas/year=2020"
 - permission = "GetObject"
 - user = "analyst"
 - is recursive = "True"

Finora, solo i file parquet con il prefisso s3://sales-reports/americas/year=2000 sono stati inclusi. È ora possibile includere anche i file parquet con un prefisso diverso, s3://sales-reports/americas/year=2020, nella stessa policy ricorrente introducendo un'espressione con caratteri jolly come segue.

 - S3 resource = "sales-reports/americas/year=20?0"
 - permission = "GetObject"
 - user = "analyst"
 - is recursive = "True"

Politiche PutObject e DeleteObject autorizzazioni

La scrittura di politiche PutObject e DeleteObject autorizzazioni per i file su EMRFS richiede un'attenzione speciale perché, a differenza delle autorizzazioni, richiedono GetObject autorizzazioni ricorsive aggiuntive concesse al prefisso.

Esempio Politiche PutObject DeleteObject e autorizzazioni

Ad esempio, l'eliminazione del file non annual-summary.parquet richiede solo l' DeleteObject autorizzazione per il file effettivo.

- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "DeleteObject"
- user = "analyst"

ma anche una policy che conceda autorizzazioni ricorrenti GetObject e PutObject per il suo prefisso.

Allo stesso modo, la modifica del file annual-summary.parquet richiede non solo un'autorizzazione PutObject per il file effettivo,

- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "PutObject"
- user = "analyst"

ma anche una policy che conceda l'autorizzazione ricorrente GetObject per il suo prefisso.

- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"

Caratteri jolly nelle policy

Sono disponibili due aree in cui è possibile specificare i caratteri jolly. Quando si specifica una risorsa S3, è possibile utilizzare i valori "*" e "?". "*" fornisce la corrispondenza con un percorso S3 e corrisponde a tutto ciò che viene dopo il prefisso. Per esempio, la seguente policy.

S3 resource = "sales-reports/americas/*"

Questo corrisponde ai seguenti percorsi S3.

sales-reports/americas/year=2020/
sales-reports/americas/year=2019/
sales-reports/americas/year=2019/month=12/day=1/afile.parquet 
sales-reports/americas/year=2018/month=6/day=1/afile.parquet 
sales-reports/americas/year=2017/afile.parquet

Il carattere jolly "?" corrisponde a un singolo carattere. Ad esempio, per la policy:

S3 resource = "sales-reports/americas/year=201?/"

Questo corrisponde ai seguenti percorsi S3.

sales-reports/americas/year=2019/
sales-reports/americas/year=2018/
sales-reports/americas/year=2017/

Caratteri jolly negli utenti

Esistono due caratteri jolly incorporati quando si assegnano utenti per consentire l'accesso agli utenti. Il primo è il carattere jolly "{USER}" che fornisce l'accesso a tutti gli utenti. Il secondo carattere jolly è "{OWNER}" che fornisce l'accesso diretto o l'accesso al proprietario di un particolare oggetto. Tuttavia, il carattere jolly "{USER}" non è attualmente supportato.

Limitazioni

Di seguito sono riportate le attuali limitazioni per il plug-in EMRFS S3:

• Apache Ranger può avere al massimo tre policy.

• L'accesso a S3 deve essere realizzato tramite EMRFS e può essere utilizzato con le applicazioni correlate ad Hadoop. Il seguente elemento non è supportato:

  - Librerie Boto3

  - AWS SDK e AWK CLI

  - Connettore open source S3A

• Le policy di negazione di Apache Ranger non sono supportate.

• Le operazioni su S3 con chiavi con crittografia CSE-KMS non sono attualmente supportate.

• Il supporto tra Regioni non è supportato.

• La caratteristica Security Zone di Apache Ranger non è supportata. Le restrizioni per il controllo degli accessi definite utilizzando la funzione Security Zone non vengono applicate ai cluster Amazon EMR.

• L'utente Hadoop non genera alcun evento di controllo poiché Hadoop accede sempre al profilo dell'istanza. EC2

• Si consiglia di disabilitare la visualizzazione di coerenza Amazon EMR. S3 ha un'elevata coerenza, pertanto tale visualizzazione non è più necessaria. Per maggiori informazioni, consulta Forte coerenza di Amazon S3.

• Il plug-in EMRFS S3 effettua numerose chiamate STS. Si consiglia di eseguire test di carico su un account di sviluppo e monitorare il volume delle chiamate STS. Si consiglia inoltre di effettuare una richiesta STS per aumentare i limiti del servizio. AssumeRole

• Il server Ranger Admin non supporta il completamento automatico.