Habilitar o Lake Formation com o Amazon EMR no EKS - Amazon EMR

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 às tabelas do Catálogo de dados que são suportadas 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 para o Lake Formation deve definir a etiqueta de sessão LakeFormationAuthorizedCaller. 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 aplicações 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

Observe que a etiqueta de sessão LakeFormationAuthorizedCaller passado aqui é passado no SecurityConfiguration mais tarde quando você configura perfis 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.

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 do usuário e os executores são executados no namespace do usuário e estão vinculados ao JobExecutionRole que é passado na API StartJobRun. O driver do sistema e os executores são executados no namespace do sistema e estão vinculados ao perfil QueryEngine.

Configurar o perfil do mecanismo de consulta

O perfil QueryEngine está vinculado aos componentes do espaço do sistema e teria permissões para assumir o perfil JobExecutionRole com a etiqueta de sessão LakeFormationAuthorizedCaller. 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.

Configurar o perfil de execução do trabalho

As permissões do Lake Formation controlam o acesso aos recursos do Catálogo de Dados do AWS Glue, aos locais do Amazon S3 e aos dados subjacentes nesses locais. As permissões do IAM controlam o acesso às APIs e aos 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: o perfil de execução de trabalho 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.

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.

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 Id de SecurityConfiguration 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 trabalho no cluster virtual habilitado para FGAC

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.

O driver Spark, o executor e os logs de eventos do driver do sistema são armazenados no bucket do S3 da conta de serviço da AWS para depuração. Recomendamos configurar uma chave do KMS gerenciada pelo cliente na execução do trabalho para criptografar todos os log armazenados no bucket de serviço da AWS. Para obter mais informações sobre como habilitar a criptografia de logs, consulte Criptografar logs do Amazon EMR no EKS.