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 em Trabalhos Spark do Amazon EMR no EKS. 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 permissões em nível de coluna, linha ou célula com base no Lake Formation 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 a **AWS conta em IDs ** que os Spark Jobs seriam executados e os **valores da tag Session**. ![\[Configurações de integração de aplicações\]](http://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 trabalho Spark habilitado para o Lake Formation 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 ao Lake Formation, ao AWS Glue APIs e aos recursos. 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", "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Resource": [ "arn:aws:iam::*:role/QueryExecutionRole" ], "Condition": { "StringLike": { "aws:RequestTag/LakeFormationAuthorizedCaller": "EMR on EKS Engine" } } }, { "Sid": "TrustQueryEngineRoleForSystemExecutor", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/QueryEngineRole" ] } ] } ``` ------ 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 um trabalho habilitado para o Lake Formation, 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 **authorizedSessionTagValue** possa autorizar o Lake Formation. Defina o valor como aquele configurado no Lake Formation, em [Etapa 1: Configurar permissões em nível de coluna, linha ou célula com base no Lake Formation](#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 SecurityConfiguraionId ``` 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](). ## Etapa 6: Enviar um Job no FGAC Enabled VirtualCluster O processo de envio de trabalhos é o mesmo para trabalhos pertencentes ou não ao 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).