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 e scrittura 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: imposta le autorizzazioni a livello di Formation-based colonna, riga o cella di Lake 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 **LakeFormationAuthorizedCaller**sessione. 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 gli **ID dell'AWS account** in cui verrebbero eseguiti gli Spark Jobs e i valori dei **tag di sessione**. ![Impostazioni di integrazione delle applicazioni](https://docs.aws.amazon.com/it_it/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Nota che il tag di **LakeFormationAuthorizedCaller**sessione passato qui viene passato in un **SecurityConfiguration**secondo 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"] - apiGroups: ["kyverno.io"] resources: ["clusterpolicies"] verbs: ["create", "delete"] --- ``` ``` 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`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-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. Un Lake Formation-enabled Spark Job ha due componenti, utente e sistema. Il driver utente e gli executor vengono eseguiti nello spazio dei nomi utente e sono legati a JobExecutionRole ciò che viene passato nell'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 **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. Il ruolo IAM Permissions Policy of Query Engine è il seguente: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemDriver", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/{{JobExecutionRole}}" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "AssumeJobRoleWithSessionTagAccessForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*: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}} \ --namespace {{eks system namespace}} \ --role-name {{query_engine_iam_role_name}} ``` Per ulteriori informazioni, consulta [Aggiornamento](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html) 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 alle API e alle risorse Lake Formation and AWS Glue. 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 **JobExecution**ruolo dovrebbe avere le dichiarazioni politiche nella sua politica sulle autorizzazioni. ------ #### [ JSON ] **** ``` { "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** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "TrustQueryEngineRoleForSystemDriver", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{{123456789012}}:role/{{QueryEngineRole}}" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "TrustQueryEngineRoleForSystemExecutor", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{{123456789012}}: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}} \ --namespace {{eks User namespace}} \ --role-name {{job_execution_role_name}} ``` Per ulteriori informazioni, consulta [Aggiornare la politica di fiducia del ruolo di esecuzione del lavoro](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Fase 4: Configurazione della configurazione di sicurezza Per eseguire un Formation-enabled job Lake, è 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 Session Tag passato nel campo **autorizzato SessionTagValue possa autorizzare** Lake Formation. Imposta il valore su quello configurato in Lake Formation, in[Passaggio 1: imposta le autorizzazioni a livello di Formation-based colonna, riga o cella di Lake](#security_iam_fgac-lf-enable-permissions). ## 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-id {{SecurityConfigurationId}} ``` Assicurati che venga passato l'**SecurityConfiguration**ID 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](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-registration.html). ## Fase 6: Inviare un Job in FGAC Enabled VirtualCluster La procedura per l'invio dei lavori è la stessa sia per i lavori non Lake Formation che per quelli di Lake Formation. Per ulteriori informazioni, consulta [Inviare un lavoro eseguito con `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). 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](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html) log EKS.