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à.
Abilita Lake Formation con Amazon EMR su EKS
Con Amazon EMR versione 7.7 e successive, puoi sfruttare Lake AWS Formation per applicare controlli di accesso granulari alle tabelle di Data Catalog supportate da Amazon S3. Questa funzionalità consente di configurare i controlli di accesso a livello di tabella, riga, colonna e cella per le query di lettura all'interno di Amazon EMR su EKS Spark Jobs.
Questa sezione spiega come creare una configurazione di sicurezza e configurare Lake Formation per l'utilizzo con Amazon EMR. Descrive inoltre come creare un cluster virtuale con la configurazione di sicurezza creata per Lake Formation. Queste sezioni devono essere completate in sequenza.
Passaggio 1: configurare le autorizzazioni a livello di colonna, riga o cella basate su Lake Formation
Innanzitutto, per applicare le autorizzazioni a livello di riga e colonna con Lake Formation, l'amministratore del data lake per Lake Formation deve impostare il tag di LakeFormationAuthorizedCallersessione. Lake Formation utilizza questo tag di sessione per autorizzare i chiamanti e fornire l'accesso al data lake.
Vai alla console di AWS Lake Formation e seleziona l'opzione Impostazioni di integrazione delle applicazioni dalla sezione Amministrazione nella barra laterale. Quindi, seleziona la casella Consenti ai motori esterni di filtrare i dati nelle località Amazon S3 registrate con Lake Formation. Aggiungi l'AWS account IDs in cui verranno eseguiti gli Spark Jobs e i valori del tag di sessione.

