As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Habilitar o Lake Formation com o Amazon EMR no EKS Com o Amazon EMR versão 7.7 e superior, você pode aproveitar o AWS Lake Formation para aplicar controles de acesso refinados nas tabelas do catálogo de dados que são apoiadas pelo Amazon S3. Esse recurso permite configurar controles de acesso em nível de tabela, linha, coluna e célula para consultas de leitura e gravação em seu Amazon EMR no EKS Spark Jobs. Esta seção aborda como criar uma configuração de segurança e configurar o Lake Formation para funcionar com o Amazon EMR. Ele também descreve como criar um cluster virtual com a configuração de segurança que você criou para o Lake Formation. Essas seções devem ser concluídas em sequência. ## Etapa 1: configurar as permissões em nível de Formation-based coluna, linha ou célula do Lake Primeiro, para aplicar permissões em nível de linha e coluna com o Lake Formation, o administrador do data lake do Lake Formation deve definir a tag de **LakeFormationAuthorizedCaller**sessão. O Lake Formation usa essa etiqueta de sessão para autorizar os chamadores e fornecer acesso ao data lake. Navegue até o console do AWS Lake Formation e selecione a opção **Configurações de integração de aplicativos** na seção **Administração** na barra lateral. Em seguida, marque a caixa **Permitir que mecanismos externos filtrem dados em locais do Amazon S3 registrados no Lake Formation**. Adicione os **IDs de contas da AWS ** em que os trabalhos Spark seriam executados e os **valores de etiquetas de sessão**. ![Configurações de integração de aplicações](https://docs.aws.amazon.com/pt_br/emr/latest/EMR-on-EKS-DevelopmentGuide/images/application_integration_settings_fgac.png) Observe que a tag de **LakeFormationAuthorizedCaller**sessão passada aqui é passada **SecurityConfiguration**posteriormente quando você configura as funções do IAM, na seção 3. ## Etapa 2: Configurar permissões de RBAC do EKS Em segundo lugar, você configura permissões para controle de acesso baseado em perfil. ### Fornecer permissões do cluster do EKS ao serviço Amazon EMR no EKS O serviço Amazon EMR no EKS deve ter permissões de perfil de cluster do EKS para que possa criar permissões entre namespaces para que o driver do sistema execute executores de usuário no namespace do usuário. **Criar perfil de cluster** Este exemplo define permissões para um conjunto de recursos. ``` 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 ``` **Criar vinculações de perfis de 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 ``` ### Fornecer acesso ao namespace ao serviço Amazon EMR no EKS Crie dois namespaces do Kubernetes, um para o driver e executores do usuário e outro para o driver e executores do sistema, e habilite o acesso ao serviço Amazon EMR no EKS para enviar trabalhos nos namespaces do usuário e do sistema. Siga o guia existente para fornecer acesso a cada namespace, disponível em [Habilitar acesso ao cluster usando `aws-auth`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-aws-auth). ## Etapa 3: Configurar perfis do IAM para componentes de perfil de usuário e sistema Em terceiro lugar, você define perfis para componentes específicos. Um Lake Formation-enabled Spark Job tem dois componentes, Usuário e Sistema. O driver e os executores do usuário são executados no namespace do usuário e estão vinculados ao JobExecutionRole que é passado na API. StartJobRun O driver e os executores do sistema são executados no namespace System e estão vinculados à função. **QueryEngine** ### Configurar o perfil do mecanismo de consulta A QueryEngine função está vinculada aos componentes do System Space e teria permissões para assumir a tag **JobExecutionRole**with **LakeFormationAuthorizedCaller**Session. A Política de permissões do IAM do perfil do Mecanismo de consulta é a seguinte: ------ #### [ 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": [ "*" ] } ] } ``` ------ Configure a política de confiança do perfil do Mecanismo de consulta para confiar no namespace do sistema Kubernetes. ``` aws emr-containers update-role-trust-policy \ --cluster-name {{eks cluster}} \ --namespace {{eks system namespace}} \ --role-name {{query_engine_iam_role_name}} ``` Para obter mais informações, consulte [Atualizar a política de confiança de perfis](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ### Configurar o perfil de execução do trabalho As permissões do Lake Formation controlam o acesso aos recursos do AWS Glue Data Catalog, aos locais do Amazon S3 e aos dados subjacentes nesses locais. As permissões do IAM controlam o acesso às APIs e recursos do Lake Formation e do AWS Glue. Embora você possa ter a permissão do Lake Formation para acessar uma tabela no Catálogo de dados (SELECT), a operação falhará se você não tiver a permissão do IAM em operações de API `glue:Get*`. Política de permissões do IAM de **JobExecutionRole**: A **JobExecution**função deve ter as declarações de política em sua política de permissões. ------ #### [ 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": [ "*" ] } ] } ``` ------ Política de confiança do IAM para **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" } ] } ``` ------ Configure a política de confiança do Perfil de execução de trabalho para confiar no namespace de usuário do Kubernetes: ``` aws emr-containers update-role-trust-policy \ --cluster-name {{eks cluster}} \ --namespace {{eks User namespace}} \ --role-name {{job_execution_role_name}} ``` Para obter mais informações, consulte [Atualizar a política de confiança do perfil de execução do trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html). ## Etapa 4: Definir a configuração de segurança Para executar uma Formation-enabled tarefa do Lake, você deve criar uma configuração de segurança. ``` 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}}" } } }' ``` Certifique-se de que a etiqueta de sessão passada no campo **autorizado SessionTagValue possa autorizar** o Lake Formation. Defina o valor como aquele configurado no Lake Formation, em [Etapa 1: configurar as permissões em nível de Formation-based coluna, linha ou célula do Lake](#security_iam_fgac-lf-enable-permissions). ## Etapa 5: Criar um cluster virtual Crie um cluster virtual do Amazon EMR no EKS com uma configuração de segurança. ``` 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}} ``` Certifique-se de que o **SecurityConfiguration**ID da etapa anterior seja passado, para que a configuração de autorização do Lake Formation seja aplicada a todos os trabalhos em execução no cluster virtual. Para obter mais informações, consulte [Registrar o cluster do Amazon EKS no Amazon EMR](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-registration.html). ## Etapa 6: Enviar um Job no FGAC Enabled VirtualCluster O processo de envio de vagas é o mesmo para trabalhos que não sejam da Lake Formation e da Lake Formation. Para obter mais informações, consulte [Enviar uma execução de trabalho com o `StartJobRun`](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-submit.html). O driver Spark, o executor e os registros de eventos do driver do sistema são armazenados no bucket S3 da conta de AWS serviço para depuração. Recomendamos configurar uma chave KMS gerenciada pelo cliente no Job Run para criptografar todos os registros armazenados no service bucket. AWS Para obter mais informações sobre como habilitar a criptografia de logs, consulte [Criptografar logs do Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/security_iam_fgac-logging-kms.html).