Nota che il tag di LakeFormationAuthorizedCallersessione passato qui viene passato in un SecurityConfigurationsecondo momento quando configuri i ruoli IAM, nella sezione 3.
Fase 2: Configurazione delle autorizzazioni EKS RBAC
In secondo luogo, si impostano le autorizzazioni per il controllo degli accessi basato sui ruoli.
Fornisci le autorizzazioni del cluster EKS al servizio Amazon EMR su EKS
Il servizio Amazon EMR su EKS deve disporre delle autorizzazioni EKS Cluster Role in modo da poter creare autorizzazioni cross-namespace per consentire al driver di sistema di inserire gli esecutori utente nello spazio dei nomi utente.
Crea un ruolo del cluster
Questo esempio definisce le autorizzazioni per una raccolta di risorse.
vim emr-containers-cluster-role.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: emr-containers rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["get"] - apiGroups: [""] resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["secrets"] verbs: ["create", "patch", "delete", "watch"] - apiGroups: ["apps"] resources: ["statefulsets", "deployments"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["batch"] resources: ["jobs"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["extensions", "networking.k8s.io"] resources: ["ingresses"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles","clusterrolebindings","roles", "rolebindings"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] - apiGroups: [""] resources: ["persistentvolumeclaims"] verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"] ---
kubectl apply -f emr-containers-cluster-role.yaml
Crea associazioni di ruoli del cluster
vim emr-containers-cluster-role-binding.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: emr-containers subjects: - kind: User name: emr-containers apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: emr-containers apiGroup: rbac.authorization.k8s.io ---
kubectl apply -f emr-containers-cluster-role-binding.yaml
Fornisci l'accesso Namespace al servizio Amazon EMR on EKS
Crea due namespace Kubernetes, uno per driver utente ed esecutori e un altro per driver ed esecutori di sistema, e abilita l'accesso al servizio Amazon EMR su EKS per inviare lavori sia nei namespace utente che in quelli di sistema. Segui la guida esistente per fornire l'accesso a ogni spazio dei nomi, disponibile in Abilita l'accesso al cluster utilizzando. aws-auth
Fase 3: Configurazione dei ruoli IAM per i componenti del profilo utente e di sistema
In terzo luogo, si impostano i ruoli per componenti specifici. Uno Spark Job abilitato per Lake Formation ha due componenti, utente e sistema. Il driver User e gli executor vengono eseguiti nello spazio dei nomi utente e sono legati a ciò che viene passato nell' JobExecutionRole API. StartJobRun Il driver e gli executor di sistema vengono eseguiti nello spazio dei nomi System e sono legati al ruolo. QueryEngine
Configura il ruolo di Query Engine
Il QueryEngine ruolo è legato ai componenti dello spazio di sistema e avrebbe le autorizzazioni per assumere il tag JobExecutionRolewith LakeFormationAuthorizedCallerSession. Il ruolo IAM Permissions Policy of Query Engine è il seguente:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": "arn:aws:iam::
Account
:role/JobExecutionRole
", "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::Account
:role/JobExecutionRole
", }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": "emr-containers:CreateCertificate", "Resource": "*" } ] }
Configura la politica di attendibilità del ruolo Query Engine per considerare attendibile lo spazio dei nomi del sistema Kubernetes.
aws emr-containers update-role-trust-policy \ --cluster-name
eks cluster
\ --namespaceeks system namespace
\ --role-namequery_engine_iam_role_name
Per ulteriori informazioni, consulta Aggiornamento della policy di attendibilità dei ruoli.
Configurazione del ruolo Job Execution
Le autorizzazioni di Lake Formation controllano l'accesso alle risorse di AWS Glue Data Catalog, alle sedi Amazon S3 e ai dati sottostanti in tali sedi. Le autorizzazioni IAM controllano l'accesso a Lake Formation and AWS Glue APIs e alle risorse. Sebbene tu possa avere l'autorizzazione Lake Formation per accedere a una tabella nel Data Catalog (SELECT), l'operazione fallisce se non disponi dell'autorizzazione IAM sulle operazioni glue:Get*
API.
Politica sulle autorizzazioni IAM di JobExecutionRole: Il JobExecutionruolo dovrebbe avere le dichiarazioni politiche nella sua politica sulle autorizzazioni.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "GlueCatalogAccess", "Effect": "Allow", "Action": [ "glue:Get*", "glue:Create*", "glue:Update*" ], "Resource": ["*"] }, { "Sid": "LakeFormationAccess", "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": ["*"] }, { "Sid": "CreateCertificateAccessForTLS", "Effect": "Allow", "Action": "emr-containers:CreateCertificate", "Resource": "*" } ] }
IAM Trust Policy per: JobExecutionRole
{ "Version": "2012-10-17", "Statement": [ { "Sid": "TrustQueryEngineRoleForSystemDriver", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
your_account
:role/QueryExecutionRole
" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "TrustQueryEngineRoleForSystemExecutor", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::your_account
:role/QueryEngineRole
" }, "Action": "sts:AssumeRole" } ] }
Configura la Trust Policy of Job execution Role per considerare attendibile lo spazio dei nomi utente Kubernetes:
aws emr-containers update-role-trust-policy \ --cluster-name
eks cluster
\ --namespaceeks User namespace
\ --role-namejob_execution_role_name
Per ulteriori informazioni, consulta Aggiornare la politica di fiducia del ruolo di esecuzione del lavoro.
Fase 4: Configurazione della configurazione di sicurezza
Per eseguire un job abilitato per Lake Formation, è necessario creare una configurazione di sicurezza.
aws emr-containers create-security-configuration \ --name 'security-configuration-name' \ --security-configuration '{ "authorizationConfiguration": { "lakeFormationConfiguration": { "authorizedSessionTagValue": "
SessionTag configured in LakeFormation
", "secureNamespaceInfo": { "clusterId": "eks-cluster-name
", "namespace": "system-namespace-name
" }, "queryEngineRoleArn": "query-engine-IAM-role-ARN
" } } }'
Assicurati che il tag di sessione passato nel campo authorizedSessionTagValue possa autorizzare Lake Formation. Imposta il valore su quello configurato in Lake Formation, inPassaggio 1: configurare le autorizzazioni a livello di colonna, riga o cella basate su Lake Formation.
Fase 5: Creare un cluster virtuale
Crea un cluster virtuale Amazon EMR su EKS con una configurazione di sicurezza.
aws emr-containers create-virtual-cluster \ --name my-lf-enabled-vc \ --container-provider '{ "id": "
eks-cluster
", "type": "EKS", "info": { "eksInfo": { "namespace": "user-namespace
" } } }' \ --security-configuration-idSecurityConfiguraionId
Assicurati che venga passato l'SecurityConfigurationID del passaggio precedente, in modo che la configurazione di autorizzazione di Lake Formation venga applicata a tutti i lavori in esecuzione sul cluster virtuale. Per ulteriori informazioni, consulta Registrare il cluster Amazon EKS con Amazon EMR.
Fase 6: Inviare un Job in FGAC Enabled VirtualCluster
Il processo di invio dei lavori è lo stesso sia per i lavori non Lake Formation che per quelli di Lake Formation. Per ulteriori informazioni, consulta Inviare un lavoro eseguito con StartJobRun
.
Il driver Spark, l'Executor e i registri degli eventi del driver di sistema sono archiviati nel bucket S3 di AWS Service Account per il debug. Consigliamo di configurare una chiave KMS gestita dal cliente nel Job Run per crittografare tutti i log archiviati nel bucket di servizi. AWS Per ulteriori informazioni sull'attivazione della crittografia dei log, consulta Encrypting Amazon EMR sui log EKS.