```
Além disso, você deve escapar os argumentos do comando Bash ao executar comandos com o executador de scripts. Veja a seguir um exemplo que mostra a configuração das propriedades do Spark, com caracteres de escape incluídos:
```
"\"--conf spark.sql.autoBroadcastJoinThreshold=-1\n--conf spark.cradle.RSv2Mode.enabled=true\""
```
+ Os perfis de runtime não oferecem suporte para controlar o acesso a recursos no cluster, como HDFS e HMS.
+ Perfis de runtime não oferecem suporte para docker/contêineres.
# Configurar funções de serviço do IAM para permissões do Amazon EMR para AWS serviços e recursos
O Amazon EMR e aplicações como o Hadoop e o Spark precisam de permissões para acessar outros recursos da AWS e realizar ações quando são executados. Cada cluster no Amazon EMR deve ter um *perfil de serviço* e um perfil para o *perfil de instância* do Amazon EC2. Para obter mais informações, consulte [Perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) e [Usar perfis de instância](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) no *Guia do usuário do IAM*. As políticas do IAM anexadas a esses perfis fornecem permissões para o cluster interoperar com outros serviços da AWS em nome de um usuário.
Um perfil adicional, o perfil do Auto Scaling, será necessário se o cluster usar a ajuste de escala automático no Amazon EMR. A função AWS de serviço para Notebooks EMR é necessária se você usa Notebooks EMR.
O Amazon EMR fornece perfis padrão e políticas gerenciadas padrão para determinar permissões para cada perfil. As políticas gerenciadas são criadas e mantidas por AWS, portanto, são atualizadas automaticamente se os requisitos de serviço mudarem. Consulte [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies.html) no *Guia do usuário do IAM*.
Se você estiver criando um cluster ou um caderno pela primeira vez em uma conta, os perfis do Amazon EMR ainda não existirão. Depois de criá-las, você pode visualizar as funções, as políticas associadas a elas e as permissões permitidas ou negadas pelas políticas no console do IAM ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)). Você pode especificar perfis padrão para o Amazon EMR criar e usar, pode criar seus próprios perfis e especificá-los individualmente ao criar um cluster para personalizar as permissões e pode, ainda, especificar perfis padrão a serem usados ao criar um cluster usando a AWS CLI. Para obter mais informações, consulte [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md).
## Modificar políticas baseadas em identidade para permissões a fim de transmitir perfis de serviço ao Amazon EMR
As políticas gerenciadas padrão de permissões completas do Amazon EMR incorporam configurações de segurança `iam:PassRole`, incluindo estas:
+ Permissões `iam:PassRole` somente para perfis padrão específicos do Amazon EMR.
+ `iam:PassedToService`condições que permitem que você use a política somente com AWS serviços específicos, como `elasticmapreduce.amazonaws.com` `ec2.amazonaws.com` e.
Você pode visualizar a versão JSON das políticas Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) no console do IAM. É recomendável criar novos clusters com políticas gerenciadas v2.
## Resumo do perfil de serviço
A tabela a seguir lista os perfis de serviço do IAM associadas ao Amazon EMR para referência rápida.
| Função | Perfil padrão | Description | Política gerenciada padrão |
| --- | --- | --- | --- |
| [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md) | `EMR_DefaultRole_V2` | Permite que o Amazon EMR chame outros AWS serviços em seu nome ao provisionar recursos e realizar ações em nível de serviço. Essa função é necessária para todos os clusters. | `AmazonEMRServicePolicy_v2` É necessário ter um perfil vinculado ao serviço para solicitar instâncias spot. Se esse perfil não existir, o perfil de serviço do Amazon EMR deve ter permissão para criá-lo ou ocorrerá um erro de permissão. Se você pretende solicitar instâncias spot, é necessário atualizar essa política para incluir uma instrução que permita a criação desse perfil vinculado ao serviço. Para obter mais informações, consulte [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md) e [Perfil vinculado ao serviço para solicitações de instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) no *Guia do usuário do Amazon EC2*. |
| [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md) | `EMR_EC2_DefaultRole` | Os processos de aplicativos executados no ecossistema do Hadoop em instâncias de cluster usam essa função quando chamam outros AWS serviços. Para acessar os dados no Amazon S3 usando o EMRFS, você pode especificar diferentes perfis a serem assumidos com base no local dos dados no Amazon S3. Por exemplo, múltiplas equipes podem acessar uma única “conta de armazenamento” de dados do Amazon S3. Para obter mais informações, consulte [Configurar perfis do IAM para solicitações do EMRFS para o Amazon S3](emr-emrfs-iam-roles.md). Essa função é necessária para todos os clusters. | `AmazonElasticMapReduceforEC2Role`. Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md). |
| [Perfil de serviço para ajuste de escala automático no Amazon EMR (perfil do Auto Scaling)](emr-iam-role-automatic-scaling.md) | `EMR_AutoScaling_DefaultRole` | Permite ações adicionais para ambientes de escalabilidade dinâmica. Necessária apenas para clusters que usam a ajuste de escala automático no Amazon EMR. Para obter mais informações, consulte [Uso do ajuste de escala automático com uma política personalizada para grupos de instâncias no Amazon EMR](emr-automatic-scaling.md). | `AmazonElasticMapReduceforAutoScalingRole`. Para obter mais informações, consulte [Perfil de serviço para ajuste de escala automático no Amazon EMR (perfil do Auto Scaling)](emr-iam-role-automatic-scaling.md). |
| [Perfil de serviço para Cadernos do EMR](emr-managed-notebooks-service-role.md) | `EMR_Notebooks_DefaultRole` | Fornece as permissões que um notebook EMR precisa para acessar outros AWS recursos e realizar ações. Necessário somente se forem usados cadernos EMR. | `AmazonElasticMapReduceEditorsRole`. Para obter mais informações, consulte [Perfil de serviço para Cadernos do EMR](emr-managed-notebooks-service-role.md). `S3FullAccessPolicy` também é anexado por padrão. Veja a seguir o conteúdo da política. JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
``` |
| [Função vinculada ao serviço](using-service-linked-roles.md) | `AWSServiceRoleForEMRCleanup` | O Amazon EMR cria automaticamente um perfil vinculado ao serviço. Se o serviço do Amazon EMR tiver perdido a capacidade de apagar os recursos do Amazon EC2, o Amazon EMR poderá usar esse perfil para fazer isso. Se um cluster usar instâncias spot, a política de permissões anexada ao [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md) deverá permitir a criação de uma função vinculada ao serviço. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon EMR](using-service-linked-roles.md). | `AmazonEMRCleanupPolicy` |
**Topics**
+ [Modificar políticas baseadas em identidade para permissões a fim de transmitir perfis de serviço ao Amazon EMR](#emr-iam-roles-passrole)
+ [Resumo do perfil de serviço](#emr-iam-roles-summary)
+ [Perfis de serviço do IAM usados pelo Amazon EMR](emr-iam-service-roles.md)
+ [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md)
+ [Configurar perfis do IAM para solicitações do EMRFS para o Amazon S3](emr-emrfs-iam-roles.md)
+ [Use políticas baseadas em recursos para o acesso do Amazon EMR ao Glue Data Catalog AWS](emr-iam-roles-glue.md)
+ [Use funções do IAM com aplicativos que chamam AWS serviços diretamente](emr-iam-roles-calling.md)
+ [Permitir que usuários e grupos criem e modifiquem perfis](emr-iam-roles-create-permissions.md)
# Perfis de serviço do IAM usados pelo Amazon EMR
O Amazon EMR usa perfis de serviço do IAM para executar ações em seu nome ao provisionar recursos do cluster, executar aplicações, escalar recursos de forma dinâmica e criar e executar Cadernos do EMR. O Amazon EMR usa os seguintes perfis ao interagir com outros serviços da AWS . Cada perfil tem um papel exclusivo no Amazon EMR. Os tópicos desta seção descrevem o papel da função e fornecem as funções padrão e a política de permissões de cada função.
Se você tiver um código de aplicativo em seu cluster que chame AWS serviços diretamente, talvez seja necessário usar o SDK para especificar funções. Para obter mais informações, consulte [Use funções do IAM com aplicativos que chamam AWS serviços diretamente](emr-iam-roles-calling.md).
**Topics**
+ [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md)
+ [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md)
+ [Perfil de serviço para ajuste de escala automático no Amazon EMR (perfil do Auto Scaling)](emr-iam-role-automatic-scaling.md)
+ [Perfil de serviço para Cadernos do EMR](emr-managed-notebooks-service-role.md)
+ [Uso de perfis vinculados ao serviço para o Amazon EMR](using-service-linked-roles.md)
# Perfil de serviço para Amazon EMR (perfil do EMR)
O perfil do Amazon EMR define as ações permitidas para o Amazon EMR durante o provisionamento de recursos e a execução de tarefas no nível de serviço que não são executadas no contexto de uma instância do Amazon EC2 em execução em um cluster. Por exemplo, a função de serviço é usada para provisionar instâncias do EC2 quando um cluster é executado.
+ O nome de perfil padrão é `EMR_DefaultRole_V2`.
+ A política gerenciada com escopo do Amazon EMR padrão anexada a `EMR_DefaultRole_V2` é `AmazonEMRServicePolicy_v2`. Essa política v2 substitui a política gerenciada padrão defasada, `AmazonElasticMapReduceRole`.
`AmazonEMRServicePolicy_v2` depende do acesso de escopo limitado aos recursos que o Amazon EMR provisiona ou usa. Ao usar essa política, é necessário passar a etiqueta de usuário `for-use-with-amazon-emr-managed-policies = true` ao provisionar o cluster. O Amazon EMR propagará essas etiquetas automaticamente. Além disso, talvez seja necessário adicionar manualmente uma etiqueta de usuário a tipos específicos de recursos, como grupos de segurança do EC2 que não foram criados pelo Amazon EMR. Consulte [Etiquetar recursos para usar políticas gerenciadas](emr-managed-iam-policies.md#manually-tagged-resources).
**Importante**
O Amazon EMR usa esse perfil de serviço do Amazon EMR e o perfil `AWSServiceRoleForEMRCleanup` para limpar recursos de cluster em sua conta que você não usa mais, como instâncias do Amazon EC2. Você deve incluir ações nas políticas de perfil para excluir ou encerrar os recursos. Caso contrário, o Amazon EMR não poderá realizar essas ações de limpeza e você poderá ter custos com recursos não utilizados que permanecem no cluster.
O exemplo a seguir mostra o conteúdo de uma política `AmazonEMRServicePolicy_v2` atual. Você também pode ver o conteúdo atual da política gerenciada [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) no console do IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateInTaggedNetwork",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateWithEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedLaunchTemplate",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplate"
],
"Resource": [
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRTaggedInstancesAndVolumes",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ResourcesToLaunchEC2",
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:CreateFleet",
"ec2:CreateLaunchTemplate",
"ec2:CreateLaunchTemplateVersion"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:capacity-reservation/*",
"arn:aws:ec2:*:*:placement-group/pg-*",
"arn:aws:ec2:*:*:fleet/*",
"arn:aws:ec2:*:*:dedicated-host/*",
"arn:aws:resource-groups:*:*:group/*"
]
},
{
"Sid": "ManageEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateLaunchTemplateVersion",
"ec2:DeleteLaunchTemplate",
"ec2:DeleteNetworkInterface",
"ec2:ModifyInstanceAttribute",
"ec2:TerminateInstances"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ManageTagsOnEMRTaggedResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateNetworkInterfaceNeededForPrivateSubnet",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateTaggedEMRResources",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:launch-template/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": [
"RunInstances",
"CreateFleet",
"CreateLaunchTemplate",
"CreateNetworkInterface"
]
}
}
},
{
"Sid": "TagPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "ListActionsForEC2Resources",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeCapacityReservations",
"ec2:DescribeDhcpOptions",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeLaunchTemplates",
"ec2:DescribeNetworkAcls",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribePlacementGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVolumes",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVpcAttribute",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs"
],
"Resource": [
"*"
]
},
{
"Sid": "CreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateDefaultSecurityGroupInVPCWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateSecurityGroup"
],
"Resource": [
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "TagOnCreateDefaultSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"ec2:CreateAction": "CreateSecurityGroup"
}
}
},
{
"Sid": "ManageSecurityGroups",
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEMRPlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:CreatePlacementGroup"
],
"Resource": [
"arn:aws:ec2:*:*:placement-group/pg-*"
]
},
{
"Sid": "DeletePlacementGroups",
"Effect": "Allow",
"Action": [
"ec2:DeletePlacementGroup"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScaling",
"Effect": "Allow",
"Action": [
"application-autoscaling:DeleteScalingPolicy",
"application-autoscaling:DeregisterScalableTarget",
"application-autoscaling:DescribeScalableTargets",
"application-autoscaling:DescribeScalingPolicies",
"application-autoscaling:PutScalingPolicy",
"application-autoscaling:RegisterScalableTarget"
],
"Resource": [
"*"
]
},
{
"Sid": "ResourceGroupsForCapacityReservations",
"Effect": "Allow",
"Action": [
"resource-groups:ListGroupResources"
],
"Resource": [
"*"
]
},
{
"Sid": "AutoScalingCloudWatch",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricAlarm",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:*:*:alarm:*_EMR_Auto_Scaling"
]
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "CreateAndModifyEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:ModifyVpcEndpoint",
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:vpc/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "CreateEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
},
{
"Sid": "TagEmrServiceVPCEndpoint",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint",
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true",
"aws:RequestTag/Name": "emr-service-vpce"
}
}
}
]
}
```
------
Seu perfil de serviço deve usar a seguinte política de confiança.
**Importante**
A política de confiança a seguir inclui as chaves de condição globais [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), que limitam as permissões que você concede ao Amazon EMR para recursos específicos em sua conta. O uso delas pode proteger você contra [o problema de “confused deputy”](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
}
}
]
}
```
------
# Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)
O perfil de serviço para instâncias do EC2 do cluster (também chamada de perfil de instância do EC2 para Amazon EMR) é um tipo especial de perfil de serviço atribuído a cada instância do EC2 no cluster do Amazon EMR quando a instância é iniciada. Os processos de aplicação que são executados no ecossistema do Hadoop assumem esse perfil para que as permissões interajam com outros serviços da AWS .
Para obter mais informações sobre perfis de serviço para instâncias do EC2, consulte [Uso de um perfil do IAM para conceder permissões a aplicações em execução em instâncias do Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) no *Guia do usuário do IAM*.
**Importante**
A função de serviço padrão para instâncias EC2 de cluster e sua política gerenciada AWS padrão associada `AmazonElasticMapReduceforEC2Role` estão em vias de descontinuação, sem nenhuma política gerenciada AWS substituta fornecida. Será necessário criar e especificar um perfil de instância para substituir o perfil e a política padrão defasados.
## Perfil padrão e política gerenciada
+ O nome de perfil padrão é `EMR_EC2_DefaultRole`.
+ A política gerenciada `EMR_EC2_DefaultRole` padrão, `AmazonElasticMapReduceforEC2Role`, está chegando ao fim do suporte. Em vez de usar uma política gerenciada padrão para o perfil de instância do EC2, aplique políticas baseadas em recursos aos buckets do S3 e outros recursos que o Amazon EMR precisa, ou use sua própria política gerenciada pelo cliente com um perfil do IAM como perfil de instância. Para obter mais informações, consulte [Criar um perfil de serviço para instâncias do EC2 do cluster com permissões de privilégio mínimo](#emr-ec2-role-least-privilege).
Veja a seguir o conteúdo da versão 3 de `AmazonElasticMapReduceforEC2Role`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"cloudwatch:*",
"dynamodb:*",
"ec2:Describe*",
"elasticmapreduce:Describe*",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSteps",
"kinesis:CreateStream",
"kinesis:DeleteStream",
"kinesis:DescribeStream",
"kinesis:GetRecords",
"kinesis:GetShardIterator",
"kinesis:MergeShards",
"kinesis:PutRecord",
"kinesis:SplitShard",
"rds:Describe*",
"s3:*",
"sdb:*",
"sns:*",
"sqs:*",
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Sid": "AllowCLOUDWATCH"
}
]
}
```
------
Seu perfil de serviço deve usar a seguinte política de confiança.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
}
]
}
```
------
## Criar um perfil de serviço para instâncias do EC2 do cluster com permissões de privilégio mínimo
Como prática recomendada, é altamente recomendável que você crie uma função de serviço para instâncias do EC2 de cluster e uma política de permissões que tenha as permissões mínimas para outros AWS serviços exigidos pelo seu aplicativo.
A política gerenciada padrão, `AmazonElasticMapReduceforEC2Role`, fornece permissões que facilitam a execução de um cluster inicial. No entanto, `AmazonElasticMapReduceforEC2Role` está em vias de descontinuação e o Amazon EMR não fornecerá uma política padrão AWS gerenciada substituta para a função obsoleta. Para iniciar um cluster inicial, é necessário fornecer uma política gerenciada pelo cliente baseada em recursos ou baseada em ID.
As instruções de política a seguir fornecem exemplos das permissões necessárias para diferentes atributos do Amazon EMR. Recomendamos que você use essas permissões para criar uma política de permissões que restrinja o acesso somente a esses recursos e aos recursos que o cluster exige. Todos os exemplos de declarações de política usam a *us-west-2* Região e o ID *123456789012* fictício AWS da conta. Faça as substituições apropriadas para o seu cluster.
Para obter mais informações sobre como criar e especificar funções personalizadas, consulte [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md).
**nota**
Se você criar um perfil personalizado do EMR para o EC2, siga o fluxo de trabalho básico, que criará automaticamente um perfil de instância com o mesmo nome. O Amazon EC2 permite criar perfis e perfis de instância com nomes diferentes, mas o Amazon EMR não oferece suporte a essa configuração, o que resulta em um erro de “perfil de instância inválido” quando você cria o cluster.
### Ler e gravar dados no Amazon S3 usando o EMRFS
Quando uma aplicação em execução em um cluster do Amazon EMR faz referência a dados usando o formato `s3://mydata`, o Amazon EMR usa o perfil de instância do EC2 para fazer a solicitação. Normalmente, os clusters leem e gravam dados no Amazon S3 dessa maneira, e o Amazon EMR usa as permissões anexadas ao perfil de serviço para instâncias do cluster do EC2 por padrão. Para obter mais informações, consulte [Configurar perfis do IAM para solicitações do EMRFS para o Amazon S3](emr-emrfs-iam-roles.md).
Já que os perfis do IAM para o EMRFS se enquadrarão às permissões anexadas ao perfil de serviço para instâncias de cluster do EC2, como prática recomendada, é aconselhável usar perfis do IAM para o EMRFS e limitar as permissões do EMRFS e do Amazon S3 anexadas ao perfil de serviço para instâncias de cluster do EC2.
O exemplo de instrução a seguir demonstra as permissões que o EMRFS exige para fazer solicitações ao Amazon S3.
+ *my-data-bucket-in-s3-for-emrfs-reads-and-writes* especifica o bucket no Amazon S3 em que o cluster lê e grava dados e todas as subpastas usando */\$1*. Adicione somente os buckets e as pastas que o aplicativo exige.
+ A instrução de política que permite ações `dynamodb` será necessária somente se a visualização consistente do EMRFS estiver habilitada. *EmrFSMetadata* especifica a pasta padrão para a visualização consistente do EMRFS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:CreateBucket",
"s3:DeleteObject",
"s3:GetBucketVersioning",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:ListBucketVersions",
"s3:ListMultipartUploadParts",
"s3:PutBucketVersioning",
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": [
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes",
"arn:aws:s3:::my-data-bucket-in-s3-for-emrfs-reads-and-writes/*"
],
"Sid": "AllowS3Abortmultipartupload"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:CreateTable",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:PutItem",
"dynamodb:DescribeTable",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem",
"dynamodb:DeleteTable",
"dynamodb:UpdateTable"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/EmrFSMetadata"
],
"Sid": "AllowDYNAMODBCreatetable"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"dynamodb:ListTables",
"s3:ListBucket"
],
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHPutmetricdata"
},
{
"Effect": "Allow",
"Action": [
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:DeleteQueue",
"sqs:SendMessage",
"sqs:CreateQueue"
],
"Resource": [
"arn:aws:sqs:*:123456789012:EMRFS-Inconsistency-*"
],
"Sid": "AllowSQSGetqueueurl"
}
]
}
```
------
### Arquivar arquivos de log no Amazon S3
A instrução de política a seguir permite que o cluster do Amazon EMR arquive os arquivos de log no local especificada do Amazon S3. No exemplo abaixo, quando o cluster foi criado, *s3://MyLoggingBucket/MyEMRClusterLogs* foi especificado usando a **localização da pasta Log S3** no console, usando a `--log-uri` opção do AWS CLI, ou usando o `LogUri` parâmetro no `RunJobFlow` comando. Para obter mais informações, consulte [Arquivamento dos arquivos de log no Amazon S3](emr-plan-debugging.md#emr-plan-debugging-logs-archive).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::MyLoggingBucket/MyEMRClusterLogs/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
### Usando o AWS Glue Data Catalog
A declaração de política a seguir permite ações que são necessárias se você usar o AWS Glue Data Catalog como metastore para aplicativos. *Para obter mais informações, consulte [Usando o AWS Glue Data Catalog como metastore para o Spark SQL](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-glue.html), Usando [o AWS Glue Data Catalog como metastore para o Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) e Usando o [Presto com o Glue Data AWS Catalog no Guia de lançamento do](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) Amazon EMR.*
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateDatabase",
"glue:UpdateDatabase",
"glue:DeleteDatabase",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:CreateTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTable",
"glue:GetTables",
"glue:GetTableVersions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:CreateUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:DeleteUserDefinedFunction",
"glue:GetUserDefinedFunction",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"*"
],
"Sid": "AllowGLUECreatedatabase"
}
]
}
```
------
# Perfil de serviço para ajuste de escala automático no Amazon EMR (perfil do Auto Scaling)
O perfil do Auto Scaling para o Amazon EMR executa uma função semelhante ao perfil de serviço, mas permite outras ações para ambientes de ajusta de escala dinâmico.
+ O nome de perfil padrão é `EMR_AutoScaling_DefaultRole`.
+ A política gerenciada padrão anexada a `EMR_AutoScaling_DefaultRole` é `AmazonElasticMapReduceforAutoScalingRole`.
O conteúdo da versão 1 da `AmazonElasticMapReduceforAutoScalingRole` é mostrado a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:DescribeAlarms",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHDescribealarms"
}
]
}
```
------
Seu perfil de serviço deve usar a seguinte política de confiança.
**Importante**
A política de confiança a seguir inclui as chaves de condição globais [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), que limitam as permissões que você concede ao Amazon EMR para recursos específicos em sua conta. O uso delas pode proteger você contra [o problema de “confused deputy”](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/ApplicationAutoScalingEMRRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:application-autoscaling:*:123456789012:scalable-target/*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
# Perfil de serviço para Cadernos do EMR
Cada notebook do EMR precisa de permissões para acessar outros AWS recursos e realizar ações. As políticas do IAM anexadas a essa função de serviço fornecem permissões para que o notebook interopere com outros AWS serviços. Ao criar um notebook usando o Console de gerenciamento da AWS, você especifica uma *função AWS de serviço*. É possível usar a função padrão, `EMR_Notebooks_DefaultRole`, ou especificar uma função criada por você. Se um bloco de anotações não foi criado anteriormente, é possível optar por criar a função padrão.
+ O nome de perfil padrão é `EMR_Notebooks_DefaultRole`.
+ As políticas gerenciadas listadas anexadas a `EMR_Notebooks_DefaultRole` são `AmazonElasticMapReduceEditorsRole` e `S3FullAccessPolicy`.
Seu perfil de serviço deve usar a seguinte política de confiança.
**Importante**
A política de confiança a seguir inclui as chaves de condição globais [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) e [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), que limitam as permissões que você concede ao Amazon EMR para recursos específicos em sua conta. O uso delas pode proteger você contra [o problema de “confused deputy”](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMRServiceRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:elasticmapreduce:*:123456789012:*"
}
},
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
O conteúdo da versão 1 de `AmazonElasticMapReduceEditorsRole` é o seguinte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Authorizesecuritygroupegress"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"aws:elasticmapreduce:editor-id",
"aws:elasticmapreduce:job-flow-id"
]
}
},
"Sid": "AllowEC2Createtags"
}
]
}
```
------
Veja a seguir o conteúdo de `S3FullAccessPolicy`. `S3FullAccessPolicy` permite que seu perfil de serviço para cadernos EMR executem todas as ações do Amazon S3 em objetos em sua Conta da AWS. Ao criar um perfil de serviço personalizado para Cadernos do EMR, você deve conceder permissões do Amazon S3 ao perfil de serviço.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
```
------
Você pode restringir o acesso de leitura e gravação do perfil de serviço ao local do Amazon S3 em que deseja salvar os arquivos do caderno. Use o conjunto mínimo de permissões do Amazon S3 apresentado a seguir.
```
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
```
Se o seu bucket do Amazon S3 estiver criptografado, você deverá incluir as seguintes permissões para o AWS Key Management Service.
```
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
```
Quando você vincula repositórios do Git ao caderno e precisa criar um segredo para o repositório, é necessário adicionar a permissão `secretsmanager:GetSecretValue` à política do IAM anexada ao perfil de serviço dos Cadernos do Amazon EMR. Um exemplo de política é demonstrado a seguir:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"*"
]
}
]
}
```
------
## Permissões de perfil de serviço de Cadernos do EMR
Esta tabela lista as ações que os Cadernos do EMR executam usando o perfil de serviço, junto com as permissões necessárias para cada ação.
****
| Ação | Permissões |
| --- | --- |
| Estabelecimento de um canal de rede seguro entre um caderno e um cluster do Amazon EMR e execução das ações de limpeza necessárias. | "ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:DescribeSecurityGroups",
"ec2:RevokeSecurityGroupEgress",
"ec2:DescribeTags",
"ec2:DescribeInstances",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"elasticmapreduce:ListInstances",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps"
|
| Uso das credenciais do Git armazenadas no AWS Secrets Manager para vincular repositórios Git a um caderno. | "secretsmanager:GetSecretValue"
|
| Aplique AWS tags à interface de rede e aos grupos de segurança padrão que o EMR Notebooks cria ao configurar o canal de rede seguro. Para obter mais informações, consulte [Etiquetar recursos da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html). | "ec2:CreateTags"
|
| Acesso ou upload de arquivos e metadados de cadernos para o Amazon S3. | "s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
As permissões a seguir serão necessárias somente se você usar um bucket criptografado do Amazon S3. "kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
|
## Notebooks EMR: atualizações para políticas gerenciadas AWS
Veja detalhes sobre as atualizações das políticas AWS gerenciadas para Notebooks EMR desde 1º de março de 2021.
| Alteração | Descrição | Data |
| --- | --- | --- |
| AmazonElasticMapReduceEditorsRole - Added permissions | Cadernos do EMR foram adicionadas as permissões `ec2:describeVPCs` e `elastmicmapreduce:ListSteps` para `AmazonElasticMapReduceEditorsRole`. | 8 de fevereiro de 2023 |
| Os Cadernos do EMR começaram a monitorar alterações | O EMR Notebooks começou a monitorar as mudanças em suas políticas gerenciadas AWS . | 8 de fevereiro de 2023 |
# Uso de perfis vinculados ao serviço para o Amazon EMR
O Amazon EMR usa funções vinculadas a [serviços AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Um perfil vinculado ao serviço é um tipo especial de perfil do IAM vinculado diretamente ao Amazon EMR. As funções vinculadas ao serviço são predefinidas pelo Amazon EMR e incluem todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
**Topics**
+ [Uso de perfis vinculados ao serviço para limpeza do Amazon EMR](using-service-linked-roles-cleanup.md)
+ [Uso de perfis vinculados ao serviço com o Amazon EMR para registro em log com gravação antecipada](using-service-linked-roles-wal.md)
Para obter informações sobre outros serviços que oferecem suporte a funções vinculadas a serviços, consulte [AWS Serviços que funcionam com IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que têm **Sim** na coluna Funções **vinculadas ao serviço**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado a esse serviço.
# Uso de perfis vinculados ao serviço para limpeza do Amazon EMR
O Amazon EMR usa funções vinculadas a [serviços AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Um perfil vinculado ao serviço é um tipo especial de perfil do IAM vinculado diretamente ao Amazon EMR. As funções vinculadas ao serviço são predefinidas pelo Amazon EMR e incluem todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
Os perfis vinculados ao serviço funcionam com o perfil de serviço do Amazon EMR e o perfil de instância do Amazon EC2 para o Amazon EMR. Para obter mais informações sobre a função de serviço e o perfil da instância, consulte [Configurar funções de serviço do IAM para permissões do Amazon EMR para AWS serviços e recursos](emr-iam-roles.md).
Um perfil vinculado ao serviço facilita a configuração do Amazon EMR porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EMR define as permissões dos perfis vinculados ao serviço e, a não ser que esteja definido de outra forma, somente o Amazon EMR poderá assumir os perfis. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM.
É possível excluir esse perfil vinculado ao serviço no Amazon EMR somente depois de excluir quaisquer recursos relacionados e encerrar todos os clusters do EMR na conta. Isso protege os recursos do Amazon EMR, para que você não possa remover inadvertidamente a permissão de acesso aos recursos.
## Uso de perfis vinculados ao serviço para limpeza
O Amazon EMR usa a função baseada em serviços para conceder permissão **AWSServiceRoleForEMRCleanup**ao Amazon EMR para encerrar e excluir recursos do Amazon EC2 em seu nome se a função vinculada ao serviço do Amazon EMR perder essa capacidade. O Amazon EMR cria o perfil vinculado ao serviço automaticamente durante a criação do cluster, caso ele ainda não exista.
A função AWSService RoleFor EMRCleanup vinculada ao serviço confia nos seguintes serviços para assumir a função:
+ `elasticmapreduce.amazonaws.com`
A política de permissões AWSService RoleFor EMRCleanup de função vinculada ao serviço permite que o Amazon EMR conclua as seguintes ações nos recursos especificados:
+ Ação: `DescribeInstances` em `ec2`
+ Ação: `DescribeLaunchTemplates` em `ec2`
+ Ação: `DeleteLaunchTemplate` em `ec2`
+ Ação: `DescribeSpotInstanceRequests` em `ec2`
+ Ação: `ModifyInstanceAttribute` em `ec2`
+ Ação: `TerminateInstances` em `ec2`
+ Ação: `CancelSpotInstanceRequests` em `ec2`
+ Ação: `DeleteNetworkInterface` em `ec2`
+ Ação: `DescribeInstanceAttribute` em `ec2`
+ Ação: `DescribeVolumeStatus` em `ec2`
+ Ação: `DescribeVolumes` em `ec2`
+ Ação: `DetachVolume` em `ec2`
+ Ação: `DeleteVolume` em `ec2`
+ Ação: `DescribePlacementGroups` em `ec2`
+ Ação: `DeletePlacementGroup` em `ec2`
É necessário configurar as permissões para permitir que uma entidade do IAM (como um usuário, grupo ou perfil) crie, edite ou exclua uma função vinculada ao serviço.
## Criar um perfil vinculado ao serviço para Amazon EMR
Você não precisa criar a AWSService RoleFor EMRCleanup função manualmente. Quando você inicia um cluster, seja pela primeira vez ou quando a função AWSService RoleFor EMRCleanup vinculada ao serviço não está presente, o Amazon EMR cria a função vinculada ao AWSService RoleFor EMRCleanup serviço para você. Você deve ter permissões para criar um perfil vinculado ao serviço. Para obter um exemplo de instrução que acrescenta essa possibilidade à política de permissões de uma entidade do IAM (por exemplo, um usuário, grupo ou perfil):
Adicione a instrução a seguir à política de permissões da entidade do IAM que precisa criar o perfil vinculado ao serviço.
```
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
**Importante**
Se você usou o Amazon EMR antes de 24 de outubro de 2017, quando as funções vinculadas ao serviço não eram suportadas, o Amazon EMR criou a função vinculada ao AWSService RoleFor EMRCleanup serviço em sua conta. Para obter mais informações, consulte [Uma nova função apareceu na minha conta do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
## Editar um perfil vinculado ao serviço do Amazon EMR
O Amazon EMR não permite que você edite a função vinculada ao AWSService RoleFor EMRCleanup serviço. Depois que você criar um perfil vinculado ao serviço, não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, você pode editar a descrição do perfil vinculado ao serviço usando o IAM.
### Editar a descrição de uma função vinculada ao serviço (console do IAM)
Você pode usar o console do IAM para editar a descrição de uma função vinculada ao serviço.
**Para editar a descrição de uma função vinculada ao serviço (console)**
1. No painel de navegação do console do IAM, escolha **Perfis**.
1. Escolha o nome da função a ser modificada.
1. À direita de **Descrição do perfil**, escolha **Editar**.
1. Insira uma nova descrição na caixa e escolha **Save changes** (Salvar alterações).
### Editar descrição de um perfil vinculado ao serviço (CLI do IAM)
Você pode usar os comandos do IAM do AWS Command Line Interface para editar a descrição de uma função vinculada ao serviço.
**Para alterar a descrição de uma função (CLI)**
1. (Opcional) Para visualizar a descrição atual de a uma função, use um dos comandos a seguir:
```
$ aws iam get-role --role-name role-name
```
Use o nome da função, não o nome de recurso da Amazon (ARN), para fazer referência às funções com os comandos da CLI. Por exemplo, se uma função tiver o seguinte nome de recurso da Amazon (ARN): `arn:aws:iam::123456789012:role/myrole`, você fará referência à função como **myrole**.
1. Para atualizar a descrição de uma função vinculada a serviço, use um dos comandos a seguir:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Editar a descrição de uma função vinculada ao serviço (API do IAM)
Você pode usar a API do IAM para editar a descrição de uma função vinculada ao serviço.
**Para alterar a descrição de uma função (API)**
1. (Opcional) Para visualizar a descrição atual de uma função, use o comando a seguir:
API do IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Para atualizar a descrição de uma função, use o comando a seguir:
API do IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Excluir um perfil vinculado ao serviço do Amazon EMR
Se você não precisar mais usar um recurso ou serviço que exija um perfil vinculado a um serviço, recomendamos excluir esse perfil. Dessa forma, você não terá uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar sua função vinculada ao serviço antes de excluí-la.
### Limpar um perfil vinculado ao serviço
Antes de usar o IAM para excluir um perfil vinculado ao serviço, você deve primeiro confirmar que o perfil não tem sessões ativas e remover todos os recursos usados por ele.
**Para verificar se a função vinculada ao serviço tem uma sessão ativa no console do IAM**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**. Selecione o nome (não a caixa de seleção) da função AWSService RoleFor EMRCleanup vinculada ao serviço.
1. Na página **Resumo** do perfil vinculado ao serviço selecionado, escolha **Consultor de acesso**.
1. Na guia **Consultor de acesso**, revise a atividade recente para a função vinculada ao serviço.
**nota**
Se você não tiver certeza se o Amazon EMR está usando AWSService RoleFor EMRCleanup a função vinculada ao serviço, você pode tentar excluir a função vinculada ao serviço. Se o serviço estiver usando o perfil vinculado ao serviço, a exclusão falhará e você poderá exibir as regiões em que o perfil está sendo usado. Se o perfil vinculado ao serviço estiver sendo usado, você deverá aguardar o término da sessão antes de exclui-lo. Não é possível revogar a sessão de uma função vinculada a um serviço.
**Para remover os recursos do Amazon EMR usados pelo AWSService RoleFor EMRCleanup**
+ Encerre todos os clusters em sua conta. Para obter mais informações, consulte [Encerramento de um cluster do Amazon EMR em estado iniciando, executando ou aguardando](UsingEMR_TerminateJobFlow.md).
### Excluir um perfil vinculado ao serviço (console do IAM)
É possível usar o console do IAM para excluir uma função vinculada ao serviço.
**Para excluir uma função vinculada ao serviço (console)**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**. Marque a caixa de seleção ao lado AWSService RoleForEMRCleanup, não o nome ou a linha em si.
1. Em ações de **Função** na parte superior da página, escolha a função **Excluir**.
1. Na caixa de diálogo de confirmação, revise os últimos dados acessados do serviço, que mostram quando cada uma das funções selecionadas acessou um AWS serviço pela última vez. Isso ajuda a confirmar se a função está ativa no momento. Para prosseguir, selecione **Yes, Delete**.
1. Monitore as notificações do console do IAM para progresso da exclusão da função vinculada ao serviço. Como a exclusão do perfil vinculado ao serviço do IAM é assíncrona, depois de enviar o perfil para exclusão, a tarefa de exclusão pode ou não ser bem-sucedida. Se a tarefa obtiver êxito, você poderá escolher **Visualizar Detalhes** ou **Visualizar Recursos** a partir das notificações para saber por que a exclusão falhou. Se houve falha na exclusão porque há recursos no serviço que estão sendo usados pela função, o motivo da falha incluirá uma lista de recursos.
### Excluir um perfil vinculado ao serviço (CLI do IAM)
Você pode usar os comandos do IAM do AWS Command Line Interface para excluir uma função vinculada ao serviço. Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Se essas condições não forem atendidas, essa solicitação poderá ser negada.
**Para excluir uma função vinculado ao serviço (CLI)**
1. Para verificar o status da tarefa de exclusão, você deve capturar o `deletion-task-id` da resposta. Digite o seguinte comando para enviar uma solicitação de exclusão de função vinculada ao serviço:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRCleanup
```
1. Digite o seguinte comando para verificar o estado da tarefa de exclusão:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
### Excluir uma função vinculada ao serviço (API do IAM)
É possível usar a API do IAM para excluir uma função vinculada ao serviço. Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Se essas condições não forem atendidas, essa solicitação poderá ser negada.
**Para excluir uma função vinculada ao serviço (API)**
1. Para enviar uma solicitação de exclusão para uma função vinculada ao serviço, ligue. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Na solicitação, especifique o nome da AWSService RoleFor EMRCleanup função.
Para verificar o status da tarefa de exclusão, você deve capturar o `DeletionTaskId` da resposta.
1. Para verificar o status da exclusão, chame [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). Na solicitação, especifique o `DeletionTaskId`.
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
## Regiões suportadas para AWSService RoleFor EMRCleanup
O Amazon EMR oferece suporte ao uso da função AWSService RoleFor EMRCleanup vinculada ao serviço nas seguintes regiões.
****
| Nome da região | Identidade da região | Compatível com o Amazon EMR |
| --- | --- | --- |
| Leste dos EUA (Norte da Virgínia) | us-east-1 | Sim |
| Leste dos EUA (Ohio) | us-east-2 | Sim |
| Oeste dos EUA (N. da Califórnia) | us-west-1 | Sim |
| Oeste dos EUA (Oregon) | us-west-2 | Sim |
| Ásia-Pacífico (Mumbai) | ap-south-1 | Sim |
| Ásia Pacifico (Osaka) | ap-northeast-3 | Sim |
| Ásia-Pacífico (Seul) | ap-northeast-2 | Sim |
| Ásia-Pacífico (Singapura) | ap-southeast-1 | Sim |
| Ásia-Pacífico (Sydney) | ap-southeast-2 | Sim |
| Ásia-Pacífico (Tóquio) | ap-northeast-1 | Sim |
| Canadá (Central) | ca-central-1 | Sim |
| Europa (Frankfurt) | eu-central-1 | Sim |
| Europa (Irlanda) | eu-west-1 | Sim |
| Europa (Londres) | eu-west-2 | Sim |
| Europa (Paris) | eu-west-3 | Sim |
| América do Sul (São Paulo) | sa-east-1 | Sim |
# Uso de perfis vinculados ao serviço com o Amazon EMR para registro em log com gravação antecipada
O Amazon EMR usa funções vinculadas a [serviços AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Um perfil vinculado ao serviço é um tipo especial de perfil do IAM vinculado diretamente ao Amazon EMR. As funções vinculadas ao serviço são predefinidas pelo Amazon EMR e incluem todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
Os perfis vinculados ao serviço funcionam com o perfil de serviço do Amazon EMR e o perfil de instância do Amazon EC2 para o Amazon EMR. Para obter mais informações sobre a função de serviço e o perfil da instância, consulte [Configurar funções de serviço do IAM para permissões do Amazon EMR para AWS serviços e recursos](emr-iam-roles.md).
Um perfil vinculado ao serviço facilita a configuração do Amazon EMR porque você não precisa adicionar as permissões necessárias manualmente. O Amazon EMR define as permissões dos perfis vinculados ao serviço e, a não ser que esteja definido de outra forma, somente o Amazon EMR poderá assumir os perfis. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM.
É possível excluir esse perfil vinculado ao serviço no Amazon EMR somente depois de excluir os recursos relacionados e encerrar todos os clusters do EMR na conta. Isso protege os recursos do Amazon EMR, para que você não possa remover inadvertidamente a permissão de acesso aos recursos.
## Permissões de perfil vinculado ao serviço para registro em log com gravação antecipada (WAL)
O Amazon EMR usa a função vinculada ao serviço **AWSServiceRoleForEMRWAL** para recuperar o status de um cluster.
A função vinculada ao serviço AWSService RoleFor EMRWAL confia nos seguintes serviços para assumir a função:
+ `emrwal.amazonaws.com`
A política de permissões [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) do perfil vinculado ao serviço permite que o Amazon EMR conclua as seguintes ações nos recursos especificados:
+ Ação: `DescribeCluster` em `*`
Você deve configurar permissões para permitir que uma entidade do IAM (neste caso, o Amazon EMR WAL) crie, edite ou exclua um perfil vinculado ao serviço. Adicione as seguintes instruções conforme necessário à política de permissões do perfil de instância:
## CreateServiceLinkedRole
**Para permitir que uma entidade do IAM crie a função vinculada ao AWSService RoleFor serviço EMRWAL**
Adicione a seguinte declaração à política de permissões da entidade do IAM que precisa criar a função vinculada ao serviço:
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## UpdateRoleDescription
**Para permitir que uma entidade do IAM edite a descrição da função vinculada ao serviço AWSService RoleFor EMRWAL**
Adicione a seguinte declaração à política de permissões da entidade do IAM que precisa editar a descrição de uma função vinculada ao serviço:
```
{
"Effect": "Allow",
"Action": [
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/emrwal.amazonaws.com*/AWSServiceRoleForEMRWAL*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## DeleteServiceLinkedRole
**Para permitir que uma entidade do IAM exclua a função vinculada ao AWSService RoleFor serviço EMRWAL**
Adicione a seguinte declaração à política de permissões da entidade do IAM que precisa excluir uma função vinculada ao serviço:
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": [
"emrwal.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
}
```
## Criar um perfil vinculado ao serviço para Amazon EMR
Você não precisa criar manualmente a função AWSService RoleFor EMRWAL. O Amazon EMR cria essa função vinculada ao serviço automaticamente quando você cria um espaço de trabalho do WAL com a CLI do EMRWAL ou a AWS CloudFormation partir de, HBase ou cria a função vinculada ao serviço quando você configura um espaço de trabalho para o Amazon EMR WAL e a função vinculada ao serviço ainda não existe. Você deve ter permissões para criar um perfil vinculado ao serviço. Para obter um exemplo de instrução que acrescenta essa capacidade à política de permissões de uma entidade do IAM (por exemplo, um usuário, grupo ou perfil), consulte a seção anterior, [Permissões de perfil vinculado ao serviço para registro em log com gravação antecipada (WAL)](#using-service-linked-roles-permissions-wal).
## Editar um perfil vinculado ao serviço do Amazon EMR
O Amazon EMR não permite que você edite a função vinculada ao serviço AWSService RoleFor EMRWAL. Depois que você criar um perfil vinculado ao serviço, não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, você pode editar a descrição do perfil vinculado ao serviço usando o IAM.
### Editar a descrição de uma função vinculada ao serviço (console do IAM)
Você pode usar o console do IAM para editar a descrição de uma função vinculada ao serviço.
**Para editar a descrição de uma função vinculada ao serviço (console)**
1. No painel de navegação do console do IAM, escolha **Perfis**.
1. Escolha o nome da função a ser modificada.
1. À direita de **Descrição do perfil**, escolha **Editar**.
1. Insira uma nova descrição na caixa e escolha **Save changes** (Salvar alterações).
### Editar descrição de um perfil vinculado ao serviço (CLI do IAM)
Você pode usar os comandos do IAM do AWS Command Line Interface para editar a descrição de uma função vinculada ao serviço.
**Para alterar a descrição de uma função (CLI)**
1. (Opcional) Para visualizar a descrição atual de a uma função, use um dos comandos a seguir:
```
$ aws iam get-role --role-name role-name
```
Use o nome da função, não o nome de recurso da Amazon (ARN), para fazer referência às funções com os comandos da CLI. Por exemplo, se uma função tiver o seguinte nome de recurso da Amazon (ARN): `arn:aws:iam::123456789012:role/myrole`, você fará referência à função como **myrole**.
1. Para atualizar a descrição de uma função vinculada a serviço, use um dos comandos a seguir:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Editar a descrição de uma função vinculada ao serviço (API do IAM)
Você pode usar a API do IAM para editar a descrição de uma função vinculada ao serviço.
**Para alterar a descrição de uma função (API)**
1. (Opcional) Para visualizar a descrição atual de uma função, use o comando a seguir:
API do IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Para atualizar a descrição de uma função, use o comando a seguir:
API do IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Excluir um perfil vinculado ao serviço do Amazon EMR
Se você não precisar mais usar um recurso ou serviço que exija um perfil vinculado a um serviço, recomendamos excluir esse perfil. Dessa forma, você não terá uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar sua função vinculada ao serviço antes de excluí-la.
**nota**
A operação de registro antecipado de gravação não será afetada se você excluir a função AWSService RoleFor EMRWAL, mas o Amazon EMR não excluirá automaticamente os registros criados quando o cluster do EMR for encerrado. Portanto, você precisará excluir manualmente os logs do Amazon EMR WAL se excluir o perfil vinculado ao serviço.
### Limpar uma função vinculada ao serviço
Antes de você poder usar o IAM para excluir uma função vinculada ao serviço, você deve primeiro confirmar que a função não tem sessões ativas e remover quaisquer recursos usados pela função.
**Para verificar se a função vinculada ao serviço tem uma sessão ativa no console do IAM**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**. Selecione o nome (não a caixa de seleção) da função AWSService RoleFor EMRWAL.
1. Na página **Summary (Resumo)** da função selecionada, selecione a guia **Access Advisor (Consultor de acesso)**.
1. Na guia **Consultor de acesso**, revise a atividade recente para a função vinculada ao serviço.
**nota**
Se você não tiver certeza se o Amazon EMR está usando AWSService RoleFor a função EMRWAL, você pode tentar excluir a função vinculada ao serviço. Se o serviço estiver usando o perfil, a exclusão falhará e você poderá exibir as regiões em que o perfil está sendo usado. Se o perfil vinculado ao serviço estiver sendo usado, você deverá aguardar o término da sessão antes de exclui-lo. Não é possível revogar a sessão de uma função vinculada a um serviço.
**Para remover os recursos do Amazon EMR usados pelo EMRWAL AWSService RoleFor**
+ Encerre todos os clusters em sua conta. Para obter mais informações, consulte [Encerramento de um cluster do Amazon EMR em estado iniciando, executando ou aguardando](UsingEMR_TerminateJobFlow.md).
### Excluir um perfil vinculado ao serviço (console do IAM)
É possível usar o console do IAM para excluir uma função vinculada ao serviço.
**Para excluir uma função vinculada ao serviço (console)**
1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação, escolha **Perfis**. Marque a caixa de seleção ao lado de AWSService RoleFor EMRWAL, não o nome ou a linha em si.
1. Em ações de **Função** na parte superior da página, escolha a função **Excluir**.
1. Na caixa de diálogo de confirmação, revise os últimos dados acessados do serviço, que mostram quando cada uma das funções selecionadas acessou um AWS serviço pela última vez. Isso ajuda a confirmar se a função está ativa no momento. Para prosseguir, selecione **Yes, Delete**.
1. Monitore as notificações do console do IAM para progresso da exclusão da função vinculada ao serviço. Como a exclusão da função vinculada ao serviço do IAM é assíncrona, depois de enviar a função para exclusão, a tarefa pode ou não ser bem-sucedida. Se a tarefa obtiver êxito, você poderá escolher **Visualizar Detalhes** ou **Visualizar Recursos** a partir das notificações para saber por que a exclusão falhou. Se houve falha na exclusão porque há recursos no serviço que estão sendo usados pela função, o motivo da falha incluirá uma lista de recursos.
### Excluir um perfil vinculado ao serviço (CLI do IAM)
Você pode usar os comandos do IAM do AWS Command Line Interface para excluir uma função vinculada ao serviço. Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Se essas condições não forem atendidas, essa solicitação poderá ser negada.
**Para excluir uma função vinculado ao serviço (CLI)**
1. Para verificar o status da tarefa de exclusão, você deve capturar o `deletion-task-id` da resposta. Digite o seguinte comando para enviar uma solicitação de exclusão de função vinculada ao serviço:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRWAL
```
1. Digite o seguinte comando para verificar o estado da tarefa de exclusão:
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/cli/latest/reference/iam/get-service-linked-role-deletion-status.html) --deletion-task-id deletion-task-id
```
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
### Excluir uma função vinculada ao serviço (API do IAM)
É possível usar a API do IAM para excluir uma função vinculada ao serviço. Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Se essas condições não forem atendidas, essa solicitação poderá ser negada.
**Para excluir uma função vinculada ao serviço (API)**
1. Para enviar uma solicitação de exclusão para uma função vinculada ao serviço, ligue. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) Na solicitação, especifique o nome da função AWSService RoleFor EMRWAL.
Para verificar o status da tarefa de exclusão, você deve capturar o `DeletionTaskId` da resposta.
1. Para verificar o status da exclusão, chame [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). Na solicitação, especifique o `DeletionTaskId`.
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
## Regiões suportadas pelo AWSService RoleFor EMRWAL
O Amazon EMR oferece suporte ao uso da função vinculada ao serviço AWSService RoleFor EMRWAL nas seguintes regiões.
****
| Nome da região | Identidade da região | Compatível com o Amazon EMR |
| --- | --- | --- |
| Leste dos EUA (Norte da Virgínia) | us-east-1 | Sim |
| Leste dos EUA (Ohio) | us-east-2 | Sim |
| Oeste dos EUA (N. da Califórnia) | us-west-1 | Sim |
| Oeste dos EUA (Oregon) | us-west-2 | Sim |
| Ásia-Pacífico (Mumbai) | ap-south-1 | Sim |
| Ásia-Pacífico (Singapura) | ap-southeast-1 | Sim |
| Ásia-Pacífico (Sydney) | ap-southeast-2 | Sim |
| Ásia-Pacífico (Tóquio) | ap-northeast-1 | Sim |
| Europa (Frankfurt) | eu-central-1 | Sim |
| Europa (Irlanda) | eu-west-1 | Sim |
# Personalização de perfis do IAM com o Amazon EMR
Talvez seja útil personalizar as permissões e os perfis de serviço do IAM para limitar os privilégios de acordo com seus requisitos de segurança. Para personalizar as permissões, recomendamos que você crie novas funções e políticas. Comece com as permissões nas políticas gerenciadas para as funções padrão (por exemplo, `AmazonElasticMapReduceforEC2Role` e `AmazonElasticMapReduceRole`). Em seguida, copie e cole o conteúdo em novas declarações de política, modifique as permissões conforme apropriado e anexe as políticas de permissões modificadas às funções que criar. Você deve ter as permissões apropriadas do IAM para trabalhar com perfis e políticas. Para obter mais informações, consulte [Permitir que usuários e grupos criem e modifiquem perfis](emr-iam-roles-create-permissions.md).
Se você criar um perfil personalizado do EMR para o EC2, siga o fluxo de trabalho básico, que criará automaticamente um perfil de instância com o mesmo nome. O Amazon EC2 permite criar perfis e perfis de instância com nomes diferentes, mas o Amazon EMR não oferece suporte a essa configuração, o que resulta em um erro de “perfil de instância inválido” quando você cria o cluster.
**Importante**
As políticas em linha não são atualizadas automaticamente quando os requisitos do serviço são alterados. Se você criar e anexar políticas em linha, lembre-se de que podem ocorrer atualizações de serviço que causem erros de permissão repentinamente. Para obter mais informações, consulte [Políticas gerenciadas e em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_managed-vs-inline.html) no *Guia do usuário do IAM* e em [Especificar perfis personalizados do IAM ao criar um cluster](#emr-iam-roles-launch-jobflow).
Para obter mais informações sobre como trabalhar com perfis do IAM, consulte os seguintes tópicos no *Guia do usuário do IAM*:
+ [Criação de uma função para delegar permissões a um serviço AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)
+ [Modificar uma função](https://docs.aws.amazon.com/IAM/latest/UserGuide/modifying-role.html)
+ [Excluir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/deleting-roles.html)
## Especificar perfis personalizados do IAM ao criar um cluster
Você especifica o perfil de serviço para o Amazon EMR e o perfil para o perfil de instância do Amazon EC2 ao criar um cluster. O usuário que está criando clusters precisa de permissões para recuperar e atribuir perfis a instâncias do EC2 e ao Amazon EMR. Caso contrário, ocorrerá um erro **account is not authorized to call EC2**. Para obter mais informações, consulte [Permitir que usuários e grupos criem e modifiquem perfis](emr-iam-roles-create-permissions.md).
### Usar o console para especificar perfis personalizados
Ao criar um cluster, você pode especificar um perfil de serviço personalizado para o Amazon EMR, um perfil personalizado para o perfil de instância do EC2 e um perfil do Auto Scaling personalizado usando as **Opções avançadas**. Quando você usa **Quick options (Opções avançadas)**, a função de serviço padrão e a função padrão para o perfil de instância do EC2 são especificadas. Para obter mais informações, consulte [Perfis de serviço do IAM usados pelo Amazon EMR](emr-iam-service-roles.md).
------
#### [ Console ]
**Para especificar perfis do IAM personalizados usando o console**
Ao criar um cluster usando o console, é necessário especificar um perfil de serviço personalizado para o Amazon EMR e um perfil personalizado para o perfil de instância do EC2. Para obter mais informações, consulte [Perfis de serviço do IAM usados pelo Amazon EMR](emr-iam-service-roles.md).
1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**.
1. Em **Configuração e permissões de segurança**, encontre os campos **Perfil do IAM para o perfil de instância** e **Perfil de serviço para o Amazon EMR**. Para cada tipo de função, selecione uma função na lista. Apenas as funções em sua conta que têm a política de confiança apropriada para esse tipo de função são listadas.
1. Escolha qualquer outra opção que se aplique ao cluster.
1. Para iniciar o cluster, escolha **Criar cluster**.
------
### Use o AWS CLI para especificar funções personalizadas
É possível especificar um perfil de serviço do Amazon EMR e um perfil de serviço para instâncias de cluster do EC2 usando explicitamente opções com o comando `create-cluster` na AWS CLI. Use a opção `--service-role` para especificar a função de serviço. Use o argumento `InstanceProfile` da opção `--ec2-attributes` para especificar a função para o perfil de instância do EC2.
O perfil do Auto Scaling é especificado usando uma opção separada, `--auto-scaling-role`. Para obter mais informações, consulte [Uso do ajuste de escala automático com uma política personalizada para grupos de instâncias no Amazon EMR](emr-automatic-scaling.md).
**Para especificar funções personalizadas do IAM usando o AWS CLI**
+ O comando a seguir especifica o perfil de serviço personalizado, *MyCustomServiceRoleForEMR*, e um perfil personalizado para o perfil da instância do EC2, *MyCustomServiceRoleForClusterEC2Instances*, ao iniciar um cluster. Este exemplo usa o perfil padrão do Amazon EMR.
**nota**
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).
```
aws emr create-cluster --name "Test cluster" --release-label emr-7.12.0 \
--applications Name=Hive Name=Pig --service-role MyCustomServiceRoleForEMR \
--ec2-attributes InstanceProfile=MyCustomServiceRoleForClusterEC2Instances,\
KeyName=myKey --instance-type m5.xlarge --instance-count 3
```
Você pode usar essas opções para especificar funções padrão explicitamente em vez de usar a opção `--use-default-roles`. A opção `--use-default-roles` especifica a função de serviço e a função do perfil de instância do EC2 definidas no arquivo `config` para a AWS CLI.
O exemplo a seguir demonstra o conteúdo de um `config` arquivo para as funções personalizadas especificadas para AWS CLI o Amazon EMR. Com esse arquivo de configuração, quando a `--use-default-roles` opção é especificada, o cluster é criado usando *MyCustomServiceRoleForEMR* e *MyCustomServiceRoleForClusterEC2Instances*. Por padrão, o arquivo `config` especifica a `service_role` padrão como `AmazonElasticMapReduceRole` e o `instance_profile` padrão como `EMR_EC2_DefaultRole`.
```
[default]
output = json
region = us-west-1
aws_access_key_id = myAccessKeyID
aws_secret_access_key = mySecretAccessKey
emr =
service_role = MyCustomServiceRoleForEMR
instance_profile = MyCustomServiceRoleForClusterEC2Instances
```
# Configurar perfis do IAM para solicitações do EMRFS para o Amazon S3
**nota**
O recurso de mapeamento de perfis do EMRFS descrito nesta página foi aprimorado com a introdução da solução Amazon S3 Access Grants no Amazon EMR 6.15.0. Para uma solução de controle de acesso escalável para os seus dados no Amazon S3, recomendamos usar o [S3 Access Grants com o Amazon EMR](emr-access-grants.md).
Quando uma aplicação em execução em um cluster faz referência a dados usando o formato `s3://mydata`, o Amazon EMR usa o EMRFS para fazer a solicitação. Para interagir com o Amazon S3, o EMRFS assume as políticas de permissões anexadas ao [perfil de instância do Amazon EC2](emr-iam-role-for-ec2.md). O mesmo perfil de instância do Amazon EC2 é usado independentemente do usuário ou do grupo que está executando a aplicação ou do local dos dados no Amazon S3.
Se tiver um cluster com vários usuários que precisam de diferentes níveis de acesso aos dados no Amazon S3 por meio do EMRFS, você poderá definir uma configuração de segurança com perfis do IAM para o EMRFS. O EMRFS pode assumir um perfil de serviço diferente para instâncias de cluster do EC2 com base no usuário ou no grupo que faz a solicitação ou com base na localização dos dados no Amazon S3. Cada perfil do IAM para o EMRFS pode ter permissões diferentes para acesso aos dados no Amazon S3. Para obter mais informações sobre o uso de perfis de serviço para instâncias de cluster do EC2. consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md).
Há suporte para uso de perfis personalizados do IAM para o EMRFS nas versões 5.10.0 e posteriores do Amazon EMR. Se usar uma versão anterior ou se tiver requisitos além dos fornecidos pelos perfis do IAM para EMRFS, você poderá criar um provedor de credenciais personalizadas. Para obter mais informações, consulte [Authorizing access to EMRFS data in Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider).
Ao usar uma configuração de segurança para especificar perfis do IAM para EMRFS, você configura mapeamentos de perfil. Cada mapeamento de perfil especifica um perfil do IAM que corresponde a identificadores. Esses identificadores determinam a base para o acesso ao Amazon S3 por meio do EMRFS. Os identificadores podem ser usuários, grupos ou prefixos do Amazon S3 que indicam um local de dados. Quando o EMRFS faz uma solicitação ao Amazon S3, se a solicitação corresponder à base para o acesso, o EMRFS fará com que as instâncias do EC2 do cluster assumam o perfil do IAM correspondente para a solicitação. As permissões do IAM anexadas ao perfil se aplicam no lugar das permissões do IAM anexadas ao perfil de serviço para instâncias do EC2 do cluster.
Os usuários e os grupos em um mapeamento de função são usuários e grupos do Hadoop definidos no cluster. Os usuários e os grupos são passados para o EMRFS no contexto do aplicativo que o usa (por exemplo, a personificação de usuário do YARN). O prefixo do Amazon S3 pode ser um especificador do bucket de qualquer profundidade (por exemplo `s3://amzn-s3-demo-bucket` ou `s3://amzn-s3-demo-bucket/myproject/mydata`). Você pode especificar vários identificadores em um único mapeamento de função, mas todos devem ser do mesmo tipo.
**Importante**
Os perfis do IAM para o EMRFS fornecem isolamento no nível da aplicação entre os usuários da aplicação. Isso não fornece isolamento no nível do host entre os usuários no host. Qualquer usuário com acesso ao cluster pode ignorar o isolamento para assumir qualquer uma das funções.
Quando uma aplicação de cluster faz uma solicitação ao Amazon S3 por meio do EMRFS, o EMRFS avalia os mapeamentos do perfil de cima para baixo na ordem em que aparecem na configuração de segurança. Se uma solicitação feita por meio do EMRFS não corresponder a nenhum identificador, o EMRFS retornará ao uso do perfil de serviço para instâncias do EC2 do cluster. Por esse motivo, recomendamos que as políticas anexadas ao perfil limitem as permissões ao Amazon S3. Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md).
## Configurar funções do
Antes de definir uma configuração de segurança com funções do IAM para EMRFS, planeje e crie perfis e as políticas de permissão a serem anexadas aos perfis. Para obter mais informações, consulte [Como os perfis para as instâncias do Amazon EC2 funcionam?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) no *Guia do usuário do IAM*. Ao criar políticas de permissão, recomendamos começar com a política gerenciada anexada ao perfil do Amazon EMR padrão para o EC2 e depois editar essa política de acordo com seus requisitos. O nome de perfil padrão é `EMR_EC2_DefaultRole`, e a política gerenciada padrão a ser editada é `AmazonElasticMapReduceforEC2Role`. Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md).
### Atualizar políticas de confiança para permissões para assumir perfil
Cada perfil que o EMRFS usa deve ter uma política de confiança que permite que o perfil do Amazon EMR para o EC2 do cluster o assuma. Da mesma forma, o perfil do Amazon EMR para o EC2 do cluster deve ter uma política de confiança que permita que os perfis do EMRFS o assumam.
O exemplo de política de confiança a seguir está anexado a funções para o EMRFS. A instrução permite que o perfil padrão do Amazon EMR para o EC2 assuma o perfil. Por exemplo, se você tiver duas funções do EMRFS fictícias `EMRFSRole_First` e `EMRFSRole_Second`, esta declaração de política será adicionada às políticas de confiança para cada uma delas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Além disso, o exemplo a seguir de declaração de política de confiança é adicionado à `EMR_EC2_DefaultRole` para permitir que as duas funções do EMRFS fictícias a assumam.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/EMRFSRole_First",
"arn:aws:iam::123456789012:role/EMRFSRole_Second"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
**Atualizar a política de confiança de um perfil do IAM**
Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Selecione **Roles (funções)**, insira o nome da função em **Search (Pesquisar)** e, em seguida, selecione o **Role name (Nome da função)**.
1. Escolha **Trust relationships (Relacionamentos de confiança)**, **Edit trust relationship (Editar relacionamento de confiança)**.
1. Adicione uma instrução de confiança de acordo com o **Documento da política**, de acordo com as diretrizes acima e selecione **Atualizar política de confiança**.
### Especificar um perfil como um usuário da chave
Se o perfil permitir acesso a um local no Amazon S3 que é criptografado usando uma AWS KMS key, especifique o perfil como um usuário de chaves. Isso concede permissões ao perfil para usar a chave do KMS. Para saber mais, consulte [Políticas de chaves no AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) no *Guia do desenvolvedor do AWS Key Management Service *.
## Definir uma configuração de segurança com perfis do IAM para EMRFS
**Importante**
Se nenhuma das perfis do IAM para EMRFS que você especificar for aplicável, o EMRFS retornará para o perfil do Amazon EMR para EC2. Considere a possibilidade de personalizar esse perfil para restringir permissões para o Amazon S3 conforme apropriado para suas aplicação e especificar esse perfil personalizado em vez de `EMR_EC2_DefaultRole` ao criar um cluster. Para obter mais informações, consulte [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md) e [Especificar perfis personalizados do IAM ao criar um cluster](emr-iam-roles-custom.md#emr-iam-roles-launch-jobflow).
**Especificar perfis do IAM para solicitações do EMRFS para o Amazon S3 usando o console**
1. Crie uma configuração de segurança que especifica os mapeamentos de função:
1. No console do Amazon EMR, selecione **Configurações de segurança**, **Criar**.
1. Digite um nome em **Name (Nome)** para a configuração de segurança. Esse nome é usado para especificar a configuração de segurança ao criar um cluster.
1. Escolha **Usa perfis do IAM para solicitações do EMRFS ao Amazon S3**.
1. Selecione um **Perfil do IAM** a ser aplicada e, em **Base para acesso**, selecione um tipo de identificador (**Usuários**, **Grupos** ou **Prefixos do S3**) na lista e insira os identificadores correspondentes. Se você usar vários identificadores, separe-os com uma vírgula e sem espaço. Para obter mais informações sobre cada tipo de identificador, consulte a [JSON configuration reference](#emrfs-seccfg-json) abaixo.
1. Escolha **Add role (Adicionar função)** para configurar mapeamentos de funções adicionais, conforme descrito na etapa anterior.
1. Configure outras opções de configuração de segurança conforme apropriado e escolha **Create (Criar)**. Para obter mais informações, consulte [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md).
1. Especifique a configuração de segurança criada acima ao criar um cluster. Para obter mais informações, consulte [Como especificar uma configuração de segurança para um cluster do Amazon EMR](emr-specify-security-configuration.md).
**Para especificar funções do IAM para solicitações do EMRFS para o Amazon S3 usando o AWS CLI**
1. Use o comando `aws emr create-security-configuration`, especificando um nome para a configuração de segurança e os detalhes da configuração de segurança no formato JSON.
O comando de exemplo mostrado a seguir cria uma configuração de segurança com o nome `EMRFS_Roles_Security_Configuration`. Ele é baseado em uma estrutura JSON no arquivo `MyEmrfsSecConfig.json`, que é salvo no mesmo diretório onde o comando é executado.
```
aws emr create-security-configuration --name EMRFS_Roles_Security_Configuration --security-configuration file://MyEmrFsSecConfig.json.
```
Use as diretrizes a seguir para a estrutura do arquivo `MyEmrFsSecConfig.json`. Você pode especificar essa estrutura juntamente com estruturas de outras opções de configuração de segurança. Para obter mais informações, consulte [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md).
Veja a seguir um exemplo de trecho JSON para especificar perfis do IAM personalizados para o EMRFS em uma configuração de segurança. Ele demonstra mapeamentos de perfil para os três tipos diferentes de identificadores, seguidos por uma referência de parâmetro.
```
{
"AuthorizationConfiguration": {
"EmrFsConfiguration": {
"RoleMappings": [{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_user1",
"IdentifierType": "User",
"Identifiers": [ "user1" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_to_demo_s3_buckets",
"IdentifierType": "Prefix",
"Identifiers": [ "s3://amzn-s3-demo-bucket1/","s3://amzn-s3-demo-bucket2/" ]
},{
"Role": "arn:aws:iam::123456789101:role/allow_EMRFS_access_for_AdminGroup",
"IdentifierType": "Group",
"Identifiers": [ "AdminGroup" ]
}]
}
}
}
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html)
1. Use o comando `aws emr create-cluster` para criar um cluster e especifique a configuração de segurança que você criou na etapa anterior.
O exemplo a seguir cria um cluster com aplicativos Hadoop de núcleo padrão instalados. O cluster usa a configuração de segurança criada acima como `EMRFS_Roles_Security_Configuration` e também usa um perfil do Amazon EMR personalizado para o EC2, `EC2_Role_EMR_Restrict_S3`, que é especificada usando o argumento `InstanceProfile` do parâmetro `--ec2-attributes`.
**nota**
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).
```
aws emr create-cluster --name MyEmrFsS3RolesCluster \
--release-label emr-7.12.0 --ec2-attributes InstanceProfile=EC2_Role_EMR_Restrict_S3,KeyName=MyKey \
--instance-type m5.xlarge --instance-count 3 \
--security-configuration EMRFS_Roles_Security_Configuration
```
# Use políticas baseadas em recursos para o acesso do Amazon EMR ao Glue Data Catalog AWS
Se você usa o AWS Glue em conjunto com o Hive, o Spark ou o Presto no Amazon EMR AWS , o Glue oferece suporte a políticas baseadas em recursos para controlar o acesso aos recursos do catálogo de dados. Esses recursos incluem bancos de dados, tabelas, conexões e funções definidas pelo usuário. Para obter mais informações, consulte [Políticas baseadas em recursos no AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/glue-resource-policies.html) no *Guia do desenvolvedor do AWS Glue*.
Ao usar políticas baseadas em recursos para limitar o acesso ao AWS Glue de dentro do Amazon EMR, o principal que você especifica na política de permissões deve ser o ARN da função associado ao perfil de instância do EC2 que é especificado quando um cluster é criado. Por exemplo, para uma política baseada em recursos anexada a um catálogo, você pode especificar o ARN da função para a função de serviço padrão para instâncias EC2 de cluster, *EMR\$1EC2\$1DefaultRole* como a`Principal`, usando o formato mostrado no exemplo a seguir:
```
arn:aws:iam::acct-id:role/EMR_EC2_DefaultRole
```
*acct-id*Pode ser diferente do ID da conta AWS Glue. Isso possibilita o acesso de clusters do EMR em outras contas. Você pode especificar várias entidades principais, cada uma de uma conta diferente.
# Use funções do IAM com aplicativos que chamam AWS serviços diretamente
Os aplicativos executados nas instâncias do EC2 de um cluster podem usar o perfil da instância do EC2 para obter credenciais de segurança temporárias ao chamar serviços. AWS
As versões do Hadoop disponíveis com a versão 2.3.0 e posteriores do Amazon EMR já foram atualizadas para usar perfis do IAM. Se seu aplicativo é executado estritamente sobre a arquitetura do Hadoop e não chama diretamente nenhum serviço AWS, ele deve funcionar com funções do IAM sem modificações.
Se seu aplicativo chamar serviços AWS diretamente, você precisará atualizá-lo para aproveitar as funções do IAM. Isso significa que, em vez de obter credenciais de conta de `/etc/hadoop/conf/core-site.xml` nas instâncias do EC2 no cluster, sua aplicação usa um SDK para acessar os recursos usando perfis do IAM ou chama os metadados de instâncias do EC2 para obter as credenciais temporárias.
**Para acessar AWS recursos com funções do IAM usando um SDK**
+ Os tópicos a seguir mostram como usar vários deles AWS SDKs para acessar credenciais temporárias usando funções do IAM. Cada tópico começa com uma versão de uma aplicação que não usa perfis do IAM e depois percorre o processo de conversão dessa aplicação para usar perfis do IAM.
+ [Using IAM roles for Amazon EC2 instances with the SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) no *Guia do usuário do AWS SDK para Java *
+ [Using IAM roles for Amazon EC2 instances with the SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-hosm.html) no *Guia do usuário do AWS SDK para .NET *
+ [Using IAM roles for Amazon EC2 instances with the SDK for PHP](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/php-dg-roles.html) no *Guia do usuário do AWS SDK para PHP *
+ [Using IAM roles for Amazon EC2 instances with the SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ruby-dg-roles.html) no *Guia do usuário do AWS SDK para Ruby *
**Para obter credenciais temporárias de metadados de instâncias do EC2**
+ Chame a seguinte URL de uma instância do EC2 que está sendo executada com a função IAM especificada, que retorna as credenciais de segurança temporárias associadas (AccessKeyId, SecretAccessKey SessionToken, e Expiration). O exemplo a seguir usa o perfil de instância padrão para o Amazon EMR, `EMR_EC2_DefaultRole`.
```
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/EMR_EC2_DefaultRole
```
Para obter mais informações sobre como escrever aplicativos que usam funções do IAM, consulte [Conceder acesso AWS a recursos para aplicativos executados em instâncias do Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html).
Para obter mais informações sobre credenciais de segurança temporárias, consulte [Using temporary security credentials](https://docs.aws.amazon.com/STS/latest/UsingSTS/using-temp-creds.html) no guia *Using Temporary Security Credentials*.
# Permitir que usuários e grupos criem e modifiquem perfis
As entidades principais do IAM (usuários e grupos) que criam, modificam e especificam os perfis para um cluster, incluindo perfis padrão, devem ter permissão para executar as ações a seguir. Para obter detalhes sobre cada ação, consulte [Actions](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) na *IAM API Reference*.
+ `iam:CreateRole`
+ `iam:PutRolePolicy`
+ `iam:CreateInstanceProfile`
+ `iam:AddRoleToInstanceProfile`
+ `iam:ListRoles`
+ `iam:GetPolicy`
+ `iam:GetInstanceProfile`
+ `iam:GetPolicyVersion`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
A permissão `iam:PassRole` permite a criação do cluster. As permissões restantes permitem a criação das funções padrão.
Para obter informações sobre como atribuir permissões a um usuário, consulte [Alteração de permissões de um usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) no *Guia do usuário do IAM*.
# Exemplos de políticas baseadas em identidade do Amazon EMR
Por padrão, usuários e perfis não têm permissão para criar ou modificar recursos do Amazon EMR. Eles também não podem realizar tarefas usando a AWS API Console de gerenciamento da AWS AWS CLI, ou. Um administrador do IAM deve criar políticas do IAM que concedam aos usuários e perfis permissão para executarem operações de API específicas nos recursos especificados de que precisam. O administrador deve anexar essas políticas aos usuários ou grupos que exigem essas permissões.
Para saber como criar uma política baseada em identidade do IAM utilizando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Guia do usuário do IAM*.
**Topics**
+ [Práticas recomendadas de políticas para o Amazon EMR](security_iam_service-with-iam-policy-best-practices.md)
+ [Permitir que os usuários visualizem suas próprias permissões](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Políticas gerenciadas do Amazon EMR](emr-managed-iam-policies.md)
+ [Políticas do IAM para acesso baseado em etiquetas a clusters e Cadernos do EMR](emr-fine-grained-cluster-access.md)
+ [Negando a ModifyInstanceGroup ação no Amazon EMR](emr-cluster-deny-modifyinstancegroup.md)
+ [Solução de problemas de identidade e acesso da Amazon EMR](security_iam_troubleshoot.md)
# Práticas recomendadas de políticas para o Amazon EMR
As políticas baseadas em identidade são muito poderosas. Determinam se alguém pode criar, acessar ou excluir recursos do Amazon EMR em sua conta. Essas ações podem gerar custos para sua AWS conta. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:
+ **Comece a usar políticas AWS gerenciadas** — Para começar a usar o Amazon EMR rapidamente, use políticas AWS gerenciadas para dar aos seus funcionários as permissões de que precisam. Essas políticas já estão disponíveis em sua conta e são mantidas e atualizadas pela AWS. Para obter mais informações, consulte [Comece a usar permissões com políticas AWS gerenciadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) no *Guia do usuário do IAM* [Políticas gerenciadas do Amazon EMR](emr-managed-iam-policies.md) e.
+ **Conceder privilégio mínimo**: ao criar políticas personalizadas, conceda apenas as permissões necessárias para executar uma tarefa. Comece com um conjunto mínimo de permissões e conceda permissões adicionais conforme necessário. Fazer isso é mais seguro do que começar com permissões que são muito lenientes e tentar restringi-las superiormente. Para obter mais informações, consulte [Conceder privilégio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) no *Guia do usuário do IAM*.
+ **Habilitar o MFA para operações confidenciais**: para reforçar a segurança, exija que os usuários usem a autenticação multifator (MFA) para acessar recursos ou operações de API sigilosos. Para obter mais informações, consulte [Usar autenticação multifator (MFA) AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) no *Guia do usuário do IAM*.
+ **Usar condições de política para segurança adicional**: na medida do possível, defina as condições sob as quais suas políticas baseadas em identidade permitem o acesso a um recurso. Por exemplo, você pode gravar condições para especificar um intervalo de endereços IP permitidos do qual a solicitação deve partir. Você também pode escrever condições para permitir somente solicitações em uma data especificada ou período ou para exigir o uso de SSL ou MFA. Para obter mais informações, consulte [Elementos de política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
# Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como você pode criar uma política que permite que os usuários visualizem as políticas gerenciadas e em linha anexadas as respectivas identidades de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou AWS .
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListUserPolicies"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:ListUsers"
],
"Resource": [
"*"
]
}
]
}
```
------
# Políticas gerenciadas do Amazon EMR
A maneira mais fácil de conceder acesso total ou acesso somente leitura a ações do Amazon EMR é usar as políticas gerenciadas do IAM para o Amazon EMR. Políticas gerenciadas oferecem o benefício de serem atualizadas automaticamente se os requisitos de permissões forem alterados. Se você usar políticas em linha, podem ocorrer alterações de serviço que provoquem erros de permissão.
O Amazon EMR substituirá as políticas gerenciadas já existentes (políticas v1) em favor de novas políticas gerenciadas (políticas v2). As novas políticas gerenciadas foram reduzidas para se alinharem às melhores práticas. AWS Depois que as políticas gerenciadas v1 existentes forem defasadas, não será possível anexar essas políticas a nenhum novo perfil ou usuário do IAM. Os perfis e os usuários existentes que usam políticas defasadas podem continuar a usá-las. As políticas gerenciadas v2 restringem o acesso usando etiquetas. Elas permitem somente ações específicas do Amazon EMR e exigem recursos de cluster marcados com uma chave específica do EMR. É recomendável analisar cuidadosamente a documentação antes de usar as novas políticas v2.
As políticas v1 serão marcadas como defasadas com um ícone de aviso próximo a elas na lista **Políticas** no console do IAM. As políticas defasadas terão as seguintes características:
+ Continuarão funcionando para todos os usuários, grupos e perfis atualmente conectados. Nada é rompido.
+ Não é possível anexar a novos usuários, grupos ou perfis. Se você desvincular uma das políticas de uma entidade atual, não poderá anexá-la novamente.
+ Após separar uma política v1 de todas as entidades atuais, a política não estará mais visível e não poderá mais ser usada.
A tabela a seguir resume as alterações entre as políticas atuais (v1) e v2.
**Alterações de políticas gerenciadas pelo Amazon EMR**
| Tipo de política | Nomes de política | Finalidade da política | Alterações na política v2 |
| --- | --- | --- | --- |
| Perfil de serviço do EMR padrão e política gerenciada anexada | Nome da função: **EMR\$1 DefaultRole** Política V1 (a ser descontinuada): (função de serviço do **AmazonElasticMapReduceRole**EMR) Nome da política v2 (com escopo reduzido): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Permite que o Amazon EMR chame outros AWS serviços em seu nome ao provisionar recursos e realizar ações em nível de serviço. Essa função é necessária para todos os clusters. | A política adiciona a nova permissão `"ec2:DescribeInstanceTypeOfferings"`. Essa operação de API retorna uma lista de tipos de instância compatíveis com uma lista de determinadas zonas de disponibilidade. |
| Política gerenciada pelo IAM para acesso total ao Amazon EMR por usuário, perfil ou grupo vinculado | Nome da política v2 (no escopo): [`AmazonEMRServicePolicy_v2`](emr-managed-policy-fullaccess-v2.md) | Concede aos usuários permissões completas para ações do EMR. Inclui iam: PassRole permissões para recursos. | A política adiciona o pré-requisito de que os usuários devem adicionar etiquetas de usuário aos recursos para poderem usar essa política. Consulte [Etiquetar recursos para usar políticas gerenciadas](#manually-tagged-resources). iam: a PassRole ação requer iam: PassedToService condição definida para o serviço especificado. O acesso ao Amazon EC2, ao Amazon S3 e a outros serviços não é permitido por padrão. Consulte [IAM Managed Policy for Full Access (v2 Managed Default Policy)](emr-managed-policy-fullaccess-v2.md). |
| Política gerenciada do IAM para acesso somente leitura ao EMR por usuário, perfil ou grupo vinculado | Política v1 (a ser defasada): [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) Nome da política v2 (no escopo): [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) | Concede aos usuários permissões somente leitura para ações do Amazon EMR. | As permissões concedem somente ações específicas de leitura do elasticmapreduce. O acesso ao Amazon S3 é um acesso não concedido por padrão. Consulte [IAM Managed Policy for Read-Only Access (v2 Managed Default Policy)](emr-managed-policy-readonly-v2.md). |
| Perfil de serviço do EMR padrão e política gerenciada anexada | Nome da função: **EMR\$1 DefaultRole** Política V1 (a ser descontinuada): (função de serviço do **AmazonElasticMapReduceRole**EMR) Nome da política v2 (com escopo reduzido): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Permite que o Amazon EMR chame outros AWS serviços em seu nome ao provisionar recursos e realizar ações em nível de serviço. Essa função é necessária para todos os clusters. | O perfil de serviço v2 e a política padrão v2 substituem o perfil e a política defasados. A política adiciona o pré-requisito de que os usuários devem adicionar etiquetas de usuário aos recursos para poderem usar essa política. Consulte [Etiquetar recursos para usar políticas gerenciadas](#manually-tagged-resources). Consulte [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md). |
| Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2) | Nome da função: **EMR\$1 \$1 EC2 DefaultRole** **Nome da política obsoleta: Role AmazonElasticMapReducefor EC2** | Permite que aplicações executadas em um cluster do EMR acessem outros recursos da AWS , como o Amazon S3. Por exemplo, se você executar trabalhos do Apache Spark que processam dados do Amazon S3, a política precisará permitir o acesso a esses recursos. | Tanto o perfil padrão como a política padrão estão prestes a serem defasados. Não há nenhuma função ou política gerenciada AWS padrão de substituição. É necessário fornecer uma política baseada em recursos ou em identidade. Isso significa que, por padrão, as aplicações executados em um cluster do EMR não têm acesso ao Amazon S3 ou a outros recursos, a menos que você os adicione à política manualmente. Consulte [Perfil padrão e política gerenciada](emr-iam-role-for-ec2.md#emr-ec2-role-default). |
| Outras políticas de perfil de serviço do EC2 | Nomes atuais da política: **AmazonElasticMapReduceforAutoScalingRole, AmazonElasticMapReduceEditorsRole, Amazon EMRCleanup Policy** | Fornece as permissões que o Amazon EMR precisa para acessar outros recursos da AWS e realizar ações se estiver usando ajuste de escala automático, cadernos ou para limpar recursos do EC2. | Nenhuma alteração na v2. |
## Objetivo de proteção: PassRole
As políticas gerenciadas padrão de permissões completas do Amazon EMR incorporam configurações de segurança `iam:PassRole`, incluindo estas:
+ Permissões `iam:PassRole` somente para perfis padrão específicos do Amazon EMR.
+ `iam:PassedToService`condições que permitem que você use a política somente com AWS serviços específicos, como `elasticmapreduce.amazonaws.com` `ec2.amazonaws.com` e.
Você pode visualizar a versão JSON das políticas Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) no console do IAM. É recomendável criar novos clusters com políticas gerenciadas v2.
Para criar políticas personalizadas, recomendamos que você comece com as políticas gerenciadas e edite-as de acordo com seus requisitos.
Para obter informações sobre como anexar políticas aos usuários (entidades principais), consulte Console de gerenciamento da AWS[Working with managed policies using the ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#policies_using-managed-console) no *Guia do usuário do IAM*.
## Etiquetar recursos para usar políticas gerenciadas
**O Amazon EMRService Policy\$1v2** e o **EMRFullAccessPolicyAmazon** \$1v2 dependem do acesso limitado aos recursos que o Amazon EMR provisiona ou usa. Obtém-se o escopo reduzido restringindo o acesso somente aos recursos que têm uma etiqueta de usuário predefinida associada a eles. Ao usar qualquer uma dessas duas políticas, é necessário passar a etiqueta de usuário predefinida `for-use-with-amazon-emr-managed-policies = true` ao provisionar o cluster. O Amazon EMR propagará essa etiqueta automaticamente. Além disso, é necessário adicionar uma etiqueta de usuário aos recursos listados na seção a seguir. Se você usa o console do Amazon EMR para iniciar seu cluster, consulte [Considerações sobre o uso do console do Amazon EMR para iniciar clusters com políticas gerenciadas v2](#emr-cluster-v2policy-awsconsole-launch).
Para usar políticas gerenciadas, passe a etiqueta de usuário `for-use-with-amazon-emr-managed-policies = true` ao provisionar um cluster com a CLI, o SDK ou outro método.
Quando você passa a etiqueta, o Amazon EMR propaga a etiqueta para a sub-rede privada ENI, a instância do EC2 e os volumes do EBS que ele cria. O Amazon EMR também etiqueta automaticamente os grupos de segurança que ele cria. No entanto, para que o Amazon EMR seja iniciado com determinado grupo de segurança, você deve etiquetá-lo. Para recursos que não são criados pelo Amazon EMR, é necessário adicionar etiquetas a esses recursos. Por exemplo, você deve marcar sub-redes do Amazon EC2, grupos de segurança do EC2 (se não forem criados pelo Amazon EMR) e (se VPCs quiser que o Amazon EMR crie grupos de segurança). Para iniciar clusters com políticas gerenciadas v2 VPCs, você deve marcá-los VPCs com a tag de usuário predefinida. Consulte [Considerações sobre o uso do console do Amazon EMR para iniciar clusters com políticas gerenciadas v2](#emr-cluster-v2policy-awsconsole-launch).
**Marcação propagada especificada pelo usuário**
O Amazon EMR marca os recursos que ele cria usando as etiquetas do Amazon EMR especificadas ao criar um cluster. O Amazon EMR aplica etiquetas aos recursos que cria durante a vida útil do cluster.
O Amazon EMR propaga etiquetas de usuário para os seguintes recursos:
+ ENI da sub-rede privada (interfaces de rede elástica de acesso ao serviço)
+ Instâncias do EC2
+ Volumes do EBS
+ Modelos de inicialização do EC2
**Grupos de segurança etiquetados automaticamente**
O Amazon EMR marca os grupos de segurança do EC2 que ele cria com a etiqueta necessária para políticas gerenciadas v2 para o Amazon EMR, `for-use-with-amazon-emr-managed-policies`, independentemente das etiquetas que você especificar no comando para criar o cluster. Em um grupo de segurança criado antes da introdução das políticas gerenciadas v2, o Amazon EMR não etiqueta o grupo de segurança automaticamente. Para usar políticas gerenciadas v2 com os grupos de segurança padrão que já existem na conta, você precisa etiquetar os grupos de segurança manualmente com `for-use-with-amazon-emr-managed-policies = true`.
**Recursos de cluster etiquetados manualmente**
É necessário etiquetar alguns recursos do cluster manualmente para que eles possam ser acessados pelos perfis padrão do Amazon EMR.
+ Você deve marcar manualmente os grupos de segurança do EC2 e as sub-redes do EC2 com a etiqueta de política gerenciada do Amazon EMR `for-use-with-amazon-emr-managed-policies`.
+ Você deve etiquetar manualmente uma VPC, se quiser que o Amazon EMR crie grupos de segurança padrão. O EMR tentará criar um grupo de segurança com a etiqueta específica se o grupo de segurança padrão ainda não existir.
O Amazon EMR marca automaticamente os seguintes recursos:
+ Grupos de segurança do EC2 criados pelo EMR
Você deve etiquetar manualmente os seguintes recursos:
+ Sub-rede EC2
+ Grupos de segurança do EC2
Opcionalmente, você pode etiquetar manualmente os seguintes recursos:
+ VPC: somente quando quiser que o Amazon EMR crie grupos de segurança
## Considerações sobre o uso do console do Amazon EMR para iniciar clusters com políticas gerenciadas v2
É possível provisionar clusters com políticas gerenciadas v2 usando o console do Amazon EMR. Veja aqui algumas considerações ao usar o console para iniciar clusters do Amazon EMR.
+ Não é necessário passar a etiqueta predefinida. O Amazon EMR adiciona a etiqueta automaticamente e a propaga para os componentes adequados.
+ Para componentes que precisam ser etiquetados manualmente, o antigo console do Amazon EMR tenta etiquetá-los automaticamente se você tiver as permissões necessárias para etiquetar recursos. Se você não tiver as permissões para marcar recursos ou se quiser usar o console, peça para o administrador marcar esses recursos.
+ Não é possível iniciar clusters com políticas gerenciadas v2 sem que todos os pré-requisitos sejam atendidos.
+ O console antigo do Amazon EMR mostra quais recursos (VPC/sub-redes) precisam ser etiquetados.
# Política gerenciada do IAM para acesso total (política gerenciada v2 padrão) do Amazon EMR
As políticas gerenciadas padrão do EMR com escopo para v2 concedem privilégios de acesso específicos aos usuários. Eles exigem uma etiqueta de recurso predefinida do Amazon EMR e chaves de condição `iam:PassRole` para os recursos usados pelo Amazon EMR, como a `Subnet` e o `SecurityGroup` que você usa para iniciar o cluster.
Para conceder as ações necessárias para o Amazon EMR, anexe a política gerenciada `AmazonEMRFullAccessPolicy_v2`. Essa política gerenciada padrão atualizada substitui a política gerenciada [`AmazonElasticMapReduceFullAccess`](emr-managed-policy-fullaccess.md).
`AmazonEMRFullAccessPolicy_v2` depende do acesso de escopo limitado aos recursos que o Amazon EMR provisiona ou usa. Ao usar essa política, é necessário passar a etiqueta de usuário `for-use-with-amazon-emr-managed-policies = true` ao provisionar o cluster. O Amazon EMR propagará a etiqueta automaticamente. Além disso, talvez seja necessário adicionar manualmente uma etiqueta de usuário a tipos específicos de recursos, como grupos de segurança do EC2 que não foram criados pelo Amazon EMR. Para obter mais informações, consulte [Etiquetar recursos para usar políticas gerenciadas](emr-managed-iam-policies.md#manually-tagged-resources).
A política [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) protege os recursos fazendo o seguinte:
+ Requer que os recursos sejam marcados com a etiqueta predefinida de políticas gerenciadas do Amazon EMR `for-use-with-amazon-emr-managed-policies` para criação de clusters e acesso ao Amazon EMR.
+ Restringe a ação `iam:PassRole` a perfis padrão específicos e acesso `iam:PassedToService` a serviços específicos.
+ Não permite mais acesso ao Amazon EC2, ao Amazon S3 e a outros serviços por padrão.
Veja a seguir o conteúdo dessa política.
**nota**
Você também pode usar o link do console [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRFullAccessPolicy_v2) para visualizar a política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithEMRManagedTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true"
}
}
},
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddInstanceFleet",
"elasticmapreduce:AddInstanceGroups",
"elasticmapreduce:AddJobFlowSteps",
"elasticmapreduce:AddTags",
"elasticmapreduce:CancelSteps",
"elasticmapreduce:CreateEditor",
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:CreateSecurityConfiguration",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:DeleteSecurityConfiguration",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribePersistentAppUI",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetPersistentAppUIPresignedURL",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ModifyCluster",
"elasticmapreduce:ModifyInstanceFleet",
"elasticmapreduce:ModifyInstanceGroups",
"elasticmapreduce:OpenEditorInConsole",
"elasticmapreduce:PutAutoScalingPolicy",
"elasticmapreduce:PutBlockPublicAccessConfiguration",
"elasticmapreduce:PutManagedScalingPolicy",
"elasticmapreduce:RemoveAutoScalingPolicy",
"elasticmapreduce:RemoveManagedScalingPolicy",
"elasticmapreduce:RemoveTags",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_DefaultRole",
"arn:aws:iam::*:role/EMR_DefaultRole_V2"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_EC2_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForAutoScaling",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/EMR_AutoScaling_DefaultRole"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "application-autoscaling.amazonaws.com*"
}
}
},
{
"Sid": "ElasticMapReduceServiceLinkedRole",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/elasticmapreduce.amazonaws.com*/AWSServiceRoleForEMRCleanup*"
],
"Condition": {
"StringEquals": {
"iam:AWSServiceName": [
"elasticmapreduce.amazonaws.com",
"elasticmapreduce.amazonaws.com.rproxy.govskope.ca.cn"
]
}
}
},
{
"Sid": "ConsoleUIActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeAccountAttributes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeNatGateways",
"ec2:DescribeRouteTables",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeVpcEndpoints",
"s3:ListAllMyBuckets",
"iam:ListRoles"
],
"Resource": [
"*"
]
}
]
}
```
------
# Política gerenciada do IAM para acesso total (prestes a ser defasada)
As políticas gerenciadas `AmazonElasticMapReduceFullAccess` e `AmazonEMRFullAccessPolicy_v2` AWS Identity and Access Management (IAM) concedem todas as ações necessárias para o Amazon EMR e outros serviços.
**Importante**
A política gerenciada `AmazonElasticMapReduceFullAccess` está prestes a ser defasada e seu uso com o Amazon EMR não é mais recomendado. Em seu lugar, use [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md). Quando o serviço do IAM eventualmente defasar a política v1, você não poderá vinculá-la a um perfil. No entanto, você pode anexar um perfil já existente a um cluster mesmo que esse perfil use a política defasada.
As políticas gerenciadas padrão de permissões completas do Amazon EMR incorporam configurações de segurança `iam:PassRole`, incluindo estas:
+ Permissões `iam:PassRole` somente para perfis padrão específicos do Amazon EMR.
+ `iam:PassedToService`condições que permitem que você use a política somente com AWS serviços específicos, como `elasticmapreduce.amazonaws.com` `ec2.amazonaws.com` e.
Você pode visualizar a versão JSON das políticas Amazon \$1v2 [EMRFullAccessPolicye [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2)](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) no console do IAM. É recomendável criar novos clusters com políticas gerenciadas v2.
Você pode ver o conteúdo da política v1 obsoleta no endereço. Console de gerenciamento da AWS [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonElasticMapReduceFullAccess) A ação `ec2:TerminateInstances` na política concede permissão a um usuário ou perfil para terminar qualquer uma das instâncias do Amazon EC2 associadas à conta do IAM. Inclui instâncias que não fazem parte de um cluster do EMR.
# Política gerenciada do IAM para acesso somente leitura (política gerenciada v2 padrão) do Amazon EMR
**Para conceder privilégios somente de leitura ao Amazon EMR, anexe a política gerenciada Amazon \$1v2. EMRRead OnlyAccessPolicy** Essa política gerenciada padrão substitui a política gerenciada [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md). O conteúdo dessa instrução de política é mostrado no trecho a seguir. Em comparação com a política `AmazonElasticMapReduceReadOnlyAccess`, a política `AmazonEMRReadOnlyAccessPolicy_v2` não usa caracteres curinga para o elemento `elasticmapreduce`. Em vez disso, a política v2 padrão define o escopo das ações `elasticmapreduce` que podem ser permitidas.
**nota**
Você também pode usar o Console de gerenciamento da AWS link [https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRReadOnlyAccessPolicy_v2)para ver a política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ElasticMapReduceActions",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:DescribeJobFlows",
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:DescribeReleaseLabel",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:GetManagedScalingPolicy",
"elasticmapreduce:GetAutoTerminationPolicy",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListSupportedInstanceTypes",
"elasticmapreduce:ViewEventsFromAllClustersInConsole"
],
"Resource": [
"*"
]
},
{
"Sid": "ViewMetricsInEMRConsole",
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
]
}
]
}
```
------
# Política gerenciada do IAM para acesso somente leitura (prestes a ser defasada)
A política gerenciada `AmazonElasticMapReduceReadOnlyAccess` está prestes a ser defasada. Não é possível anexar essa política ao iniciar novos clusters. `AmazonElasticMapReduceReadOnlyAccess` foi substituída pela política gerenciada [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) padrão do Amazon EMR. O conteúdo dessa instrução de política é mostrado no trecho a seguir. Caracteres curinga para o elemento `elasticmapreduce` especificam que somente as ações que comecem com as strings especificadas serão permitidas. Lembre-se de que, como essa política não nega explicitamente as ações, uma declaração de política diferente ainda pode ser usada para conceder acesso a ações específicas.
**nota**
Você também pode usar o Console de gerenciamento da AWS para visualizar a política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:Describe*",
"elasticmapreduce:List*",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"sdb:Select",
"cloudwatch:GetMetricStatistics"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribe"
}
]
}
```
------
# AWS política gerenciada: EMRDescribe ClusterPolicyFor EMRWAL
Não é possível anexar a `EMRDescribeClusterPolicyForEMRWAL` às entidades do IAM. Essa política é anexada a um perfil vinculado ao serviço que permite ao Amazon EMR realizar ações em seu nome. Para obter mais informações sobre esse perfil vinculado ao serviço, consulte [Uso de perfis vinculados ao serviço com o Amazon EMR para registro em log com gravação antecipada](using-service-linked-roles-wal.md).
Essa política concede permissões somente leitura que permitem que o serviço WAL do Amazon EMR encontre e retorne o status de um cluster. Para obter mais informações sobre o Amazon EMR WAL, consulte [Write-ahead logs (WAL) for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
**Detalhes de permissões**
Esta política inclui as seguintes permissões:
+ `emr`: permite que as entidades principais descrevam o status do cluster do Amazon EMR. Isso é necessário para que o Amazon EMR possa confirmar quando um cluster foi encerrado e, depois de trinta dias, limpar todos os logs do WAL deixados pelo cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribecluster"
}
]
}
```
------
## AWS políticas gerenciadas para o Amazon EMR
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns, para que você possa começar a atribuir permissões a usuários, grupos e funções.
Lembre-se de que as políticas AWS gerenciadas podem não conceder permissões de privilégio mínimo para seus casos de uso específicos porque elas estão disponíveis para uso de todos os AWS clientes. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso.
Você não pode alterar as permissões definidas nas políticas AWS gerenciadas. Se AWS atualizar as permissões definidas em uma política AWS gerenciada, a atualização afetará todas as identidades principais (usuários, grupos e funções) às quais a política está anexada. AWS é mais provável que atualize uma política AWS gerenciada quando uma nova AWS service (Serviço da AWS) é lançada ou novas operações de API são disponibilizadas para serviços existentes.
Para saber mais, consulte [AWS Políticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
# Atualizações do Amazon EMR para AWS políticas gerenciadas
Veja detalhes sobre as atualizações das políticas AWS gerenciadas do Amazon EMR desde que esse serviço começou a rastrear essas alterações.
| Alteração | Descrição | Data |
| --- | --- | --- |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): atualizar para uma política existente | Foram adicionados ec2:CreateVpcEndpoint, ec2:ModifyVpcEndpoint e ec2:CreateTags, necessárias para uma experiência ideal, começando com o Amazon EMR versão 7.5.0. | 4 de março de 2025 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – atualização para uma política existente | Foram adicionadas elasticmapreduce:CreatePersistentAppUI, elasticmapreduce:DescribePersistentAppUI e elasticmapreduce:GetPersistentAppUIPresignedURL. | 28 de fevereiro de 2025 |
| [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) – Nova política | Foi adicionada uma nova política para que o Amazon EMR possa determinar o status do cluster para limpeza do WAL trinta dias após o encerramento do cluster. | 10 de agosto de 2023 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) e [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md): atualizar para uma política já existente | Adicionadas elasticmapreduce:DescribeReleaseLabel e elasticmapreduce:GetAutoTerminationPolicy. | 21 de abril de 2022 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – atualização para uma política existente | Adicionou-se ec2:DescribeImages para [Uso de uma AMI personalizada para fornecer mais flexibilidade na configuração de clusters do Amazon EMR](emr-custom-ami.md). | 15 de fevereiro de 2022 |
| [**Políticas gerenciadas do Amazon EMR**](emr-managed-iam-policies.md) | Atualizado para esclarecer o uso de etiquetas de usuário predefinidas. Foi adicionada uma seção sobre como usar o AWS console para iniciar clusters com políticas gerenciadas v2. | 29 de setembro de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – atualização para uma política existente | Foram alteradas as ações PassRoleForAutoScaling e PassRoleForEC2 para usar o operador de condição StringLike para corresponder a "iam:PassedToService":"application-autoscaling.amazonaws.com\$1" e "iam:PassedToService":"ec2.amazonaws.com\$1", respectivamente. | 20 de maio de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – atualização para uma política existente | A ação inválida `s3:ListBuckets` foi removida e substituída pela ação `s3:ListAllMyBuckets`. Foi atualizada a criação do perfil vinculado ao serviço (SLR) para ser explicitamente reduzida ao único SLR que o Amazon EMR tem com princípios de serviço explícitos. Os SLRs que podem ser criados são exatamente os mesmos de antes dessa alteração. | 23 de março de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) – Nova política | O Amazon EMR adicionou novas permissões para definir o escopo do acesso aos recursos e adicionar o pré-requisito de que os usuários devem adicionar uma etiqueta de usuário predefinida aos recursos para poderem usar as políticas gerenciadas do Amazon EMR. A ação `iam:PassRole` requer uma condição `iam:PassedToService` definida para o serviço especificado. O acesso ao Amazon EC2, ao Amazon S3 e a outros serviços não é permitido por padrão. | 11 de março de 2021 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) – Nova política | Adiciona o pré-requisito de que os usuários devem adicionar etiquetas de usuário aos recursos para poderem usar essa política. | 11 de março de 2021 |
| [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) – Nova política | As permissões concedem somente ações específicas de leitura do elasticmapreduce. O acesso ao Amazon S3 é um acesso não concedido por padrão. | 11 de março de 2021 |
| O Amazon EMR passou a monitorar alterações | O Amazon EMR começou a monitorar as mudanças em suas políticas AWS gerenciadas. | 11 de março de 2021 |
# Políticas do IAM para acesso baseado em etiquetas a clusters e Cadernos do EMR
É possível aplicar condições em sua política baseada em identidade para controlar o acesso aos clusters e blocos de anotações do EMR baseados em tags.
Para obter mais informações sobre como adicionar tags a clusters, consulte [Marcar clusters do EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html).
Os exemplos a seguir demonstram diferentes cenários e maneiras de usar operadores de condição com chaves de condição do Amazon EMR. Estas instruções de política do IAM são destinadas somente para fins de demonstração e não devem ser usadas em ambientes de produção. Há várias maneiras de combinar declarações de políticas para conceder e negar permissões de acordo com seus requisitos. Para obter mais informações sobre como planejar e testar políticas do IAM, consulte o [Guia do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**Importante**
Recusar, explicitamente, permissões para ações de uso de tags é uma consideração importante. Isso evita que os usuários façam a marcação de um recurso e, assim, concedam a si mesmos permissões que você não pretendia conceder. Se você não negar as ações de marcação de um recurso, o usuário poderá modificar as etiquetas e contornar a intenção das políticas baseadas em etiquetas.
## Exemplo de instruções de políticas baseadas em identidade para clusters
Os exemplos a seguir demonstram a políticas de permissões baseadas em identidade que são usadas para controlar as ações permitidas com clusters do EMR.
**Importante**
A ação `ModifyInstanceGroup` do Amazon EMR não exige que você especifique um ID de cluster. Por isso, negar essa ação com base em etiquetas de cluster requer mais atenção. Para obter mais informações, consulte [Negando a ModifyInstanceGroup ação no Amazon EMR](emr-cluster-deny-modifyinstancegroup.md).
**Topics**
+ [Permitir ações somente em clusters com determinados valores de etiqueta](#emr-cluster-access-example-tagvalue)
+ [Exigir a marcação do cluster quando um cluster é criado](#emr-cluster-access-example-require-tagging)
+ [Permitir ações em clusters com uma etiqueta específica, independentemente do valor da etiqueta](#emr-cluster-access-example-tag)
### Permitir ações somente em clusters com determinados valores de etiqueta
Os exemplos a seguir demonstram uma política que permite ao usuário executar ações com base na etiqueta de cluster `department` com o valor `dev` e também permite que o usuário atribua etiquetas a clusters com a mesma etiqueta. O último exemplo de política demonstra como negar privilégios para atribuir tags a clusters do EMR com qualquer coisa, menos a mesma tag.
No exemplo de política a seguir, o operador de condição `StringEquals` tenta corresponder `dev` com o valor da tag `department`. Se a tag `department` ainda não tiver sido adicionada ao cluster ou não contiver o valor `dev`, a política não se aplicará e as ações não serão permitidas por essa política. Se nenhuma outra declaração de política permitir as ações, o usuário poderá somente trabalhar com clusters que tenham essa tag com esse valor.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt12345678901234",
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListSteps",
"elasticmapreduce:TerminateJobFlows",
"elasticmapreduce:SetTerminationProtection",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:DescribeStep"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
}
]
}
```
------
Você também pode especificar vários valores de tag usando um operador de condição. Por exemplo, para permitir todas as ações em clusters em que a tag `department` contenha o valor `dev` ou `test`, você poderia substituir o bloco condicional no exemplo anterior com o seguinte.
```
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department":["dev", "test"]
}
}
```
### Exigir a marcação do cluster quando um cluster é criado
Como no exemplo anterior, o exemplo de política a seguir procura a mesma etiqueta correspondente: o valor `dev` para a etiqueta `department`. Mas neste exemplo, a chave de condição `RequestTag` especifica que a política se aplica durante a criação da etiqueta. Portanto, é necessário criar um cluster com uma etiqueta que corresponda ao valor especificado.
Para criar um cluster com uma etiqueta, também é necessário ter permissão para a ação `elasticmapredue:AddTags`. Para essa instrução, a chave de condição `elasticmapreduce:ResourceTag` garante que o IAM conceda acesso somente aos recursos da etiqueta com o valor `dev` na etiqueta `department`. O elemento `Resource` é usado para limitar essa permissão aos recursos do cluster.
Para os `PassRole` recursos, você deve fornecer o ID ou alias da AWS conta, o nome da função de serviço na `PassRoleForEMR` declaração e o nome do perfil da instância na `PassRoleForEC2` declaração. Para obter mais informações sobre o formato ARN do IAM, consulte [IAM ARNs no Guia do](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *usuário do IAM*.
Para obter mais informações sobre a correspondência de valores de chave de etiqueta, consulte [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) no *Guia do usuário do IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunJobFlowExplicitlyWithTag",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/department": "dev"
}
}
},
{
"Sid": "AddTagsForDevClusters",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": "dev"
}
}
},
{
"Sid": "PassRoleForEMR",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
### Permitir ações em clusters com uma etiqueta específica, independentemente do valor da etiqueta
Você também pode permitir ações somente em clusters que tenham uma determinada tag, independentemente do valor da tag. Para fazer isso, você pode usar o operador `Null`. Para obter mais informações, consulte [Operador de condição para verificar a existência de chaves de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) no *Guia do usuário do IAM*. Por exemplo, para permitir ações somente em clusters do EMR que tenham a tag `department`, independentemente do valor que ela contenha, você poderia substituir o bloco condicional no exemplo anterior pelo seguinte. O operador `Null` procura a presença da tag `department` em um cluster do EMR. Se a tag existir, a instrução `Null` será avaliada como falsa, correspondendo à condição especificada nesta declaração de política e as ações apropriadas serão permitidas.
```
1. "Condition": {
2. "Null": {
3. "elasticmapreduce:ResourceTag/department":"false"
4. }
5. }
```
A declaração de política a seguir permite que um usuário crie um cluster do EMR somente se o cluster tiver uma tag `department`, que possa conter qualquer valor. Para o `PassRole` recurso, você precisa fornecer o ID ou alias da AWS conta e o nome da função de serviço. Para obter mais informações sobre o formato ARN do IAM, consulte [IAM ARNs no Guia do](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) *usuário do IAM*.
Para obter mais informações sobre como especificar o operador de condição nulo (“false”), consulte [Operador de condição para verificar a existência de chaves de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null) no *Guia do usuário do IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateClusterTagNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:RunJobFlow"
],
"Resource": [
"*"
],
"Condition": {
"Null": {
"aws:RequestTag/department": "false"
}
}
},
{
"Sid": "AddTagsNullCondition",
"Effect": "Allow",
"Action": [
"elasticmapreduce:AddTags"
],
"Resource": [
"arn:aws:elasticmapreduce:*:*:cluster/*"
],
"Condition": {
"Null": {
"elasticmapreduce:ResourceTag/department": "false"
}
}
},
{
"Sid": "PassRoleForElasticMapReduce",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "elasticmapreduce.amazonaws.com*"
}
}
},
{
"Sid": "PassRoleForEC2",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Role-Name-With-Path"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ec2.amazonaws.com*"
}
}
}
]
}
```
------
## Exemplo de instruções de políticas baseadas em identidade para Cadernos do EMR
Os exemplos de instruções de políticas do IAM nesta seção demonstram cenários comuns para usar chaves a fim de limitar as ações permitidas usando Cadernos do EMR. Desde que nenhuma outra política associada à entidade principal (usuário) permita as ações, as chaves de contexto de condição limitam as ações permitidas conforme indicado.
**Example : permitir acesso somente aos Cadernos do EMR que o usuário cria com base na marcação**
A instrução de política de exemplo a seguir, quando anexada a um perfil ou usuário, permite que o usuário trabalhe apenas com cadernos criados por ele. Esta declaração de política usa a tag padrão aplicada quando um bloco de anotações é criado.
No exemplo, o operador de condição `StringEquals` tenta combinar uma variável que representa o ID do usuário atual (`{aws:userId}`) com o valor de etiqueta `creatorUserID`. Se a tag `creatorUserID` ainda não tiver sido adicionada ao bloco de anotações ou não contiver o valor do ID do usuário atual, a política não se aplicará e as ações não serão permitidas por essa política. Se nenhuma outra declaração de política permitir as ações, o usuário só poderá trabalhar com blocos de anotações que tenham essa tag com esse valor.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:StartEditor",
"elasticmapreduce:StopEditor",
"elasticmapreduce:DeleteEditor",
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/creatorUserId": "${aws:userId}"
}
},
"Sid": "AllowELASTICMAPREDUCEDescribeeditor"
}
]
}
```
**Example –Exigir marcação de caderno quando um caderno é criado**
Neste exemplo, a chave de contexto `RequestTag` é usada. A ação `CreateEditor` será permitida somente se o usuário não alterar nem excluir a tag `creatorUserID` é que é adicionada por padrão. A variável \$1\$1aws:userId\$1 especifica o ID de usuário do usuário atualmente ativo, que é o valor padrão da etiqueta.
A declaração de política pode ser usada para ajudar a garantir que os usuários não removam a tag `createUserId` tag nem alterem seu valor.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
Este exemplo requer que o usuário crie o cluster com uma tag com a string de chave `dept` e um valor definido como um dos seguintes: `datascience`, `analytics`, `operations`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/dept": [
"datascience",
"analytics",
"operations"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example –Limitar a criação do caderno para clusters marcados e exigir etiquetas de caderno**
Este exemplo permite a criação do bloco de anotações somente se o bloco de anotações for criado com uma tag que tenha a string de chave `owner` definida como um dos valores especificados. Além disso, o bloco de anotações poderá ser criado somente se o cluster tiver uma tag com a string de chave `department` definida como um dos valores especificados.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/owner": [
"owner1",
"owner2",
"owner3"
],
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
**Example –Limitar a capacidade de iniciar um caderno com base em etiquetas**
Este exemplo limita a capacidade de iniciar blocos de anotações àqueles que tenham uma tag com a string de chave `owner` definida como um dos valores especificados. Como o elemento `Resource` é usado para especificar apenas o `editor`, a condição não se aplica ao cluster e não precisa ser marcado.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"owner1",
"owner2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
Este exemplo é semelhante ao exposto acima. No entanto, o limite se aplica apenas a clusters com tags, e não a blocos de anotações.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"dep1",
"dep3"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditor"
}
]
}
```
Este exemplo usa um conjunto diferente de tags de cluster e bloco de anotações. Ele permite que um bloco de anotações seja iniciado somente se:
+ O bloco de anotações tiver uma tag com a string de chave `owner` definida como qualquer um dos valores especificados
—e—
+ O cluster tiver uma tag com a string de chave `department` definida como qualquer um dos valores especificados
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByOwner"
},
{
"Action": [
"elasticmapreduce:StartEditor"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEStarteditorByDepartment"
}
]
}
```
**Example –Limitar a capacidade de abrir o editor de caderno com base em etiquetas**
Este exemplo permite que o editor de blocos de anotações seja aberto somente se:
+ O bloco de anotações tiver uma tag com a string de chave `owner` definida como qualquer um dos valores especificados.
—e—
+ O cluster tiver uma tag com a string de chave `department` definida como qualquer um dos valores especificados.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:editor/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/owner": [
"user1",
"user2"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByOwner"
},
{
"Action": [
"elasticmapreduce:OpenEditorInConsole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department": [
"datascience",
"analytics"
]
}
},
"Sid": "AllowELASTICMAPREDUCEOpeneditorconsoleByDepartment"
}
]
}
```
# Negando a ModifyInstanceGroup ação no Amazon EMR
A [ModifyInstanceGroups](https://docs.aws.amazon.com/emr/latest/APIReference/API_ModifyInstanceGroups.html)ação no Amazon EMR não exige que você forneça um ID de cluster com a ação. Em vez disso, você pode especificar apenas um ID de grupo de instâncias. Por isso, uma política de negação aparentemente simples para essa ação com base no ID do cluster ou em uma etiqueta do cluster pode não ter o efeito pretendido. Considere a seguinte política de exemplo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroups"
}
]
}
```
------
Se um usuário com essa política anexada realizar uma ação `ModifyInstanceGroup` e especificar somente o ID do grupo de instâncias, a política não se aplicará. Como a ação é permitida em todos os outros recursos, ela tem êxito.
Uma solução para esse problema é anexar uma declaração de política à identidade que usa um [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html)elemento para negar qualquer `ModifyInstanceGroup` ação emitida sem um ID de cluster. O exemplo de política a seguir adiciona essa instrução de negação para que qualquer solicitação `ModifyInstanceGroups` falhe, a menos que um ID de cluster esteja especificado. Como uma identidade deve especificar um ID de cluster com a ação, as instruções de negação com base no ID do cluster são, portanto, efetivas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-12345ABCDEFG67"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsSpecificCluster"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Deny",
"NotResource": "arn:*:elasticmapreduce:*:*:cluster/*",
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNonCluster"
}
]
}
```
------
Um problema semelhante ocorre quando você deseja negar a ação `ModifyInstanceGroups` com base no valor associado a uma etiqueta de cluster. A solução é semelhante. Além de uma instrução de negação que especifica o valor da etiqueta, é possível adicionar uma instrução de política que nega a ação `ModifyInstanceGroup` se a etiqueta especificada não estiver presente, qualquer que seja o valor.
O exemplo a seguir demonstra uma política que, quando anexada a uma identidade, nega à identidade a ação `ModifyInstanceGroups` de qualquer cluster com a etiqueta `department` definida como `dev`. Essa instrução só é efetiva por causa da instrução de negação que usa a condição `StringNotLike` para negar a ação, a menos que a etiqueta `department` esteja presente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEModifyinstancegroups"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsDevDepartment"
},
{
"Action": [
"elasticmapreduce:ModifyInstanceGroups"
],
"Condition": {
"StringNotLike": {
"aws:ResourceTag/department": "?*"
}
},
"Effect": "Deny",
"Resource": [
"*"
],
"Sid": "DenyELASTICMAPREDUCEModifyinstancegroupsNoDepartmentTag"
}
]
}
```
------
# Solução de problemas de identidade e acesso da Amazon EMR
Use as informações a seguir para ajudar a diagnosticar e corrigir problemas comuns que você pode encontrar ao trabalhar com o Amazon EMR e o IAM.
**Topics**
+ [Não tenho autorização para executar uma ação no Amazon EMR](#security_iam_troubleshoot-no-permissions)
+ [Não estou autorizado a realizar iam: PassRole](#security_iam_troubleshoot-passrole)
+ [Quero permitir que pessoas fora da minha AWS conta acessem meus recursos do Amazon EMR](#security_iam_troubleshoot-cross-account-access)
## Não tenho autorização para executar uma ação no Amazon EMR
Se isso Console de gerenciamento da AWS indicar que você não está autorizado a realizar uma ação, entre em contato com o administrador para obter ajuda. O administrador é a pessoa que forneceu o seu nome de usuário e senha.
O erro do exemplo a seguir ocorre quando o usuário `mateojackson` tenta usar o console para visualizar detalhes sobre um recurso do `my-example-widget` fictício, mas não tem as permissões fictícias do `EMR:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: EMR:GetWidget on resource: my-example-widget
```
Neste caso, Mateo pede ao administrador para atualizar suas políticas e permitir o acesso ao recurso `my-example-widget` usando a ação `EMR:GetWidget`.
## Não estou autorizado a realizar iam: PassRole
Caso receba uma mensagem de erro informando que você não tem autorização para executar a ação `iam:PassRole`, as políticas deverão ser atualizadas para permitir a transmissão de um perfil ao Amazon EMR.
Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço.
O erro exemplificado a seguir ocorre quando uma usuária do IAM chamada `marymajor` tenta usar o console para executar uma ação no Amazon EMR. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`.
Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login.
## Quero permitir que pessoas fora da minha AWS conta acessem meus recursos do Amazon EMR
É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos.
Para saber mais, consulte:
+ Para saber se o Amazon EMR é compatível com esses recursos, consulte [Como o Amazon EMR funciona com o IAM](security_iam_service-with-iam.md).
+ Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*.
+ Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*.
+ Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*.
+ Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
# Uso do Amazon S3 Access Grants com o Amazon EMR
## Visão geral do S3 Access Grants para o Amazon EMR
Com as versões 6.15.0 e superiores do Amazon EMR, o Amazon S3 Access Grants fornece uma solução de controle de acesso escalável que você pode usar para aumentar o acesso aos dados do Amazon S3 por meio do Amazon EMR. Se você tiver uma configuração de permissão complexa ou grande para os dados do S3, poderá usar a funcionalidade Access Grants para escalar as permissões de dados do S3 para usuários, perfis e aplicações no seu cluster.
Use o S3 Access Grants para aumentar o acesso aos dados do Amazon S3 além das permissões concedidas pelo perfil de runtime ou pelos perfis do IAM anexados às identidades com acesso ao seu cluster do EMR. Para obter mais informações, consulte [Gerenciar o acesso com o S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) no *Guia do usuário do Amazon S3*.
Para ver as etapas de uso do S3 Access Grants com outras implantações do Amazon EMR, consulte a seguinte documentação:
+ [Using S3 Access Grants with Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Using S3 Access Grants with Amazon EMR Sem Servidor](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
## Como o Amazon EMR funciona com o S3 Access Grants
O Amazon EMR 6.15.0 e versões superiores oferecem uma integração nativa com o S3 Access Grants. Você pode habilitar o S3 Access Grants no Amazon EMR e executar trabalhos do Spark. Quando um trabalho do Spark faz uma solicitação de dados do S3, o Amazon S3 fornece credenciais temporárias que têm como escopo o bucket, prefixo ou objeto específico.
Veja a seguir uma visão geral de alto nível sobre como o Amazon EMR obtém acesso aos dados protegidos pela funcionalidade Access Grants do S3.
![\[Como o Amazon EMR funciona com o S3 Access Grants\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/access-grants-overview.png)
1. Um usuário envia um trabalho do Spark do Amazon EMR que usa dados armazenados no Amazon S3.
1. O Amazon EMR solicita ao S3 Access Grants que permita o acesso ao bucket, prefixo ou objeto em nome desse usuário.
1. O Amazon S3 retorna credenciais temporárias na forma de um token AWS Security Token Service (STS) para o usuário. O escopo do token é acessar o bucket, prefixo ou objeto do S3.
1. O Amazon EMR usa o token do STS para recuperar dados do S3.
1. O Amazon EMR recebe os dados do S3 e retorna os resultados ao usuário.
## Considerações sobre o S3 Access Grants com o Amazon EMR
Observe os comportamentos e as limitações a seguir ao usar o S3 Access Grants com o Amazon EMR.
### Suporte a recursos
+ O S3 Access Grants é compatível com as versões 6.15.0 e superiores do Amazon EMR.
+ O Spark é o único mecanismo de consulta compatível ao usar o S3 Access Grants com o Amazon EMR.
+ Delta Lake e Hudi são os únicos formatos de tabela aberta compatíveis ao usar o S3 Access Grants com o Amazon EMR.
+ Os seguintes recursos do Amazon EMR não são compatíveis com o S3 Access Grants:
+ tabelas do Apache Iceberg
+ Autenticação nativa LDAP
+ Autenticação nativa do Apache Ranger
+ AWS CLI solicitações para o Amazon S3 que usam funções do IAM
+ Acesso ao S3 por meio do protocolo de código aberto do S3A
+ A opção `fallbackToIAM` não é compatível com clusters do EMR que usam a propagação de identidade confiável com o Centro de Identidade do IAM.
+ O [S3 Access Grants com o AWS Lake Formation](#emr-access-grants-lf) só é compatível com clusters do Amazon EMR executados no Amazon EC2.
### Considerações comportamentais
+ A integração nativa do Apache Ranger com o Amazon EMR possui funcionalidade congruente com o S3 Access Grants como parte do plug-in EMRFS S3 do Apache Ranger. Se você usa o Apache Ranger para controle de acesso refinado (FGAC), recomendamos usar esse plug-in em vez do S3 Access Grants.
+ O Amazon EMR fornece um cache de credenciais no EMRFS para garantir que o usuário não precise fazer solicitações repetidas das mesmas credenciais em um trabalho do Spark. Portanto, o Amazon EMR sempre solicita o privilégio de nível padrão quando solicita credenciais. Para obter mais informações, consulte [Solicitação de acesso aos dados do S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants-credentials.html) no *Guia do usuário do Amazon S3*.
+ No caso de um usuário realizar uma ação que não tenha suporte do S3 Access Grants, o Amazon EMR está configurado para usar o perfil do IAM que foi especificado para a execução do trabalho. Para obter mais informações, consulte [Fallback para os perfis do IAM](#emr-access-grants-fallback).
## Launch an Amazon EMR cluster with S3 Access Grants
Esta seção descreve como iniciar um cluster do EMR que é executado no Amazon EC2 e usa o S3 Access Grants para gerenciar o acesso aos dados no Amazon S3. Para ver as etapas de uso do S3 Access Grants com outras implantações do Amazon EMR, consulte a seguinte documentação:
+ [Using S3 Access Grants with Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Using S3 Access Grants with EMR Sem Servidor ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
Use as etapas a seguir para iniciar um cluster do EMR que é executado no Amazon EC2 e usa o S3 Access Grants para gerenciar o acesso aos dados no Amazon S3.
1. Configure um perfil de execução de trabalhos para o cluster do EMR. Inclua as permissões do IAM necessárias para executar os trabalhos do Spark, `s3:GetDataAccess` e `s3:GetAccessGrantsInstanceForPrefix`:
```
{
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": [ //LIST ALL INSTANCE ARNS THAT THE ROLE IS ALLOWED TO QUERY
"arn:aws_partition:s3:Region:account-id1:access-grants/default",
"arn:aws_partition:s3:Region:account-id2:access-grants/default"
]
}
```
**nota**
Com o Amazon EMR, a funcionalidade S3 Access Grants aumenta as permissões definidas nos perfis do IAM. Se os perfis do IAM especificados para a execução do trabalho contiverem permissões de acesso direto ao S3, os usuários poderão acessar mais dados do que os definidos por você no S3 Access Grants.
1. Em seguida, use o AWS CLI para criar um cluster com o Amazon EMR 6.15 ou superior e a `emrfs-site` classificação para habilitar o S3 Access Grants, semelhante ao exemplo a seguir:
```
aws emr create-cluster
--release-label emr-6.15.0 \
--instance-count 3 \
--instance-type m5.xlarge \
--configurations '[{"Classification":"emrfs-site", "Properties":{"fs.s3.s3AccessGrants.enabled":"true", "fs.s3.s3AccessGrants.fallbackToIAM":"false"}}]'
```
## Concessões de acesso ao S3 com AWS Lake Formation
Se você usa o Amazon EMR com a [integração do AWS Lake Formation](emr-lake-formation.md), poderá utilizar o Amazon S3 Access Grants para acesso direto ou tabular aos dados no Amazon S3.
**nota**
O S3 Access Grants with só AWS Lake Formation é compatível com clusters do Amazon EMR que são executados no Amazon EC2.
**Acesso direto**
O acesso direto envolve todas as chamadas para acessar dados do S3 que não invocam a API do serviço AWS Glue que a Lake Formation usa como metastore com o Amazon EMR, por exemplo, para chamar: `spark.read`
```
spark.read.csv("s3://...")
```
Quando você usa o S3 Access Grants AWS Lake Formation no Amazon EMR, todos os padrões de acesso direto passam pelo S3 Access Grants para obter credenciais temporárias do S3.
**Acesso tabular**
O acesso tabular ocorre quando o Lake Formation invoca a API do metastore para acessar sua localização no S3, por exemplo, para consultar dados da tabela:
```
spark.sql("select * from test_tbl")
```
Quando você usa o S3 Access Grants AWS Lake Formation no Amazon EMR, todos os padrões de acesso tabulares passam pelo Lake Formation.
## Fallback para os perfis do IAM
Se um usuário tentar realizar uma ação que não tenha o suporte do S3 Access Grants, o Amazon EMR usa como padrão o perfil do IAM que foi especificado para a execução do trabalho quando a configuração `fallbackToIAM` for `true`. Isso permite que os usuários efetuem o fallback do perfil de execução de trabalhos para fornecer credenciais de acesso ao S3 em cenários não cobertos pelo S3 Access Grants.
Com a opção `fallbackToIAM` habilitada, os usuários podem acessar os dados que o Access Grant permite. Se não houver um token do S3 Access Grants para os dados de destino, o Amazon EMR verifica a permissão no perfil de execução de trabalhos.
**nota**
Recomendamos que você teste suas permissões de acesso com a configuração `fallbackToIAM` habilitada, mesmo que planeje desabilitar a opção para workloads de produção. Com os trabalhos do Spark, há outras maneiras pelas quais os usuários podem acessar todos os conjuntos de permissões com as credenciais do IAM. Quando habilitadas em clusters do EMR, as concessões do S3 dão aos trabalhos do Spark acesso às localizações do S3. Você deve garantir a proteção dessas localizações do S3 contra o acesso fora do EMRFS. Por exemplo, você deve proteger as localizações do S3 contra o acesso de clientes do S3 usados em notebooks ou por aplicações sem o suporte do S3 Access Grants, como Hive ou Presto.
# Autenticação em nós de cluster do Amazon EMR
Os clientes SSH podem usar um par de chaves do Amazon EC2 para autenticar-se em instâncias de cluster. Como alternativa, com o Amazon EMR 5.10.0 ou versões posteriores, você pode configurar o Kerberos para autenticar usuários e conexões SSH para o nó primário. E com o Amazon EMR 5.12.0 e versões posteriores, você pode se autenticar com o LDAP.
**Topics**
+ [Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR](emr-plan-access-ssh.md)
+ [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md)
+ [Usar servidores Active Directory ou LDAP para autenticação com o Amazon EMR](ldap.md)
# Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR
Os nós de cluster do Amazon EMR são executados em instâncias do Amazon EC2. É possível se conectar a nós de cluster da mesma forma que você se conecta a instâncias do Amazon EC2. Você pode usar o Amazon EC2 para criar um par de chaves ou você pode importar um par de chaves. Ao criar um cluster, é possível especificar o par de chaves do Amazon EC2 que será usado nas conexões SSH para todas as instâncias de cluster. Também é possível criar um cluster sem par de chaves. Isso geralmente é feito com clusters transitórios que são iniciados, executam etapas e são encerrados automaticamente.
O cliente SSH que você usa para se conectar ao cluster precisa usar o arquivo de chave privada associado ao par de chaves. Esse é um arquivo .pem para clientes SSH que usam Linux, Unix e macOS. Você deve definir permissões para que apenas o proprietário da chave tenha permissão para acessar o arquivo. É um arquivo .ppk para clientes SSH que usam o Windows, e o arquivo .ppk geralmente é criado a partir do arquivo .pem.
+ Para obter mais informações sobre a criação de pares de chaves do Amazon EC2, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
+ *Para obter instruções sobre como usar o Pu TTYgen para criar um arquivo.ppk a partir de um arquivo.pem, consulte [Convertendo sua chave privada usando o Pu no Guia do usuário do TTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) Amazon EC2.*
+ Para obter mais informações sobre como definir permissões de arquivos.pem e como se conectar ao nó primário de um cluster do EMR usando métodos diferentes, inclusive do `ssh` Linux ou macOS, do PuTTY do Windows ou AWS CLI de qualquer sistema operacional compatível, consulte. [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md)
# Usar o Kerberos para autenticação com o Amazon EMR
O Amazon EMR 5.10.0 e versões posteriores oferecem suporte ao Kerberos. O Kerberos é um protocolo de autenticação de rede que usa criptografia segredo-chave para fornecer autenticação forte, de maneira que senhas ou outras credenciais não sejam enviadas pela rede em um formato não criptografado.
No Kerberos, os serviços e os usuários que precisam se autenticar são conhecidos como *entidades principais*. As entidades principais existem em um *realm* Kerberos. Dentro do realm, um servidor Kerberos conhecido como *Key Distribution Center (KDC)* oferece as entidades principais se autenticarem. O KDC faz isso emitindo *tíquetes* para autenticação. O KDC mantém um banco de dados das entidades principais no realm, as senhas e outras informações administrativas sobre cada entidade principal. Um KDC também pode aceitar credenciais de autenticação de entidades principais em outros realms, o que é conhecido como uma *relação de confiança entre realms*. Além disso, um cluster do EMR pode usar um KDC externo para autenticar principais.
Um cenário comum para estabelecer uma relação de confiança entre realms ou usar um KDC externo é autenticar usuários de um domínio do Active Directory. Isso permite que os usuários acessem um cluster do EMR com a conta do domínio quando eles usarem o SSH para se conectar a um cluster ou trabalhar com aplicações de big data.
Quando você usa autenticação do Kerberos, o Amazon EMR configura o Kerberos para as aplicações, os componentes e os subsistemas que ele instala no cluster, de maneira que eles sejam autenticados entre si.
**Importante**
O Amazon EMR não oferece suporte AWS Directory Service for Microsoft Active Directory em uma relação de confiança entre regiões ou como um KDC externo.
Antes de configurar o Kerberos usando o Amazon EMR, recomendamos que você se familiarize com os conceitos do Kerberos, os serviços executados em um KDC e as ferramentas para administrar serviços do Kerberos. Para obter mais informações, consulte a [documentação do MIT Kerberos](http://web.mit.edu/kerberos/krb5-latest/doc/), publicada pelo [Kerberos Consortium](http://kerberos.org/).
**Topics**
+ [Aplicações compatíveis com o Amazon EMR](emr-kerberos-principals.md)
+ [Opções de arquitetura do Kerberos com o Amazon EMR](emr-kerberos-options.md)
+ [Configurar o Kerberos no Amazon EMR](emr-kerberos-configure.md)
+ [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: configurar um KDC dedicado ao cluster com o Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md)
# Aplicações compatíveis com o Amazon EMR
Em um cluster do EMR, as entidades principais do Kerberos são os serviços de aplicações de big data e os subsistemas executados em todos os nós de cluster. O Amazon EMR pode configurar as aplicações e os componentes listados abaixo para usar o Kerberos. Cada aplicativo tem uma entidade principal de usuário Kerberos associada.
O Amazon EMR não oferece suporte a relações de confiança entre realms com AWS Directory Service for Microsoft Active Directory.
O Amazon EMR somente configura os recursos de autenticação do Kerberos de código aberto para as aplicações e os componentes listados abaixo. Todos os outros aplicativos instalados não são Kerberizados, o que pode resultar em uma incapacidade de se comunicar com componentes Kerberizados e causar erros de aplicativo. Os aplicativos e os componentes não Kerberizados não têm autenticação ativada. As aplicações e componentes compatíveis podem variar conforme as diferentes versões do Amazon EMR.
A interface de usuário do Livy é a única interface de usuário da Web hospedada no cluster que é kerberizada.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ Não habilite o Hive com autenticação LDAP. Isso pode causar problemas na comunicação com o YARN Kerberizado.
+ **Hue**
+ A autenticação de usuário do Hue não é definida automaticamente e pode ser configurada usando-se a API de configuração.
+ O servidor do Hue é Kerberizado. O front-end (UI) do Hue não está configurado para autenticação. A autenticação LDAP pode ser configurada para o Hue UI.
+ **Livy**
+ A representação do Livy com clusters kerberizados é compatível com as versões 5.22.0 e posteriores do Amazon EMR.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ O Presto oferece suporte à autenticação Kerberos no Amazon EMR 6.9.0 e versões posteriores.
+ Para usar a autenticação Kerberos com o Presto, é necessário habilitar a [criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ O Trino oferece suporte à autenticação Kerberos no Amazon EMR 6.11.0 e versões posteriores.
+ Para usar a autenticação Kerberos com o Trino, é necessário habilitar a [criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ O Zeppelin é configurado somente para usar o Kerberos com o intérprete do Spark. Ele não é configurado para outros intérpretes.
+ A representação de usuário não oferece suporte a intérpretes kerberizados do Zeppelin além do Spark.
+ **Zookeeper**
+ O cliente do Zookeeper não é compatível.
# Opções de arquitetura do Kerberos com o Amazon EMR
Ao usar o Kerberos com o Amazon EMR, você pode escolher entre as arquiteturas listadas nesta seção. Independentemente da arquitetura que escolhida, você pode configurar o Kerberos usando as mesmas etapas. Você cria uma configuração de segurança, especifica a configuração de segurança do Kerberos e as opções específicas do cluster compatíveis ao criar o cluster, e você cria diretórios do HDFS para usuários do Linux no cluster que correspondam aos usuários principais no KDC. Para obter uma explicação sobre as opções de configuração e configurações de exemplo para cada arquitetura, consulte [Configurar o Kerberos no Amazon EMR](emr-kerberos-configure.md).
## KDC dedicado ao cluster (KDC no nó primário)
Essa configuração está disponível no Amazon EMR 5.10.0 e versões posteriores.
![\[Amazon EMRcluster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Vantagens**
+ O Amazon EMR tem total propriedade do KDC.
+ O KDC no cluster do EMR é independente das implementações centralizadas do KDC, como o Microsoft Active Directory ou o AWS Managed Microsoft AD.
+ O impacto no desempenho é mínimo porque o KDC gerencia a autenticação somente para nós locais no cluster.
+ Opcionalmente, outros clusters Kerberizados pode fazer referência ao KDC como um KDC externo. Para obter mais informações, consulte [KDC externo: nó primário em um cluster diferente](#emr-kerberos-extkdc-cluster-summary).
**Considerações e limitações**
+ Os clusters Kerberizados não podem autenticar uns ao outros, portanto, os aplicativos não podem interoperar. Se os aplicativos de cluster precisarem interoperar, você deverá estabelecer uma relação de confiança entre realms entre os clusters, ou configurar um cluster como o KDC externo para outros clusters. Se uma relação de confiança entre reinos for estabelecida, eles KDCs devem ter reinos Kerberos diferentes.
+ Você deve criar usuários do Linux na instância do EC2 do nó primário que correspondam aos usuários principais do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar ao cluster usando SSH.
## Relação de confiança entre realms
Nessa configuração, os principais (normalmente usuários) de um realm do Kerberos diferente autenticam componentes do aplicativo em um cluster do EMR Kerberizado, que tem seu próprio KDC. O KDC no nó primário estabelece uma relação de confiança com outro KDC usando um *principal entre domínios que existe em ambos*. KDCs O nome do principal e a senha coincidem precisamente em cada KDC. Relações de confianças entre realms são mais comuns com implementações do Active Directory, conforme mostrado no diagrama a seguir. Relações de confiança entre realms com um MIT KDC externo ou um KDC em outro cluster do Amazon EMR também são compatíveis.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Vantagens**
+ O cluster do EMR no qual o KDC está instalado mantém a total propriedade do KDC.
+ Com o Active Directory, o Amazon EMR cria automaticamente usuários do Linux que correspondam aos usuários principais do KDC. Ainda assim é necessário criar diretórios do HDFS para cada usuário. Além disso, os usuário principais no domínio do Active Directory podem acessar clusters Kerberizados usando credenciais `kinit`, sem o arquivo de chave privada do EC2. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.
+ Como cada cluster do KDC gerencia a autenticação para os nós no cluster, os efeitos da latência da rede e da sobrecarga de processamento para um grande número de nós nos clusters é minimizado.
**Considerações e limitações**
+ Se estiver estabelecendo uma relação de confiança com um domínio do Active Directory, você deverá fornecer um nome de usuário e senha do Active Directory com permissões para se juntar aos principais do domínio ao criar o cluster.
+ As relações de confiança entre realms não podem ser estabelecidas entre realms do Kerberos com o mesmo nome.
+ As relações de confiança entre realms deve ser estabelecidas explicitamente. Por exemplo, se o Cluster A e o Cluster B estabelecerem uma relação de confiança entre realms com um KDC, eles não confiarão inerentemente um no outro e seus aplicativos não poderão se autenticar entre si para interoperar.
+ KDCs devem ser mantidas de forma independente e coordenada para que as credenciais dos usuários principais correspondam com precisão.
## KDC externo
Configurações com um KDC externo são compatíveis com o Amazon EMR 5.20.0 e posteriores.
+ [KDC externo: MIT KDC](#emr-kerberos-extkdc-mit-summary)
+ [KDC externo: nó primário em um cluster diferente](#emr-kerberos-extkdc-cluster-summary)
+ [KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC externo: MIT KDC
Essa configuração permite que um ou mais clusters do EMR usem principais definidos e mantidos em um servidor KDC MIT.
![\[Amazon EMRcluster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado em um único KDC.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
+ O nó primário em um cluster kerberizado não tem o ônus da performance associada com a manutenção do KDC.
**Considerações e limitações**
+ Você deve criar usuários do Linux na instância do EC2 de cada nó primário do cluster kerberizado que corresponda às entidades principais de usuário do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar aos clusters Kerberizados usando SSH.
+ Cada nó nos clusters do EMR Kerberizados deve ter uma rota de rede para o KDC.
+ Cada nó nos clusters Kerberizados coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta o desempenho do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters Kerberizados e no KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
### KDC externo: nó primário em um cluster diferente
Essa configuração é quase idêntica à implementação do MIT KDC externo acima, porém o KDC está no nó primário de um cluster do EMR. Para obter mais informações, consulte [KDC dedicado ao cluster (KDC no nó primário)](#emr-kerberos-localkdc-summary) e [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md).
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado em um único KDC.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
**Considerações e limitações**
+ Você deve criar usuários do Linux na instância do EC2 de cada nó primário do cluster kerberizado que corresponda às entidades principais de usuário do KDC, juntamente com os diretórios do HDFS para cada usuário.
+ Os usuários principais devem usar um arquivo de chave privada do EC2 e credenciais `kinit` para se conectar aos clusters Kerberizados usando SSH.
+ Cada nó nos clusters do EMR deve ter uma rota de rede para o KDC.
+ Cada nó do Amazon EMR nos clusters kerberizados coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta a performance do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters e no KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
### KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory
Nessa configuração, você primeiro cria um cluster com um KDC dedicado ao cluster que tenha uma relação de confiança entre realms unidirecional com o Active Directory. Para ver um tutorial detalhado, consulte [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md). Em seguida, inicie clusters adicionais, fazendo referência ao KDC do cluster que tem a confiança como um KDC externo. Para ver um exemplo, consulte [KDC externo do cluster com relação de confiança entre realms do Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). Isso permite que cada cluster do Amazon EMR que usa o KDC externo autentique as entidades principais definidas e mantidas em um domínio do Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Vantagens**
+ O gerenciamento de principais é consolidado no domínio do Active Directory.
+ O Amazon EMR ingressa no realm do Active Directory, o que elimina a necessidade de criar usuários do Linux que correspondam aos usuários do Active Directory. Ainda assim é necessário criar diretórios do HDFS para cada usuário.
+ Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. Para obter mais informações, consulte [Requisitos para usar múltiplos clusters com o mesmo KDC](#emr-kerberos-multi-kdc).
+ Os usuário principais no domínio do Active Directory podem acessar clusters Kerberizados usando credenciais `kinit`, sem o arquivo de chave privada do EC2. Isso elimina a necessidade de compartilhar o arquivo de chave privada entre os usuários do cluster.
+ Somente um nó primário do Amazon EMR tem a carga para manter o KDC, e somente esse cluster deve ser criado com as credenciais do Active Directory para a relação de confiança entre realms entre o KDC e o Active Directory.
**Considerações e limitações**
+ Cada nó nos clusters do EMR deve ter uma rota de rede para o KDC e o controlador de domínio do Active Directory.
+ Cada nó do Amazon EMR coloca uma carga de autenticação no KDC externo, portanto, a configuração do KDC afeta a performance do cluster. Ao configurar o hardware do servidor KDC, considere o suporte simultâneo ao número máximo de nós do Amazon EMR.
+ O desempenho do cluster depende da latência da rede entre os nós nos clusters e no servidor KDC.
+ A solução de problemas pode ser mais difícil devido a interdependências.
## Requisitos para usar múltiplos clusters com o mesmo KDC
Vários clusters podem usar o mesmo KDC no mesmo realm do Kerberos. No entanto, se os clusters forem executados simultaneamente, eles poderão falhar se usarem ServicePrincipal nomes Kerberos conflitantes.
Se você tiver múltiplos clusters simultâneos com o mesmo KDC externo, certifique-se de que os clusters usem regiões Kerberos diferentes. Se os clusters precisarem usar o mesmo realm do Kerberos, certifique-se de que os clusters estejam em sub-redes diferentes e que os intervalos de CIDR não se sobreponham.
# Configurar o Kerberos no Amazon EMR
Esta seção fornece detalhes da configuração e exemplos para configurar o Kerberos com arquiteturas comuns. Independentemente da arquitetura escolhida, as noções básicas de configuração são as mesmas e a configuração é feita em três etapas. Se usar um KDC externo ou configurar uma relação de confiança entre realms, você deverá garantir que cada nó em um cluster tenha uma rota de rede para o KDC externo, incluindo a configuração aplicável de grupos de segurança para permitir o tráfego de entrada e saída do Kerberos.
## Etapa 1: Criar uma configuração de segurança com propriedades do Kerberos
A configuração de segurança especifica detalhes sobre o KDC do Kerberos e permite que a configuração do Kerberos seja reutilizada cada vez que você criar um cluster. Você pode criar uma configuração de segurança usando o console do Amazon EMR AWS CLI, o ou a API do EMR. A configuração de segurança também pode conter outras opções de segurança, como criptografia. Para obter mais informações sobre como criar configurações de segurança e especificar uma configuração de segurança ao criar um cluster, consulte [Uso de configurações de segurança para definir a segurança do cluster do Amazon EMR](emr-security-configurations.md). Para obter informações sobre as propriedades do Kerberos em uma configuração de segurança, consulte [Configurações do Kerberos para configurações de segurança](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Etapa 2: Criar um cluster e especificar os atributos do Kerberos específicos do cluster
Ao criar um cluster, você especifica uma configuração de segurança do Kerberos juntamente com e as opções do Kerberos específicas do cluster. Quando o console do Amazon EMR é usado, somente as opções do Kerberos compatíveis com a configuração de segurança especificada estão disponíveis. Ao usar a API AWS CLI ou o Amazon EMR, certifique-se de especificar as opções do Kerberos compatíveis com a configuração de segurança especificada. Por exemplo, se você especificar uma senha principal para uma relação de confiança entre realms ao criar um cluster usando a CLI e a configuração de segurança especificada não for configurada com os parâmetros da relação de confiança entre realms, ocorrerá um erro. Para obter mais informações, consulte [Configurações do Kerberos para clusters](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Etapa 3: configurar o nó primário do cluster
Dependendo dos requisitos de sua arquitetura e implantação, configuração adicional no cluster pode ser necessária. Você pode fazer isso depois de criá-lo ou usando etapas ou ações de bootstrap durante o processo de criação.
Para cada usuário autenticado pelo Kerberos que se conecta ao cluster usando SSH, você deve garantir que as contas do Linux criadas correspondam ao usuário do Kerberos. Se as entidades principais forem fornecidos por um controlador de domínio do Active Directory, como o KDC externo ou por meio de uma relação de confiança entre realms, o Amazon EMR criará contas de usuário do Linux automaticamente. Se o Active Directory não for usado, você deverá criar principais para cada usuário que correspondam ao usuário do Linux. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
Cada usuário também deve ter um diretório de usuário do HDFS que pertença a eles, que você deve criar. Além disso, o SSH deve ser configurado com GSSAPI habilitada para permitir conexões de usuários autenticados pelo Kerberos. A GSSAPI deve ser habilitada no nó primário, e a aplicação SSH cliente deve ser configurada para usar GSSAPI. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
# Configuração de segurança e configurações do cluster para Kerberos no Amazon EMR
Ao criar um cluster Kerberizado, você especifica a configuração de segurança com atributos do Kerberos específicos do cluster. Você não pode especificar um conjunto sem o outro, ou ocorrerá um erro.
Este tópico fornece uma visão geral dos parâmetros de configuração disponíveis para o Kerberos quando você cria uma configuração de segurança e um cluster. Além disso, exemplos da CLI para criar configurações de segurança e clusters compatíveis são fornecidos para arquiteturas comuns.
## Configurações do Kerberos para configurações de segurança
Você pode criar uma configuração de segurança que especifique os atributos do Kerberos usando o console do Amazon EMR, o AWS CLI ou a API do EMR. A configuração de segurança também pode conter outras opções de segurança, como criptografia. Para obter mais informações, consulte [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md).
Use as referências a seguir para compreender as definições de configuração de segurança disponíveis para a arquitetura do Kerberos que você escolher. As configurações do console do Amazon EMR são exibidas. Para opções da CLI correspondentes, consulte [Especificando as configurações do Kerberos usando o AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) ou [Exemplos de configuração](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Configurações do Kerberos para clusters
Você pode especificar as configurações do Kerberos ao criar um cluster usando o console do Amazon EMR, o AWS CLI ou a API do EMR.
Use as referências a seguir para compreender as definições de configuração de cluster disponíveis para a arquitetura do Kerberos que você escolher. As configurações do console do Amazon EMR são exibidas. Para opções da CLI correspondentes, consulte [Exemplos de configuração](emr-kerberos-config-examples.md).
| Parâmetro | Description |
| --- | --- |
| Realm | O nome do realm do Kerberos para o cluster. A convenção do Kerberos deve ser a mesma do nome de domínio, mas em maiúsculas. Por exemplo, para o domínio `ec2.internal`, usando `EC2.INTERNAL` como o nome do realm. |
| Senha admin do KDC | A senha usada dentro do cluster para `kadmin` ou `kadmin.local`. Essas são interfaces de linha de comando para o sistema de administração do Kerberos V5, que mantém os principais do Kerberos, as políticas de senha e os keytabs do cluster. |
| Senha do principal da relação de confiança entre realms (opcional) | Obrigatório quando se estabelece uma relação de confiança entre realms. A senha do principal entre realms, que deve ser idêntica em todos os realms. Use uma senha forte. |
| Usuário de inclusão no domínio do Active Directory (opcional) | Obrigatório ao usar o Active Directory em uma relação de confiança entre realms. Este é o nome de logon de usuário de uma conta do Active Directory com permissão para integrar computadores ao domínio. O Amazon EMR usa essa identidade para integrar o cluster ao domínio. Para obter mais informações, consulte [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Senha de inclusão no domínio do Active Directory (opcional) | A senha para o usuário de inclusão no domínio do Active Directory. Para obter mais informações, consulte [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Exemplos de configuração
Os exemplos a seguir demonstram configurações de segurança e configurações de cluster para cenários comuns. AWS CLI os comandos são mostrados para fins de concisão.
## KDC local
Os comandos a seguir criam um cluster com um KDC dedicado ao cluster em execução no nó primário. Configurações adicionais no cluster podem ser necessárias. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Criar cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## KDC dedicado ao cluster com relação de confiança entre realms do Active Directory
Os comandos a seguir criam um cluster com um KDC dedicado ao cluster em execução no nó primário com uma relação de confiança entre realms para um domínio do Active Directory. Configuração adicional no cluster e no Active Directory é necessária. Para obter mais informações, consulte [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**Criar cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## KDC externo em um cluster diferente
Os comandos a seguir criam um cluster que referencia um KDC dedicado ao cluster no nó primário de um cluster diferente para autenticar entidades principais. Configurações adicionais no cluster podem ser necessárias. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH](emr-kerberos-configuration-users.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Criar cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## KDC externo do cluster com relação de confiança entre realms do Active Directory
Os comandos a seguir criam um cluster sem nenhum KDC. O cluster faz referência a um KDC dedicado ao cluster em execução no nó primário de outro cluster para autenticar entidades principais. Esse KDC tem uma relação de confiança entre realms com um controlador de domínio do Active Directory. A configuração adicional no nó primário com o KDC é obrigatória. Para obter mais informações, consulte [Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory](emr-kerberos-cross-realm.md).
**Criar configuração de segurança**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**Criar cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Configuração de um cluster do Amazon EMR para usuários do HDFS autenticados pelo Kerberos e conexões SSH
O Amazon EMR cria clientes de usuário autenticados pelo Kerberos para aplicações executadas no cluster. Por exemplo, o usuário `hadoop`, o usuário `spark` e outros. Você também pode adicionar usuários autenticados em processos de cluster usando o Kerberos. Os usuários autenticados podem se conectar ao cluster usando as credenciais do Kerberos e trabalhar com os aplicativos. Para que um usuário faça autenticação no cluster, as seguintes configurações são necessárias:
+ Deve haver uma conta Linux que corresponda à entidade principal do Kerberos no KDC no cluster. O Amazon EMR faz isso automaticamente em arquiteturas que se integram ao Active Directory.
+ Você deve criar um diretório de usuário do HDFS no nó primário para cada usuário e conceder as permissões ao usuário para o diretório.
+ É necessário configurar o serviço SSH para que GSSAPI esteja habilitada no nó primário. Além disso, os usuários devem ter um cliente SSH com GSSAPI habilitada.
## Adicionar usuários do Linux e entidades principais do Kerberos ao nó primário
Se não usar o Active Directory, você deverá criar contas do Linux no nó primário do cluster e adicionar entidades principais a esses usuários do Linux para o KDC. Isso inclui uma entidade principal no KDC para o nó primário. Além dos usuários principais, o KDC em execução no nó primário precisa de uma entidade principal para o host local.
Quando sua arquitetura inclui integração com o Active Directory, os usuários do Linux e os principais no KDC local, se aplicável, são criados automaticamente. Você pode ignorar esta etapa. Para obter mais informações, consulte [Relação de confiança entre realms](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) e [KDC externo: KDC do cluster em um cluster diferente com relação de confiança entre realms do Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**Importante**
O KDC, junto com o banco de dados de entidades principais, é perdido quando o nó primário é terminado porque o nó primário usa armazenamento temporário. Se você criar usuários para conexões SSH, é recomendável estabelecer uma relação de confiança entre regiões com um KDC externo configurado para alta disponibilidade. Como alternativa, se você criar usuários para conexões SSH usando contas Linux, automatize o processo de criação da conta usando ações e scripts de bootstrap de modo que possa ser repetido ao criar um novo cluster.
Enviar uma etapa ao cluster depois de criá-lo ou ao criar o cluster é a maneira mais fácil de adicionar usuários e principais do KDC. Como alternativa, você pode se conectar ao nó primário usando um par de chaves do EC2 como o usuário `hadoop` padrão para executar os comandos. Para obter mais informações, consulte [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md).
O exemplo a seguir envia um script bash `configureCluster.sh` para um cluster que já existe, fazendo referência ao ID do cluster. O script é salvo no Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
O exemplo a seguir demonstra o conteúdo do script `configureCluster.sh`. O script também trata da criação de diretórios do usuário do HDFS e habilita GSSAPI para SSH, que são abordados nas seções a seguir.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## Adicionar diretórios do usuário do HDFS
Para permitir que os usuários façam login no cluster para executar trabalhos do Hadoop, você deve adicionar diretórios do usuário HDFS para contas do Linux e conceder a cada um a propriedade do diretório.
Enviar uma etapa ao cluster depois de criá-lo ou ao criar o cluster é a maneira mais fácil de criar diretórios do HDFS. Como alternativa, você pode se conectar ao nó primário usando um par de chaves do EC2 como o usuário `hadoop` padrão para executar os comandos. Para obter mais informações, consulte [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md).
O exemplo a seguir envia um script bash `AddHDFSUsers.sh` para um cluster que já existe, fazendo referência ao ID do cluster. O script é salvo no Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
O exemplo a seguir demonstra o conteúdo do script `AddHDFSUsers.sh`.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## Habilitar GSSAPI para SSH
Para usuários autenticados pelo Kerberos se conectarem ao nó primário usando o SSH, o serviço SSH deve ter a autenticação GSSAPI habilitada. Para habilitar GSSAPI, execute os seguintes comandos na linha de comando do nó primário ou use uma etapa para executá-lo como um script. Depois de reconfigurar o SSH, você deverá reiniciar o serviço.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR
Esta seção demonstra as etapas para que um usuário autenticado pelo Kerberos se conecte ao nó primário de um cluster do EMR.
Cada computador que é usado para uma conexão SSH deve ter aplicativos cliente SSH e cliente Kerberos instalados. Os computadores Linux provavelmente incluem esses aplicativos por padrão. Por exemplo, a OpenSSH está instalada na maioria dos sistemas operacionais Unix, Linux e MacOS X. É possível verificar se existe um cliente SSH digitando **ssh** na linha de comando. Se o computador não reconhecer o comando, instale um cliente SSH para se conectar ao nó primário. O projeto OpenSSH fornece uma implementação grátis do pacote completo de ferramentas SSH. Para obter mais informações, consulte o site do [OpenSSH](http://www.openssh.org/). Os usuários do Windows podem usar aplicativos, como o [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/), como um cliente SSH.
Para obter mais informações sobre conexões SSH, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
O SSH usa GSSAPI para autenticar os clientes Kerberos, e você deve habilitar a autenticação GSSAPI para o serviço SSH no nó primário do cluster. Para obter mais informações, consulte [Habilitar GSSAPI para SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Os clientes SSH também devem usar GSSAPI.
Nos exemplos a seguir, *MasterPublicDNS* use o valor que aparece para **Master public DNS** na guia **Resumo** do painel de detalhes do cluster — por exemplo,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Pré-requisito para krb5.conf (que não é do Active Directory)
Ao usar uma configuração sem integração com o Active Directory, além das aplicações cliente SSH e cliente Kerberos, cada computador cliente deve ter uma cópia do arquivo `/etc/krb5.conf` que corresponde ao arquivo `/etc/krb5.conf` no nó primário do cluster.
**Para copiar o arquivo krb5.conf**
1. Use o SSH para se conectar ao nó primário usando um par de chaves do EC2 e o usuário `hadoop` padrão; por exemplo, `hadoop@MasterPublicDNS`. Para obter instruções detalhadas, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
1. No nó primário, copie o conteúdo do arquivo `/etc/krb5.conf`. Para obter mais informações, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
1. Em cada computador cliente que será usado para se conectar ao cluster, crie um arquivo `/etc/krb5.conf` idêntico com base na cópia feita na etapa anterior.
## Usar Kinit e SSH
Cada vez que um usuário se conecta a partir de um computador cliente usando credenciais do Kerberos, o usuário deve primeiro renovar tíquetes Kerberos para seu usuário no computador cliente. Além disso, o cliente SSH deve estar configurado para usar a autenticação GSSAPI.
**Para usar o SSH para se conectar a um cluster do EMR Kerberizado**
1. Use `kinit` para renovar os tíquetes Kerberos, conforme mostrado no exemplo a seguir
```
kinit user1
```
1. Use um cliente `ssh` juntamente com o principal que você criou no KDC dedicado ao cluster ou o nome de usuário do Active Directory. Certifique-se de que a autenticação GSSAPI esteja habilitada, conforme mostrado nos exemplos a seguir.
**Exemplo: usuários do Linux**
A opção `-K ` especifica a autenticação de GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Exemplo: usuários do Windows (PuTTY)**
Certifique-se de que a opção de autenticação GSSAPI para a sessão esteja habilitada conforme mostrado:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: configurar um KDC dedicado ao cluster com o Amazon EMR
Este tópico orienta você na criação de um cluster com um *centro de distribuição de chaves (KDC)* dedicado ao cluster, adicionando manualmente contas do Linux a todos os nós do cluster, adicionando entidades principais do Kerberos ao KDC no nó primário e garantindo que os computadores cliente tenham um cliente Kerberos instalado.
Para obter mais informações sobre o suporte do Amazon EMR para Kerberos e KDC, bem como links para a documentação do MIT Kerberos, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md).
## Etapa 1: criar o cluster kerberizado
1. Crie uma configuração de segurança que permita o Kerberos. O exemplo a seguir demonstra um `create-security-configuration` comando usando o AWS CLI que especifica a configuração de segurança como uma estrutura JSON embutida. Você também pode fazer referência a um arquivo salvo localmente.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Crie um cluster que faça referência à configuração de segurança, estabeleça os atributos do Kerberos para o cluster e adicione contas do Linux usando uma ação de bootstrap. O exemplo a seguir demonstra um comando `create-cluster ` usando a AWS CLI. O comando faz referência à configuração de segurança criada por você acima, `MyKerberosConfig`. Ele também faz referência a um script simples, `createlinuxusers.sh`, como uma ação de bootstrap, que você cria e carrega no Amazon S3 antes de criar o cluster.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
O código a seguir demonstra o conteúdo do script `createlinuxusers.sh`, que adiciona user1, user2 e user3 a cada nó no cluster. Na próxima etapa, você adicionará esses usuários como principais do KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Etapa 2: adicionar entidades principais ao KDC, criar diretórios de usuário do HDFS e configurar o SSH
O KDC em execução no nó primário precisa de uma entidade principal adicionada para o host local e para cada usuário criado por você no cluster. Você também poderá criar diretórios do HDFS para cada usuário se eles precisarem se conectar ao cluster e executar trabalhos do Hadoop. Da mesma maneira, configure o SSH para habilitar a autenticação GSSAPI, necessária para o Kerberos. Depois de habilitar GSSAPI, reinicie o serviço SSH.
A maneira mais fácil de realizar essas tarefas é enviar uma etapa para o cluster. O exemplo a seguir envia um `configurekdc.sh` de script bash para o cluster que você criou na etapa anterior, referenciando o ID do cluster. O script é salvo no Amazon S3. Você também pode se conectar ao nó primário usando um par de chaves do EC2 para executar os comandos ou enviar a etapa durante a criação do cluster.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
O código a seguir demonstra o conteúdo do script `configurekdc.sh`.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Os usuários que você adicionou agora devem poder se conectar ao cluster usando SSH. Para obter mais informações, consulte [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: configurar uma relação de confiança entre realms com um controlador de domínio do Active Directory
Ao configurar uma relação de confiança entre realms, você permite que os principais (normalmente usuários) de um realm do Kerberos diferente se autentiquem em componentes do aplicativo no cluster do EMR. O *centro de distribuição de chaves (KDC)* dedicado ao cluster estabelece uma relação de confiança com outro KDC usando um princípio *entre* domínios que existe em ambos. KDCs O nome do principal e a senha coincidem precisamente.
Uma relação de confiança entre realms exige que os KDCs possam se alcançar um ao outro pela rede e resolver os nomes de domínio um do outro. As etapas para estabelecer uma relação de confiança entre realms com um controlador de domínio do Microsoft AD em execução como uma instância do EC2 são apresentadas abaixo com uma configuração de rede de exemplo que oferece a conectividade e a resolução de nomes de domínio necessárias. Qualquer configuração de rede que permita o tráfego de rede necessário KDCs é aceitável.
Opcionalmente, depois de estabelecer uma relação de confiança entre realms com o Active Directory usando um KDC em um cluster, você poderá criar outro cluster usando uma configuração de segurança diferente para fazer referência ao KDC no primeiro cluster como um KDC externo. Para obter um exemplo de configuração de segurança e a configuração do cluster, consulte [KDC externo do cluster com relação de confiança entre realms do Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Para obter mais informações sobre o suporte do Amazon EMR para Kerberos e KDC, bem como links para a documentação do MIT Kerberos, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md).
**Importante**
O Amazon EMR não oferece suporte a relações de confiança entre regiões com. AWS Directory Service for Microsoft Active Directory
[Etapa 1: configurar a VPC e a sub-rede](#emr-kerberos-ad-network)
[Etapa 2: iniciar e instalar o controlador de domínio do Active Directory](#emr-kerberos-ad-dc)
[Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](#emr-kerberos-ad-users)
[Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory](#emr-kerberos-ad-configure-trust)
[Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC](#emr-kerberos-ad-DHCP)
[Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster)
[Etapa 7: criar usuários HDFS e definir permissões no cluster para contas do Active Directory](#emr-kerberos-ad-hadoopuser)
## Etapa 1: configurar a VPC e a sub-rede
As etapas a seguir demonstram como criar uma VPC e uma sub-rede, de maneira que o KDC dedicado ao cluster possa alcançar o controlador de domínio do Active Directory e resolver o nome de domínio. Nessas etapas, a resolução de nomes de domínio é fornecida referenciando-se o controlador de domínio do Active Directory como o servidor de nomes de domínio no conjunto de opções DHCP. Para obter mais informações, consulte [Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC](#emr-kerberos-ad-DHCP).
O KDC e o controlador de domínio do Active Directory devem poder resolver os nomes de domínio um do outro. Isso permite ao Amazon EMR adicionar computadores ao domínio e configurar automaticamente as contas do Linux correspondentes e os parâmetros SSH em instâncias de cluster.
Se o Amazon EMR não conseguir resolver o nome de domínio, você poderá referenciar a relação de confiança usando o endereço IP do controlador de domínio do Active Directory. No entanto, você deve adicionar manualmente contas do Linux, adicionar entidades principais correspondentes ao KDC dedicado ao cluster e configurar o SSH.
**Para configurar a VPC e a sub-rede**
1. Crie uma Amazon VPC com uma única sub-rede pública. Para obter mais informações, consulte [Step 1: Create the VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) no *Amazon VPC Getting Started Guide*.
**Importante**
Ao usar um controlador de domínio do Microsoft Active Directory, escolha um bloco CIDR para o cluster do EMR de forma que IPv4 todos os endereços tenham menos de nove caracteres (por exemplo, 10.0.0.0/16). Isso ocorre porque os nomes DNS dos computadores de cluster são usados quando os computadores ingressam no diretório do Active Directory. AWS atribui [nomes de host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) com base no IPv4 endereço de forma que endereços IP mais longos possam resultar em nomes DNS com mais de 15 caracteres. O Active Directory tem um limite de 15 caracteres para registrar nomes de computador adicionados e trunca nomes mais longos, o que pode causar erros imprevisíveis.
1. Remova o conjunto de opções DHCP padrão atribuído à VPC. Para obter mais informações, consulte [Changing a VPC to use No DHCP options](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Posteriormente, você adicionará um novo especificando o controlador de domínio do Active Directory como o servidor DNS.
1. Confirme se o suporte DNS está habilitado para a VPC, ou seja, se os nomes de host e a resolução DNS estão habilitados. Por padrão, as transições estão ativadas. Para obter mais informações, consulte [Updating DNS support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Confirme se a VPC tem um gateway da Internet anexado, que é o padrão. Para mais informações, consulte [Criar e anexar um gateway da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**nota**
Um gateway da Internet é usado neste exemplo porque você está estabelecendo um novo controlador de domínio para a VPC. O gateway da Internet talvez não seja necessário para o aplicativo. O único requisito é que o KDC dedicado ao cluster possa acessar o controlador de domínio do Active Directory.
1. Crie uma tabela de rotas personalizada, adicione uma rota com o gateway da Internet como destino e a anexe à sub-rede. Para obter mais informações, consulte [Criar uma tabela de rotas personalizada](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Quando você executa a instância EC2 para o controlador de domínio, ela deve ter um IPv4 endereço público estático para que você possa se conectar a ela usando RDP. A maneira mais fácil de fazer isso é configurar sua sub-rede para atribuir endereços públicos IPv4 automaticamente. Não se trata da configuração padrão quando uma sub-rede é criada. Para obter mais informações, consulte [Modificação do atributo de IPv4 endereçamento público da sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Você também pode atribuir o endereço ao iniciar a instância. Para obter mais informações, consulte [Atribuição de um IPv4 endereço público durante a execução da instância](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Ao terminar, anote sua VPC e sua sub-rede. IDs Você os usará depois quando iniciar o controlador de domínio do Active Directory e o cluster.
## Etapa 2: iniciar e instalar o controlador de domínio do Active Directory
1. Inicie uma instância do EC2 com base na AMI Microsoft Windows Server 2016 Base. Recomendamos um tipo de instância m4.xlarge ou melhor. Para obter mais informações, consulte [Executar uma instância do AWS Marketplace](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) no *Guia do usuário do Amazon EC2*.
1. Anote o ID do grupo de segurança associado à instância do EC2. Você precisa dele para o [Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster). Nós usamos*sg-012xrlmdomain345*. Opcionalmente, você pode especificar grupos de segurança diferentes para o cluster do EMR e essa instância que permite o tráfego entre eles. Para obter mais informações, consulte [Grupos de segurança do Amazon EC2 para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) no *Guia do usuário do Amazon EC2*.
1. Conecte-se à instância do EC2 usando o RDP. Para obter mais informações, consulte [Conectar-se à sua instância baseada no Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) no *Guia do usuário do Amazon EC2*.
1. Inicie o **Server Manager** para instalar e configurar o perfil Active Directory Domain Services no servidor. Promova o servidor para um controlador de domínio e atribua um nome de domínio (o exemplo que usamos aqui é `ad.domain.com`). Anote o nome de domínio porque você vai precisar dele depois ao criar a configuração de segurança do EMR e o cluster. Se estiver começando a configurar o Active Directory, você poderá seguir as instruções em [How to setup Active Directory (AD) In Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
A instância será reiniciada quando você terminar.
## Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR
Use o RDP para o controlador de domínio do Active Directory para criar contas em usuários e computadores do Active Directory para cada usuário do cluster. Para obter mais informações, consulte [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) no site *Microsoft Learn*. Anote o **User logon name (Nome de logon do usuário)** de cada usuário. Você precisará dele mais tarde ao configurar o cluster.
Além disso, crie uma conta com privilégios suficientes para integrar computadores ao domínio. Você especifica essa conta ao criar um cluster. O Amazon EMR a usa para integrar instâncias de cluster ao domínio. Você especifica essa conta e a senha em [Etapa 6: Iniciar um cluster EMR Kerberizado](#emr-kerberos-ad-cluster). Para delegar privilégios de integração do computador à conta, recomendamos criar um grupo com privilégios de junção e, em seguida, atribuir o usuário ao grupo. Para obter instruções, consulte [Delegating directory join privileges](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) no *Guia de administração AWS Directory Service *.
## Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory
Os comandos de exemplo abaixo criam uma relação de confiança no Active Directory, que é uma relação de confiança de realm unidirecional, de entrada e não transitiva com o KDC dedicado ao cluster. O exemplo que usamos para no realm do cluster é `EC2.INTERNAL`. *KDC-FQDN*Substitua o pelo nome **DNS público** listado para o nó primário do Amazon EMR que hospeda o KDC. O parâmetro `passwordt` especifica a **cross-realm principal password (senha da entidade principal entre realms)**, determinada por você com o **realm** do cluster ao criar um cluster. O nome do realm deriva do nome de domínio padrão em `us-east-1` para o cluster. O `Domain` é o domínio do Active Directory no qual você está criando a confiança, que é em minúscula por convenção. O exemplo usa `ad.domain.com`
Abra o prompt de comando do Windows com privilégios de administrador e digite os seguintes comandos para criar a relação de confiança no controlador de domínio do Active Directory:
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## Etapa 5: usar uma opção DHCP definida para especificar o controlador de domínio do Active Directory como um servidor DNS da VPC
Agora que o controlador de domínio do Active Directory está configurado, você deve configurar a VPC para usá-lo como um servidor de nomes de domínio para resolução de nomes em sua VPC. Para isso, anexe um conjunto de opções DHCP. Especifique o **Nome do domínio** como o nome de domínio do cluster. Por exemplo, `ec2.internal` caso o cluster esteja em us-east-1 ou `region.compute.internal` para outras regiões. Para **servidores de nomes de domínio**, você deve especificar o endereço IP do controlador de domínio do Active Directory (que deve ser acessível a partir do cluster) como a primeira entrada, seguido pelo **AmazonProvidedDNS** (por exemplo ***xx.xx.xx.xx*, AmazonProvided** DNS). Para obter mais informações, consulte [Changing DHCP option sets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Etapa 6: Iniciar um cluster EMR Kerberizado
1. No Amazon EMR, crie uma configuração de segurança que especifique o controlador de domínio do Active Directory criado por você nas etapas anteriores. Um comando de exemplo é mostrado abaixo. Substitua o domínio, `ad.domain.com`, pelo nome do domínio especificado por você em [Etapa 2: iniciar e instalar o controlador de domínio do Active Directory](#emr-kerberos-ad-dc).
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. Crie o cluster com os seguintes atributos:
+ Use a opção `--security-configuration` para especificar a configuração de segurança que você criou. Usamos *MyKerberosConfig* no exemplo.
+ Use a propriedade `SubnetId` da `--ec2-attributes option` para especificar a sub-rede que você criou em [Etapa 1: configurar a VPC e a sub-rede](#emr-kerberos-ad-network). Usamos *step1-subnet* no exemplo.
+ Use `AdditionalMasterSecurityGroups` e `AdditionalSlaveSecurityGroups` da opção `--ec2-attributes` para especificar que o grupo de segurança associado ao controlador de domínio AD do [Etapa 2: iniciar e instalar o controlador de domínio do Active Directory](#emr-kerberos-ad-dc) está associado ao nó primário do cluster, bem como aos nós centrais e de tarefa. Usamos *sg-012xrlmdomain345* no exemplo.
Use `--kerberos-attributes` para especificar os seguintes atributos Kerberos específicos ao cluster:
+ O realm do cluster especificado por você ao configurar o controlador de domínio do Active Directory.
+ A senha da entidade principal da relação de confiança entre realms especificada por você como `passwordt` em [Etapa 4: configurar uma relação de confiança recebida no controlador de domínio do Active Directory](#emr-kerberos-ad-configure-trust).
+ Um `KdcAdminPassword`, que você pode usar para administrar o KDC dedicado ao cluster.
+ O nome de logon do usuário e a senha da conta do Active Directory com privilégios de ingresso no computador criados por você em [Etapa 3: adicionar contas de usuário ao domínio do cluster do EMR](#emr-kerberos-ad-users).
O exemplo a seguir inicia um cluster kerberizado.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## Etapa 7: criar usuários HDFS e definir permissões no cluster para contas do Active Directory
Ao configurar uma relação de confiança com o Active Directory, o Amazon EMR cria usuários do Linux no cluster para cada conta do Active Directory. Por exemplo, o nome de logon de usuário `LiJuan` no Active Directory tem uma conta do Linux de `lijuan`. Os nomes de usuário do Active Directory podem conter letras maiúsculas, mas o Linux não segue o uso de maiúsculas e minúsculas do Active Directory.
Para permitir que os usuários façam login no cluster para executar trabalhos do Hadoop, você deve adicionar diretórios do usuário HDFS para contas do Linux e conceder a cada um a propriedade do diretório. Para isso, recomendamos executar um script salvo no Amazon S3 como uma etapa de cluster. Você também pode executar os comandos no script abaixo da linha de comando no nó primário. Use o par de chaves do EC2 especificado por você quando criou o cluster para se conectar ao nó primário via SSH como o usuário do Hadoop. Para obter mais informações, consulte [Uso de um par de chaves do EC2 para credenciais SSH no Amazon EMR](emr-plan-access-ssh.md).
Execute o comando a seguir para adicionar uma etapa ao cluster que executa um script,*AddHDFSUsers.sh*.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
O conteúdo do arquivo *AddHDFSUsers.sh* é o seguinte.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Grupos do Active Directory mapeados para grupos do Hadoop
O Amazon EMR usa o Daemon do System Security Services (SSD) para mapear grupos do Active Directory para grupos do Hadoop. Para confirmar mapeamentos de grupos, depois de fazer login no nó primário, conforme descrito em [Uso de SSH para se conectar a clusters kerberizados com o Amazon EMR](emr-kerberos-connect-ssh.md), você poderá usar o comando `hdfs groups` para confirmar que os grupos do Active Directory aos quais sua conta do Active Directory pertence foram mapeados para os grupos do Hadoop para o usuário correspondente do Hadoop no cluster. Você também pode verificar mapeamentos de grupos de outros usuários especificando um ou mais nomes de usuário usando, por exemplo, o comando `hdfs groups lijuan`. Para obter mais informações, consulte [grupos](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) no [Guia de comandos HDFS do Apache](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Usar servidores Active Directory ou LDAP para autenticação com o Amazon EMR
Com o Amazon EMR 6.12.0 e versões posteriores, você pode usar o protocolo LDAP sobre SSL (LDAPS) para iniciar um cluster que se integra de forma nativa ao servidor de identidade corporativo. O Lightweight Directory Access Protocol (LDAP) é um protocolo de aplicação aberto e independente de fornecedor que acessa e mantém dados. O LDAP é bastante usado para autenticação de usuários em servidores de identidade corporativa hospedados em aplicações como o Active Directory (AD) e o OpenLDAP. Com essa integração nativa, você pode usar o servidor LDAP para autenticar usuários no Amazon EMR.
Os destaques da integração do LDAP do Amazon EMR incluem:
+ O Amazon EMR configura as aplicações compatíveis para se autenticarem com a autenticação LDAP em seu nome.
+ O Amazon EMR configura e mantém a segurança das aplicações compatíveis com o protocolo Kerberos. Não é necessário inserir nenhum comando ou script.
+ Você recebe controle de acesso refinado (FGAC) por meio da autorização do Apache Ranger para bancos de dados e tabelas do Hive Metastore. Consulte [Integrar o Amazon EMR com o Apache Ranger](emr-ranger.md) para obter mais informações.
+ Ao necessitar de credenciais LDAP para acessar um cluster, você recebe controle de acesso refinado (FGAC) sobre quem pode acessar seus clusters do EMR por meio de SSH.
As páginas a seguir fornecem uma visão geral conceitual, os pré-requisitos e as etapas para iniciar um cluster do EMR com a integração LDAP do Amazon EMR.
**Topics**
+ [Visão geral do LDAP com o Amazon EMR](ldap-overview.md)
+ [Componentes LDAP para Amazon EMR](ldap-components.md)
+ [Suporte de aplicações e considerações com o LDAP para Amazon EMR](ldap-considerations.md)
+ [Configurar e iniciar um cluster do EMR com LDAP](ldap-setup.md)
+ [Exemplos usando o LDAP com Amazon EMR](ldap-examples.md)
# Visão geral do LDAP com o Amazon EMR
O Lightweight Directory Access Protocol (LDAP) é um protocolo de software que os administradores de rede usam para gerenciar e controlar o acesso aos dados por meio da autenticação de usuários na rede de uma empresa. O protocolo LDAP armazena informações em uma estrutura hierárquica de diretórios em árvore. Para obter mais informações, consulte [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/) no *LDAP.com*.
Na rede de uma empresa, muitas aplicações podem usar o protocolo LDAP para autenticar usuários. Com a integração LDAP do Amazon EMR, os clusters do EMR podem usar o mesmo protocolo LDAP de maneira nativa com uma configuração de segurança adicionada.
Há duas implementações principais do protocolo LDAP compatíveis com o Amazon EMR: **Active Directory** e **OpenLDAP**. Há outras implementações possíveis, mas a maioria se encaixa nos mesmos protocolos de autenticação do Active Directory ou do OpenLDAP.
## Active Directory (AD)
O Active Directory (AD) é um serviço de diretório da Microsoft para redes de domínio Windows. O AD está incluído na maioria dos sistemas operacionais Windows Server e pode se comunicar com clientes pelos protocolos LDAP e LDAPS. Para autenticação, o Amazon EMR tenta usar a associação do usuário com a instância do AD com o nome da entidade principal do usuário (UPN) como nome e senha distintos. O UPN usa o formato padrão `username@domain_name`.
## OpenLDAP
O OpenLDAP é uma implementação gratuita e de código aberto do protocolo LDAP. Para autenticação, o Amazon EMR tenta usar a associação do usuário com a instância do OpenLDAP com o nome de domínio totalmente qualificado (FQDN) como nome distinto e senha. O FQDN usa o formato padrão `username_attribute=username,LDAP_user_search_base`. Normalmente, o valor de `username_attribute` é `uid`, e o valor de `LDAP_user_search_base` contém os atributos da árvore que leva ao usuário. Por exemplo, .`ou=People,dc=example,dc=com`
Outras implementações gratuitas e de código aberto do protocolo LDAP normalmente seguem um FQDN semelhante ao OpenLDAP para os nomes distintos dos respectivos usuários.
# Componentes LDAP para Amazon EMR
Você pode usar seu servidor LDAP para se autenticar no Amazon EMR e em qualquer aplicação que o usuário utilize diretamente no cluster do EMR por meio dos componentes a seguir.
**Agente secreto**
O *agente secreto* é um processo no cluster que autentica todas as solicitações do usuário. O agente secreto cria a associação do usuário para o servidor LDAP em nome das aplicações compatíveis com o cluster do EMR. O agente secreto é executado como o usuário `emrsecretagent` e grava logs no diretório `/emr/secretagent/log`. Esses logs fornecem detalhes sobre o estado da solicitação de autenticação de cada usuário e os erros que possam surgir durante a autenticação do usuário.
**System Security Services Daemon (SSSD)**
O *SSSD* é um daemon executado em cada nó de um cluster do EMR habilitado para LDAP. O SSSD cria e gerencia um usuário UNIX para sincronizar sua identidade corporativa remota com cada nó. Aplicações baseadas em YARN, como o Hive e o Spark, exigem que haja um usuário UNIX local em cada nó que executa uma consulta para um usuário.
# Suporte de aplicações e considerações com o LDAP para Amazon EMR
Este tópico lista aplicações compatíveis, recursos compatíveis e recursos não compatíveis.
## Aplicações compatíveis com LDAP para Amazon EMR
**Importante**
As aplicações listadas nesta página são as únicas com suporte do Amazon EMR para LDAP. Para garantir a segurança do cluster, só é possível incluir aplicações compatíveis com LDAP ao criar um cluster do EMR com o LDAP habilitado. Se você tentar instalar outras aplicações sem suporte, o Amazon EMR rejeitará a solicitação de um novo cluster.
O Amazon EMR 6.12 e versões posteriores oferece suporte à integração LDAP com as seguintes aplicações:
+ Apache Livy
+ Apache Hive até HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
Também é possível instalar as seguintes aplicações em um cluster do EMR e configurá-las para atender a suas necessidades de segurança:
+ Apache Spark
+ Apache Hadoop
## Atributos compatíveis com LDAP para Amazon EMR
É possível usar os seguintes recursos do Amazon EMR com a integração do LDAP:
**nota**
Para manter as credenciais LDAP seguras, é necessário usar criptografia em trânsito para proteger o fluxo de dados dentro e fora do cluster. Para obter mais informações sobre criptografia em trânsito, consulte [Criptografia de dados em repouso e em trânsito com o Amazon EMR](emr-data-encryption.md).
+ Criptografia em trânsito (obrigatório) e em repouso
+ Grupos de instâncias, frotas de instâncias e instâncias spot
+ Reconfiguração de aplicações em um cluster em execução
+ Criptografia do lado do servidor (SSE) do EMRFS
## Atributos não compatíveis
Considere as seguintes limitações ao usar a integração do LDAP com Amazon EMR:
+ O Amazon EMR desabilita etapas para clusters com o LDAP habilitado.
+ O Amazon EMR não oferece suporte a funções e AWS Lake Formation integrações de tempo de execução para clusters com LDAP habilitado.
+ O Amazon EMR não oferece suporte a LDAP com StartTLS.
+ O Amazon EMR não oferece suporte ao modo de alta disponibilidade (clusters com múltiplos nós primários) para clusters com LDAP habilitado.
+ Não é possível alternar credenciais ou certificados de vinculação para clusters com LDAP habilitado. Se algum desses campos tiver sido alternado, é recomendável iniciar um novo cluster com as credenciais ou certificados de vinculação atualizados.
+ Você deve usar bases de pesquisa exatas com o LDAP. A base de pesquisa de usuários e grupos do LDAP não oferece suporte aos filtros de pesquisa do LDAP.
# Configurar e iniciar um cluster do EMR com LDAP
Esta seção aborda como configurar o Amazon EMR para uso com autenticação LDAP.
**Topics**
+ [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md)
+ [Criar a configuração de segurança do Amazon EMR para integração com LDAP](ldap-setup-security.md)
+ [Iniciar um cluster do EMR que se autentique com LDAP](ldap-setup-launch.md)
# Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR
O Amazon EMR usa um perfil de serviço do IAM para realizar ações a seu favor a fim de provisionar e gerenciar clusters. O perfil de serviço para instâncias do EC2 do cluster, também chamada de *perfil de instância do EC2 para Amazon EMR*, é um tipo especial de perfil de serviço que o Amazon EMR atribui ao iniciar cada instância do EC2 do cluster.
Para definir permissões para que um cluster do EMR interaja com dados do Amazon S3 e outros serviços da AWS , defina um perfil de instância personalizado do Amazon EC2 no lugar de `EMR_EC2_DefaultRole` ao executar o cluster. Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md) e [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md).
Adicione as seguintes instruções ao perfil de instância padrão do EC2 para permitir que o Amazon EMR marque sessões e acesse AWS Secrets Manager aquelas que armazenam certificados LDAP.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**nota**
Suas solicitações de cluster falharão se você esquecer o caractere curinga `*` no final do nome do segredo ao definir as permissões do Secrets Manager. O curinga representa as versões do segredo.
Você também deve limitar o escopo da AWS Secrets Manager política somente aos certificados que seu cluster precisa para provisionar instâncias.
# Criar a configuração de segurança do Amazon EMR para integração com LDAP
Antes de iniciar um cluster do EMR com integração com LDAP, use as etapas descritas em [Crie uma configuração de segurança com o console do Amazon EMR ou com o AWS CLI](emr-create-security-configuration.md) para criar uma configuração de segurança do Amazon EMR para o cluster. Complete as seguintes configurações no bloco de `LDAPConfiguration` em `AuthenticationConfiguration` ou nos campos correspondentes na seção **Configurações de segurança** do console do Amazon EMR:
**`EnableLDAPAuthentication`**
Opção do console: **Protocolo de autenticação: LDAP**
Para usar a integração com LDAP, defina essa opção como `true` ou selecione-a como protocolo de autenticação ao criar um cluster no console. Por padrão, `EnableLDAPAuthentication` é `true` ao criar uma configuração de segurança no console do Amazon EMR.
**`LDAPServerURL`**
Opção do console: **local do servidor LDAP**
A localização do servidor LDAP, incluindo o prefixo: `ldaps://location_of_server`.
**`BindCertificateARN`**
Opção do console: **certificado SSL LDAP**
O AWS Secrets Manager ARN que contém o certificado para assinar o certificado SSL que o servidor LDAP usa. Se seu servidor LDAP for assinado por uma Autoridade Certificadora (CA) pública, você poderá fornecer um AWS Secrets Manager ARN com um arquivo em branco. Para obter mais informações sobre como armazenar seu certificado no Secrets Manager, consulte [Armazene certificados TLS em AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opção do console: **credenciais de vinculação do servidor LDAP**
Um AWS Secrets Manager ARN que contém as credenciais de associação do usuário administrador do LDAP. As credenciais são armazenadas como objeto JSON. Há somente um par de chave-valor nesse segredo; a chave no par é o nome de usuário e o valor é a senha. Por exemplo, .`{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}` Esse é um campo opcional, a menos que você habilite o login SSH para o cluster do EMR. Em muitas configurações, as instâncias do Active Directory exigem credenciais de vinculação para permitir que o SSSD sincronize usuários.
**`LDAPAccessFilter`**
Opção do console: **filtro de acesso LDAP**
Especifica o subconjunto de objetos no servidor LDAP que podem ser autenticados. Por exemplo, para conceder acesso a todos os usuários com a classe de objeto `posixAccount` no servidor LDAP, defina o filtro de acesso como `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opção do console: **base de pesquisa de usuários LDAP**
A base de pesquisa à qual seus usuários pertencem no servidor LDAP. Por exemplo, .`cn=People,dc=example,dc=com`
**`LDAPGroupSearchBase`**
Opção de console: **base de pesquisa de grupos LDAP**
A base de pesquisa à qual seus grupos pertencem no servidor LDAP. Por exemplo, .`cn=Groups,dc=example,dc=com`
**`EnableSSHLogin`**
Opção do console: **login SSH**
Especifica se a autenticação por senha com credenciais LDAP deverá ou não ser permitida. Não é recomendável habilitar essa opção. Os pares de chaves são uma rota mais segura para permitir o acesso aos clusters do EMR. Esse campo é opcional e usa o padrão `false`.
**`LDAPServerType`**
Opção de console: **tipo de servidor LDAP**
Especifica o tipo de servidor LDAP ao qual o Amazon EMR se conectará. As opções compatíveis são Active Directory e OpenLDAP. Outros tipos de servidor LDAP podem funcionar, mas o Amazon EMR não é oficialmente compatível com outros tipos de servidor. Para obter mais informações, consulte [Componentes LDAP para Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Um sub-bloco necessário para configurações de segurança que utilizam o tipo de servidor Active Directory.
**`ADDomain`**
Opção do console: **domínio do Active Directory**
O nome de domínio usado para criar o nome da entidade principal do usuário (UPN) para autenticação do usuário com configurações de segurança que usam o tipo de servidor Active Directory.
## Considerações sobre configurações de segurança com LDAP e Amazon EMR
+ Para criar uma configuração de segurança com a integração LDAP do Amazon EMR, é necessário usar criptografia em trânsito. Para obter informações sobre criptografia em trânsito, consulte [Criptografia de dados em repouso e em trânsito com o Amazon EMR](emr-data-encryption.md).
+ Não é possível definir a configuração do Kerberos na mesma configuração de segurança. O Amazon EMR provisiona um KDC que é dedicado automaticamente e gerencia a senha de administrador para o KDC. Os usuários não poderão acessar essa senha de administrador.
+ Você não pode definir funções de tempo de execução do IAM e AWS Lake Formation na mesma configuração de segurança.
+ `LDAPServerURL` deve ter o protocolo `ldaps://` em seu valor.
+ `LDAPAccessFilter` não pode estar vazio.
## Usar o LDAP com a integração do Apache Ranger para Amazon EMR
Com a integração LDAP para Amazon EMR, é possível se integrar ainda mais com o Apache Ranger. Ao inserir seus usuários LDAP no Ranger, você pode associar esses usuários a um servidor de políticas Apache Ranger para integração com o Amazon EMR e outras aplicações. Para isso, defina o campo `RangerConfiguration` em `AuthorizationConfiguration` na configuração de segurança que você usa com o cluster do LDAP. Para obter mais informações sobre como definir a configuração de segurança, consulte [Criar a configuração de segurança do EMR](emr-ranger-security-config.md).
Ao usar o LDAP com o Amazon EMR, não é necessário fornecer uma `KerberosConfiguration` com a integração com o Amazon EMR para Apache Ranger.
# Iniciar um cluster do EMR que se autentique com LDAP
Realize as etapas a seguir para iniciar um cluster do EMR com LDAP ou Active Directory.
1. Configure o ambiente:
+ Certifique-se de que os nós em seu cluster do EMR possam se comunicar com o Amazon S3 e. AWS Secrets Manager Para obter mais informações sobre como modificar seu perfil do perfil de instância do EC2 para se comunicar com esses serviços, consulte [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md).
+ Se você planeja executar seu cluster do EMR em uma sub-rede privada, você deve usar endpoints da AWS PrivateLink Amazon VPC ou usar a tradução de endereços de rede (NAT) para configurar a VPC para se comunicar com o S3 e o Secrets Manager. Para obter mais informações, consulte [AWS PrivateLink and VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) e [NAT instances](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) no *Amazon VPC Getting Started Guide*.
+ Verifique se há conectividade de rede entre o cluster do EMR e o servidor LDAP. Seus clusters do EMR devem acessar o servidor LDAP pela rede. Os nós primário, central e de tarefa do cluster se comunicam com o servidor LDAP para sincronizar os dados do usuário. Se o servidor LDAP for executado no Amazon EC2, atualize o grupo de segurança do EC2 para aceitar o tráfego do cluster do EMR. Para obter mais informações, consulte [Adicione AWS Secrets Manager permissões à função de instância do Amazon EMR](ldap-setup-asm.md).
1. Criar uma configuração de segurança do Amazon EMR para integração com LDAP. Para obter mais informações, consulte [Criar a configuração de segurança do Amazon EMR para integração com LDAP](ldap-setup-security.md).
1. Agora que você está configurado, use as etapas descritas em [Inicialização de um cluster do Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) para iniciar o cluster com as seguintes configurações:
+ Selecione Amazon EMR versão 6.12 ou posterior. É recomendável usar a versão mais recente do Amazon EMR.
+ Especifique ou selecione somente aplicações para o cluster compatíveis com LDAP. Para obter uma lista de aplicações compatíveis com LDAP com o Amazon EMR, consulte [Suporte de aplicações e considerações com o LDAP para Amazon EMR](ldap-considerations.md).
+ Aplique a configuração de segurança criada na etapa anterior.
# Exemplos usando o LDAP com Amazon EMR
Depois de [provisionar um cluster do EMR que usa a integração com LDAP](ldap-setup-launch.md), você pode fornecer suas credenciais LDAP para qualquer [aplicação compatível](ldap-considerations.md#ldap-considerations-apps) por meio de seu mecanismo de autenticação de nome de usuário e senha incorporado. Esta página mostra alguns exemplos.
## Usar a autenticação LDAP com o Apache Hive
**Example - Apache Hive**
O comando de exemplo a seguir inicia uma sessão do Apache Hive por meio de HiveServer 2 e Beeline:
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Usar a autenticação LDAP com o Apache Livy
**Example - Apache Livy**
O comando de exemplo a seguir inicia uma sessão do Livy por cURL. Substitua `ENCODED-KEYPAIR` com uma string codificada em Base64 por `username:password`.
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Usar autenticação do LDAP com o Presto
**Example - Presto**
O comando de exemplo a seguir inicia uma sessão do Presto pela CLI do Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Após executar esse comando, digite a senha do LDAP no prompt.
## Usar a autenticação LDAP com o Trino
**Example - Trino**
O comando de exemplo a seguir inicia uma sessão do Trino pela CLI do Trino:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Após executar esse comando, digite a senha do LDAP no prompt.
## Usar a autenticação LDAP com o Hue
Você pode acessar a interface do usuário do Hue por um túnel SSH criado no cluster ou pode configurar um servidor proxy para transmitir publicamente a conexão com o Hue. Como o Hue não é executado no modo HTTPS por padrão, é recomendável usar uma camada de criptografia adicional para garantir que a comunicação entre os clientes e a interface do usuário do Hue seja criptografada com HTTPS. Isso reduz a chance de expor acidentalmente as credenciais do usuário em texto sem formatação.
Para usar a interface do usuário do Hue, abra a interface do usuário do Hue no navegador e digite a senha do nome de usuário LDAP para fazer login. Se as credenciais estiverem corretas, o Hue fará login e usará sua identidade para autenticar você em todas as aplicações compatíveis.
## Usar SSH para autenticação por senha e tíquetes do Kerberos para outras aplicações
**Importante**
Não é recomendável usar a autenticação por senha com um cluster do EMR.
Você pode usar suas credenciais LDAP para fazer SSH em um cluster do EMR. Para isso, defina a configuração `EnableSSHLogin` como `true` na configuração de segurança do Amazon EMR usada para iniciar o cluster. Depois, use o comando a seguir para SSH no cluster depois que ele for iniciado:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Após executar esse comando, digite a senha do LDAP no prompt.
O Amazon EMR inclui um script no cluster que permite aos usuários gerar um arquivo keytab e um tíquete do Kerberos para usar com aplicações compatíveis que não aceitam credenciais LDAP diretamente. Alguns desses aplicativos incluem `spark-submit` Spark SQL e. PySpark
Execute `ldap-kinit` e siga as instruções. Se a autenticação tiver êxito, o arquivo keytab do Kerberos será exibido no diretório inicial com um tíquete do Kerberos válido. Use o tíquete do Kerberos para executar aplicações como você faria em qualquer ambiente kerberizado.
# Integre o Amazon EMR com Centro de Identidade do AWS IAM
Com as versões 6.15.0 e superiores do Amazon EMR, você pode usar identidades de para se Centro de Identidade do AWS IAM autenticar em um cluster do Amazon EMR. As seções a seguir fornecem uma visão geral conceitual, os pré-requisitos e as etapas necessárias para executar um cluster do EMR com a integração do Centro de Identidade.
**Topics**
+ [Visão geral do](#emr-idc-overview)
+ [Recursos e benefícios](#emr-idc-features)
+ [Começando a usar Centro de Identidade do AWS IAM o Amazon EMR](emr-idc-start.md)
+ [Sessões de usuário em segundo plano](user-background-sessions.md)
+ [Considerações e limitações do Amazon EMR com a integração do Centro de Identidade](emr-idc-considerations.md)
## Visão geral do
O [Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) é a abordagem recomendada para autenticação e autorização da força de trabalho em AWS organizações de qualquer tamanho e tipo. Com o Identity Center, você pode criar e gerenciar identidades de usuários ou conectar sua fonte de identidade existente, incluindo Microsoft Active Directory, Okta, Ping Identity JumpCloud, Google Workspace e Microsoft Entra ID (antigo Azure AD). AWS
A [propagação de identidade confiável](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) é um Centro de Identidade do AWS IAM recurso que os administradores do Connected Serviços da AWS podem usar para conceder e auditar o acesso aos dados do serviço. O acesso a esses dados é baseado em atributos do usuário, como associações de grupo. Configurar a propagação de identidade confiável requer colaboração entre os administradores do Connected Serviços da AWS e os administradores do IAM Identity Center. Para ter mais informações, consulte [Prerequisites and considerations](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
## Recursos e benefícios
A integração do Amazon EMR com o Centro de Identidade do IAM oferece os seguintes benefícios:
+ O Amazon EMR fornece credenciais para retransmitir sua identidade do Centro de Identidade a um cluster do EMR.
+ O Amazon EMR configura todas as aplicações compatíveis para se autenticarem com as credenciais do cluster.
+ O Amazon EMR configura e mantém a segurança das aplicações compatíveis com o protocolo Kerberos, sem que você precise de comandos ou scripts.
+ A capacidade de aplicar a autorização no nível de prefixo do Amazon S3 com as identidades do Centro de Identidade em prefixos do S3 gerenciados pelo S3 Access Grants.
+ A capacidade de impor a autorização em nível de tabela com identidades do Identity Center em tabelas gerenciadas AWS Lake Formation do Glue. AWS
# Começando a usar Centro de Identidade do AWS IAM o Amazon EMR
Esta seção ajuda você a configurar o Amazon EMR para integração com o. Centro de Identidade do AWS IAM
**Topics**
+ [Criação de uma instância do Centro de Identidade](#emr-idc-start-instance)
+ [Criação de um perfil do IAM para o Centro de Identidade](#emr-idc-start-role)
+ [Adicionar permissões para serviços não integrados ao Centro de Identidade do IAM](#emr-idc-start-securityconfig-nonidc)
+ [Criação de uma configuração de segurança habilitada para o Centro de Identidade](#emr-idc-start-securityconfig)
+ [Criação e execução de um cluster habilitado para o Centro de Identidade](#emr-idc-cluster)
+ [Configuração do Lake Formation para um cluster do EMR habilitado para o Centro de Identidade do IAM](emr-idc-lf.md)
+ [Como trabalhar com o S3 Access Grants em um cluster do EMR habilitado para o Centro de Identidade do IAM](emr-idc-s3ag.md)
**nota**
Para usar a integração do Centro de Identidade com o EMR, o Lake Formation ou a Concessão de Acesso do S3 devem estar habilitados. Você também pode usar ambos. Se nenhum estiver habilitado, a integração do Centro de Identidade não será compatível.
## Criação de uma instância do Centro de Identidade
Se ainda não tiver uma, crie uma instância do Centro de Identidade na Região da AWS em que deseja executar o cluster do EMR. Uma instância do Centro de Identidade só pode existir em uma única região para uma Conta da AWS.
Use o AWS CLI comando a seguir para criar uma nova instância chamada`MyInstance`:
```
aws sso-admin create-instance --name MyInstance
```
## Criação de um perfil do IAM para o Centro de Identidade
Para integrar o Amazon EMR com Centro de Identidade do AWS IAM, crie uma função do IAM que se autentique com o Identity Center a partir do cluster do EMR. O Amazon EMR usa credenciais SigV4 internamente para retransmitir a identidade do Centro de Identidade a serviços downstream, como o AWS Lake Formation. Seu perfil também deve ter as respectivas permissões para invocar os serviços downstream.
Ao criar o perfil, use a seguinte política de permissões:
```
{
"Statement": [
{
"Sid": "IdCPermissions",
"Effect": "Allow",
"Action": [
"sso-oauth:*"
],
"Resource": "*"
},
{
"Sid": "GlueandLakePermissions",
"Effect": "Allow",
"Action": [
"glue:*",
"lakeformation:GetDataAccess"
],
"Resource": "*"
},
{
"Sid": "AccessGrantsPermissions",
"Effect": "Allow",
"Action": [
"s3:GetDataAccess",
"s3:GetAccessGrantsInstanceForPrefix"
],
"Resource": "*"
}
]
}
```
A política de confiança desse perfil permite que o perfil InstanceProfile deixe-o assumir o perfil.
```
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678912:role/EMR_EC2_DefaultRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
```
Se o perfil não tiver credenciais confiáveis e acessar uma tabela protegida pelo Lake Formation, o Amazon EMR define automaticamente o `principalId` do perfil assumido como `userID-untrusted`. A seguir está um trecho de um CloudTrail evento que exibe o. `principalId`
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "ABCDEFGH1JKLMNO2PQR3TU:5000-untrusted",
"arn": "arn:aws:sts::123456789012:assumed-role/EMR_TIP/5000-untrusted",
"accountId": "123456789012",
"accessKeyId": "ABCDEFGH1IJKLMNOPQ7R3"
...
```
## Adicionar permissões para serviços não integrados ao Centro de Identidade do IAM
AWS credenciais que usam o Trusted Identity Propagation, as políticas do IAM definidas na função do IAM para todas as chamadas feitas para serviços não integrados ao IAM Identity Center. Isso inclui, por exemplo, AWS Key Management Service o. Seu perfil também deve definir as permissões do IAM para quaisquer serviços desse tipo que você tentaria acessar AWS Key Management Service de exemplo. Os serviços integrados do Centro de Identidade do IAM atualmente compatíveis incluem o AWS Lake Formation e a Concessão de Acesso do Amazon S3.
Para saber mais sobre Propagação de identidade confiável, consulte [Propagação confiável de identidade entre aplicações](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation.html).
## Criação de uma configuração de segurança habilitada para o Centro de Identidade
Para executar um cluster do EMR com a integração do Centro de Identidade do IAM, use o exemplo de comando a seguir para criar uma configuração de segurança do Amazon EMR que tenha o Centro de Identidade habilitado. Cada configuração é explicada abaixo.
```
aws emr create-security-configuration --name "IdentityCenterConfiguration-with-lf-accessgrants" --region "us-west-2" --security-configuration '{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterApplicationAssigmentRequired":false,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789"
}
},
"AuthorizationConfiguration": {
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
},
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
}
},
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
+ **`EnableIdentityCenter`**: (obrigatório) habilita a integração do Centro de Identidade.
+ **`IdentityCenterInstanceARN`**: (opcional) o ARN da instância do Centro de Identidade. Se isso não estiver incluído, o ARN existente da instância do Centro de Identidade do IAM será pesquisado como parte da etapa de configuração.
+ **`IAMRoleForEMRIdentityCenterApplicationARN`**: (obrigatório) o perfil do IAM que adquire tokens do Centro de Identidade do cluster.
+ **`IdentityCenterApplicationAssignmentRequired `**: (booleano) determina se uma atribuição será necessária para usar a aplicação do Centro de Identidade. Esse campo é opcional. Se um valor não for fornecido, o padrão será `false`.
+ **`AuthorizationConfiguration` ou `LakeFormationConfiguration`**: opcionalmente, configure a autorização:
+ **`IAMConfiguration`**: permite que o recurso Perfis de runtimes do EMR seja usado além da sua identidade TIP. Se você habilitar essa configuração, você (ou o AWS serviço do chamador) deverá especificar uma função de tempo de execução do IAM em cada chamada para as etapas do EMR ou do EMR. `GetClusterSessionCredentials` APIs Se o cluster do EMR estiver sendo usado com o SageMaker Unified Studio, essa opção será necessária se o Trusted Identity Propagation também estiver habilitado.
+ **`EnableLakeFormation`**: habilite a autorização do Lake Formation no cluster.
Para habilitar a integração do Centro de Identidade com o Amazon EMR, você deve especificar `EncryptionConfiguration` e `IntransitEncryptionConfiguration`.
## Criação e execução de um cluster habilitado para o Centro de Identidade
Agora que configurou o perfil do IAM que se autentica ao Centro de Identidade e criou uma configuração de segurança do Amazon EMR com o Centro de Identidade habilitado, você pode criar e executar seu cluster com reconhecimento de identidade. Para ver as etapas de execução do cluster com a configuração de segurança necessária, consulte [Como especificar uma configuração de segurança para um cluster do Amazon EMR](emr-specify-security-configuration.md).
As seguintes seções descrevem como configurar o cluster habilitado pelo Centro de Identidade com opções de segurança compatíveis com o Amazon EMR:
+ [Como trabalhar com o S3 Access Grants em um cluster do EMR habilitado para o Centro de Identidade do IAM](emr-idc-s3ag.md)
+ [Configuração do Lake Formation para um cluster do EMR habilitado para o Centro de Identidade do IAM](emr-idc-lf.md)
# Configuração do Lake Formation para um cluster do EMR habilitado para o Centro de Identidade do IAM
Você pode se integrar [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/)ao seu cluster EMR Centro de Identidade do AWS IAM habilitado.
Primeiro, certifique-se de ter uma instância do Centro de Identidade configurada na mesma região do cluster. Para obter mais informações, consulte [Criação de uma instância do Centro de Identidade](emr-idc-start.md#emr-idc-start-instance). Você pode encontrar o ARN da instância no console do Centro de Identidade do IAM ao visualizar os detalhes da instância ou usar o seguinte comando para ver os detalhes de todas as instâncias na CLI:
```
aws sso-admin list-instances
```
Em seguida, use o ARN e o ID AWS da sua conta com o comando a seguir para configurar o Lake Formation para ser compatível com o IAM Identity Center:
```
aws lakeformation create-lake-formation-identity-center-configuration --cli-input-json file://create-lake-fromation-idc-config.json
json input:
{
"CatalogId": "account-id/org-account-id",
"InstanceArn": "identity-center-instance-arn"
}
```
Agora, chame `put-data-lake-settings` e habilite `AllowFullTableExternalDataAccess` com o Lake Formation:
```
aws lakeformation put-data-lake-settings --cli-input-json file://put-data-lake-settings.json
json input:
{
"DataLakeSettings": {
"DataLakeAdmins": [
{
"DataLakePrincipalIdentifier": "admin-ARN"
}
],
"CreateDatabaseDefaultPermissions": [...],
"CreateTableDefaultPermissions": [...],
"AllowExternalDataFiltering": true,
"AllowFullTableExternalDataAccess": true
}
}
```
Por fim, conceda permissões completas de tabela ao ARN da identidade do usuário que acessa o cluster do EMR. O ARN contém o ID do usuário do Centro de Identidade. Navegue até o Centro de Identidade no console, selecione **Usuários** e, em seguida, o usuário para visualizar as configurações de **Informações gerais**.
Copie o ID do usuário e cole-o no seguinte ARN para `user-id`:
```
arn:aws:identitystore:::user/user-id
```
**nota**
As consultas no cluster do EMR só funcionam se a identidade do Centro de Identidade do IAM tiver acesso total à tabela protegida do Lake Formation. Se a identidade não tiver acesso total à tabela, a consulta falhará.
Use o seguinte comando para conceder ao usuário acesso total à tabela:
```
aws lakeformation grant-permissions --cli-input-json file://grantpermissions.json
json input:
{
"Principal": {
"DataLakePrincipalIdentifier": "arn:aws:identitystore:::user/user-id"
},
"Resource": {
"Table": {
"DatabaseName": "tip_db",
"Name": "tip_table"
}
},
"Permissions": [
"ALL"
],
"PermissionsWithGrantOption": [
"ALL"
]
}
```
## Adicionar o ARN da aplicação ao IDC para integração com o Lake Formation
Para consultar os recursos habilitados para Lake Formation, o ARN da aplicação do IDC precisa ser adicionado. Para isso, siga estas etapas:
1. No console, escolha **AWS Lake Formation**.
1. Selecione **Integração com o Centro de Identidade do IAM** e **Integração com a aplicação Lake Formation**, correspondendo o ARN da aplicação. O ARN aparecerá na lista de **IDs de aplicação**.
# Como trabalhar com o S3 Access Grants em um cluster do EMR habilitado para o Centro de Identidade do IAM
Você pode integrar o [S3 Access Grants ao](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) seu cluster EMR Centro de Identidade do AWS IAM habilitado.
Use o S3 Access Grants para autorizar o acesso aos seus conjuntos de dados de clusters que usam o Centro de Identidade. Crie concessões para aumentar as permissões definidas para usuários, grupos e perfis do IAM ou para um diretório corporativo. Para obter mais informações, consulte [Using S3 Access Grants with Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-access-grants.html).
**Topics**
+ [Como criar uma instância e localização da funcionalidade S3 Access Grants](#emr-idc-s3ag-instance)
+ [Como criar concessões para identidades do Centro de Identidade](#emr-idc-s3ag-identities)
## Como criar uma instância e localização da funcionalidade S3 Access Grants
Se você ainda não tiver uma, crie uma instância do S3 Access Grants na Região da AWS em que deseja executar seu cluster do EMR.
Use o AWS CLI comando a seguir para criar uma nova instância chamada`MyInstance`:
```
aws s3control-access-grants create-access-grants-instance \
--account-id 12345678912 \
--identity-center-arn "identity-center-instance-arn" \
```
Em seguida, crie uma localização do S3 Access Grants, substituindo os valores vermelhos pelos seus próprios:
```
aws s3control-access-grants create-access-grants-location \
--account-id 12345678912 \
--location-scope s3:// \
--iam-role-arn "access-grant-role-arn" \
--region aa-example-1
```
**nota**
Defina o parâmetro `iam-role-arn` como o ARN `accessGrantRole`.
## Como criar concessões para identidades do Centro de Identidade
Por fim, crie as concessões das identidades que têm acesso ao seu cluster:
```
aws s3control-access-grants create-access-grant \
--account-id 12345678912 \
--access-grants-location-id "default" \
--access-grants-location-configuration S3SubPrefix="s3-bucket-prefix"
--permission READ \
--grantee GranteeType=DIRECTORY_USER,GranteeIdentifier="your-identity-center-user-id"
```
Exemplo de saída:
```
{
"CreatedAt": "2023-09-21T23:47:24.870000+00:00",
"AccessGrantId": "1234-12345-1234-1234567",
"AccessGrantArn": "arn:aws:s3:aa-example-1-1:123456789012:access-grants/default/grant/xxxx1234-1234-5678-1234-1234567890",
"Grantee": {
"GranteeType": "DIRECTORY_USER",
"GranteeIdentifier": "5678-56789-5678-567890"
},
"AccessGrantsLocationId": "default",
"AccessGrantsLocationConfiguration": {
"S3SubPrefix": "myprefix/*"
},
"Permission": "READ",
"GrantScope": "s3://myprefix/*"
}
```
# Sessões de usuário em segundo plano
As sessões em segundo plano do usuário permitem que os workloads de analytics e machine learning de longa duração continuem mesmo depois que o usuário se desconecta da interface do notebook. A partir do EMR na versão 7.11 do EC2, esse recurso está disponível por meio do recurso confiável de propagação de identidade do EMR-EC2. As seções a seguir explicam as opções de configuração e os comportamentos das sessões em segundo plano do usuário.
**nota**
As configurações da sessão em segundo plano do usuário afetam somente as cargas de trabalho do Spark iniciadas por meio do SageMaker Unified Studio. As alterações nessa configuração se aplicam às novas sessões do Livy — as sessões ativas existentes permanecem inalteradas.
## Configurar sessões de usuário em segundo plano
As sessões de usuário em segundo plano devem ser habilitadas em dois níveis para que funcionem adequadamente:
1. **Nível de instância do IAM Identity Center** (configurado pelos administradores do iDC)
1. **Nível de cluster do EMR** (configurado pelos administradores do cluster do EMR)
### Habilite sessões em segundo plano do usuário para o Amazon EMR
Para habilitar sessões em segundo plano do usuário, você deve definir o `userBackgroundSessionsEnabled` parâmetro como `true` no `identityCenterConfiguration` ao criar a configuração de segurança do EMR.
**Pré-requisitos:**
+ A função do IAM usada para criar ou atualizar a configuração de segurança do EMR requer a `sso:PutApplicationSessionConfiguration` permissão. Essa permissão permite sessões em segundo plano do usuário para o aplicativo IAM Identity Center gerenciado pelo Amazon EMR.
+ Crie uma função do IAM para o IAM Identity Center
+ Para integrar o Amazon EMR com o IAM Identity Center, crie uma função do IAM que se autentique com o IAM Identity Center a partir do cluster do EMR. O Amazon EMR usa credenciais SigV4 para retransmitir a identidade do IAM Identity Center para serviços posteriores, como. AWS Lake Formation Sua função também deve ter as permissões necessárias para invocar os serviços downstream.
+ [Configure o Lake Formation para um cluster EMR habilitado para o IAM Identity Center](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html). Para obter as permissões de função necessárias, consulte: [Criar uma função do IAM para o Identity Center.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-start.html#emr-idc-start-role)
+ Inicie seu cluster EMR com a versão 7.11 ou posterior e habilite a propagação de identidade confiável.
**Etapa 1 - Crie uma configuração de segurança do EMR UserBackgroundSession habilitada para o Identity Center**
Os usuários precisam definir **a `EnableUserBackgroundSession` bandeira como`true`, o** que permitirá que o serviço EMR seja ativado no nível do aplicativo IDC gerenciado pelo UserBackgourndSession EMR. Se esse sinalizador estiver definido como `false` ou não definido, o EMR desativará o IDC UserBackgroundSession por padrão.
**Exemplo de uso do AWS CLI:**
```
aws emr create-security-configuration --name "idc-userBackgroundSession-enabled-secConfig" \
--region AWS_REGION \
--security-configuration ' \
{
"AuthenticationConfiguration":{
"IdentityCenterConfiguration":{
"EnableIdentityCenter":true,
"IdentityCenterInstanceARN": "arn:aws:sso:::instance/ssoins-123xxxxxxxxxx789",
"IdentityCenterApplicationAssigmentRequired": false,
"EnableUserBackgroundSession": true,
"IAMRoleForEMRIdentityCenterApplicationARN": "arn:aws:iam::12345678912:role/YOUR_ROLE"
}
},\
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},\
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},\
"EncryptionConfiguration": {
"EnableInTransitEncryption": true,
"EnableAtRestEncryption": false,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://amzn-s3-demo-bucket/cert/my-certs.zip"
}
}
}
}'
```
**Etapa 2 - Criar e iniciar um cluster habilitado para o Identity Center**
Agora que configurou o perfil do IAM que se autentica ao Centro de Identidade e criou uma configuração de segurança do Amazon EMR com o Centro de Identidade habilitado, você pode criar e executar seu cluster com reconhecimento de identidade. Para ver as etapas para iniciar seu cluster com a configuração de segurança necessária, consulte Especificar uma configuração de segurança para um cluster do Amazon EMR.
### Matriz de configuração
O comportamento da sessão em segundo plano do usuário depende da configuração do EMR-EC2 e das configurações no nível da instância do IAM Identity Center:
**Matriz de configuração da sessão em segundo plano do usuário**
| Centro de identidade do IAM userBackgroundSession ativado | Habilitado para Amazon EMR userBackgroundSessions | Comportamento |
| --- | --- | --- |
| Sim | TRUE | Sessão em segundo plano do usuário ativada |
| Sim | FALSE | A sessão expira com o logout do usuário |
| Não | TRUE | A sessão expira com o logout do usuário |
| Não | FALSE | A sessão expira com o logout do usuário |
### Duração padrão das sessões de usuários em segundo plano
Por padrão, todas as sessões de usuário em segundo plano têm um limite de duração de 7 dias no Centro de Identidade do IAM. Os administradores podem modificar essa duração no console do Centro de Identidade do IAM. Essa configuração se aplica no nível da instância do Centro de Identidade do IAM, afetando todos os aplicativos do Centro de Identidade do IAM compatíveis nessa instância.
+ A duração pode ser definida para qualquer valor, de 15 minutos a 90 dias.
+ Essa configuração é definida no console do IAM Identity Center em **Configurações** → **Autenticação** → **Configurar** (consulte a seção Trabalhos não interativos)
### Impacto de desativar as sessões de usuário em segundo plano
Quando as sessões em segundo plano do usuário são desativadas no IAM Identity Center:
Sessões existentes do Livy
+ Continue a ser executado sem interrupção se eles tiverem sido iniciados com as sessões em segundo plano do usuário ativadas. Essas sessões continuarão usando seus tokens de sessão em segundo plano existentes até que terminem naturalmente ou sejam explicitamente interrompidas.
Novas sessões de Livy
+ Usará o fluxo padrão de propagação de identidade confiável e será encerrado quando o usuário se desconectar ou sua sessão interativa expirar (como ao fechar um notebook Amazon SageMaker Unified Studio JupyterLab).
### Alterando a duração das sessões de usuário em segundo plano
Quando a configuração de duração das sessões de usuário em segundo plano é modificada no Centro de Identidade do IAM:
Sessões existentes do Livy
+ Continue executando com a mesma duração da sessão em segundo plano com a qual eles foram iniciados.
Novas sessões de Livy
+ Usará a nova duração da sessão para sessões em segundo plano.
### Considerações
#### Disponibilidade de recursos
As sessões em segundo plano do usuário do Amazon EMR estão disponíveis para:
+ Somente motor Spark (o motor Hive não é suportado)
+ Somente sessões interativas do Livy (trabalhos em lote e trabalhos de streaming não são suportados)
+ O Amazon EMR lança as etiquetas 7.11 e versões posteriores. Com o EMR versão 7.11, você precisa instalar um script de ação bootstrap para habilitar sessões em segundo plano do usuário ao criar um cluster. Entre em contato com AWS o Support para obter mais detalhes.
**nota**
Se você estiver usando o cluster provisionado do SageMaker Unified Studio, não precisará do script de ação de bootstrap para usar esse recurso.
#### Implicações de custo
+ Os trabalhos continuarão sendo executados até a conclusão mesmo depois que os usuários encerrarem a JupyterLab sessão do Amazon SageMaker Unified Studio e incorrerão em cobranças por toda a duração da execução concluída.
+ Monitore suas sessões ativas em segundo plano para evitar custos desnecessários de sessões esquecidas ou abandonadas.
#### Condições de encerramento da sessão Livy
Ao usar sessões em segundo plano do usuário, uma sessão do Livy continuará em execução até que uma das seguintes situações ocorra:
+ A sessão em segundo plano do usuário expira (com base na configuração do iDC, em até 90 dias).
+ A sessão em segundo plano do usuário é revogada manualmente por um administrador.
+ A sessão do Livy atinge seu tempo limite de inatividade (padrão: 8 horas após a última instrução executada).
+ O usuário interrompe ou reinicia explicitamente o kernel do notebook.
# Considerações e limitações do Amazon EMR com a integração do Centro de Identidade
Considere os seguintes pontos ao usar o Centro de Identidade do IAM com o Amazon EMR:
+ A propagação de identidade confiável por meio do Centro de Identidade é compatível com o Amazon EMR 6.15.0 e versões superiores, somente com o Apache Spark. Além disso, a propagação de identidade confiável por meio do Identity Center usando o recurso de perfis de runtime do EMR é compatível com o Amazon EMR 7.8.0 e versões superiores, e somente com o Apache Spark.
+ Para habilitar clusters do EMR com propagação de identidade confiável, você deve usar o AWS CLI para criar uma configuração de segurança que tenha a propagação de identidade confiável ativada e usar essa configuração de segurança ao iniciar seu cluster. Para obter mais informações, consulte [Criação de uma configuração de segurança habilitada para o Centro de Identidade](emr-idc-start.md#emr-idc-start-securityconfig).
+ Controles de acesso refinados AWS Lake Formation que usam o Trusted Identity Propagation estão disponíveis para clusters do Amazon EMR na versão 7.2.0 e superior do EMR. Entre as versões 6.15.0 e 7.1.0 do EMR, somente o controle de acesso em nível de tabela, baseado no Lake Formation, está disponível. AWS
+ Com clusters do Amazon EMR que usam a Propagação de identidade confiável, as operações que oferecem suporte ao controle de acesso baseado no Lake Formation com o Apache Spark incluem SELECT, ALTER TABLE, INSERT INTO e DROP TABLE.
+ Controles de acesso refinados AWS Lake Formation que usam o Trusted Identity Propagation precisarão atualizar a configuração do Lake Formation Identity Center adicionando o aplicativo IAM Identity gerenciado pelo EMR, arn, como alvo autorizado. Você pode encontrar o ARN da aplicação de identidade do IAM gerenciada pelo Amazon EMR chamando a API `describe-security-configure` do EMR e procurando o campo `IdCApplicationARN`. Mais detalhes: [Atualizar a integração com o Centro de Identidade do IAM](https://docs.aws.amazon.com/lake-formation/latest/dg/update-lf-identity-center-connection.html) sobre como configurar o Lake Formation com a configuração do Centro de Identidade do IAM.
+ Para usar controles de acesso refinados usando AWS Lake Formation o Trusted Identity Propagation, os usuários do IAM Identity devem receber permissões do Lake Formation no banco de dados padrão. Mais detalhes: [Configurar o Lake Formation para um cluster EMR habilitado para o Centro de Identidade do IAM](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html).
+ A propagação de identidade confiável com o Amazon EMR é suportada no seguinte: Regiões da AWS
+ `af-south-1`: África (Cidade do Cabo)
+ `ap-east-1`: Ásia-Pacífico (Hong Kong)
+ `ap-northeast-1`: Ásia-Pacífico (Tóquio)
+ `ap-northeast-2`: Ásia-Pacífico (Seul)
+ `ap-northeast-3`: Asia Pacific (Osaka)
+ `ap-south-1`: Ásia-Pacífico (Mumbai)
+ `ap-south-2`: Ásia-Pacífico (Hyderabad)
+ `ap-southeast-1`: Ásia-Pacífico (Singapura)
+ `ap-southeast-2`: Ásia-Pacífico (Sydney)
+ `ap-southeast-3`: Ásia-Pacífico (Jacarta)
+ `ap-southeast-4`: Ásia-Pacífico (Melbourne)
+ `ca-central-1`: Canadá (Central)
+ `eu-central-1`: Europa (Frankfurt)
+ `eu-central-2`: Europa (Zurique)
+ `eu-north-1`: Europa (Estocolmo)
+ `eu-south-1`: Europa (Milão)
+ `eu-south-2`: Europa (Espanha)
+ `eu-west-1`: Europa (Irlanda)
+ `eu-west-2`: Europa (Londres)
+ `eu-west-3`: Europa (Paris)
+ `il-central-1`: Israel (Tel Aviv)
+ `me-central-1`: Oriente Médio (EAU)
+ `me-south-1`: Oriente Médio (Bahrein)
+ `sa-east-1`: América do Sul (São Paulo)
+ `us-east-1`: Leste dos EUA (Norte da Virgínia)
+ `us-east-2`: Leste dos EUA (Ohio)
+ `us-west-1`: Oeste dos EUA (Norte da Califórnia)
+ `us-west-2`: Oeste dos EUA (Oregon)
+ Se a função do IAM para a função do centro de identidade for excluída e recriada acidentalmente, o principal terá uma ID principal diferente. O exemplo *NewRole* teria principal-id *456* que não corresponderia ao principal-id registrado. *123* A única maneira de resolver isso neste momento é redefinir o principal nas políticas de recursos downstream em cada conta downstream.
# Integre o Amazon EMR com AWS Lake Formation
AWS Lake Formation é um serviço gerenciado que ajuda você a descobrir, catalogar, limpar e proteger dados em um data lake do Amazon Simple Storage Service (S3). O Lake Formation fornece acesso refinado no nível da coluna, linha ou célula aos bancos de dados e tabelas no AWS Glue Data Catalog. Para ter mais informações, consulte [O que é o AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Com o Amazon EMR 6.7.0 e versões posteriores, você pode aplicar o controle de acesso baseado no Lake Formation a trabalhos do Spark, Hive e Presto enviados aos clusters do Amazon EMR. Para se integrar ao Lake Formation, é necessário criar um cluster do EMR com um *perfil de runtime*. O perfil de runtime é um perfil do AWS Identity and Access Management (IAM) que você associa a trabalhos ou consultas do Amazon EMR. Em seguida, o Amazon EMR usa essa função para acessar AWS recursos. Para obter mais informações, consulte [Perfis de runtime para etapas ao Amazon EMR](emr-steps-runtime-roles.md).
## Como o Amazon EMR funciona com o Lake Formation
Depois de integrar o Amazon EMR com o Lake Formation, você pode executar consultas nos clusters do Amazon EMR com a [`Step`API](https://docs.aws.amazon.com/emr/latest/APIReference/API_Step.html) ou com o AI Studio. SageMaker Em seguida, o Lake Formation fornecerá acesso aos dados por meio de credenciais temporárias para o Amazon EMR. Esse processo chamado de fornecimento de credenciais. Para ter mais informações, consulte [O que é o AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Veja a seguir uma visão geral de alto nível sobre como o Amazon EMR obtém acesso aos dados protegidos pelas políticas de segurança do Lake Formation.
![\[Como o Amazon EMR acessa dados protegidos por meio de políticas de segurança do Lake Formation\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/lf-emr-security.png)
1. O usuário envia uma consulta do Amazon EMR para obter dados no Lake Formation.
1. O Amazon EMR solicita credenciais temporárias do Lake Formation para dar acesso aos dados para o usuário.
1. O Lake Formation retorna credenciais temporárias.
1. O Amazon EMR envia a solicitação de consulta para recuperar dados do Amazon S3.
1. O Amazon EMR recebe os dados do Amazon S3, filtra-os e retorna os resultados com base nas permissões de usuário que o usuário definiu no Lake Formation.
Para obter mais informações sobre como adicionar usuários e grupos às políticas do Lake Formation, consulte [Granting Data Catalog permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
## Pré-requisitos
É necessário atender aos seguintes requisitos para integrar o Amazon EMR e o Lake Formation:
+ Ative a autorização do perfil de runtime no cluster do Amazon EMR.
+ Use o AWS Glue Data Catalog como seu armazenamento de metadados.
+ Defina e gerencie permissões no Lake Formation para acessar bancos de dados, tabelas e colunas no AWS Glue Data Catalog. Para ter mais informações, consulte [O que é o AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
# Acesso refinado com o Lake Formation
As versões 6.15.0 e superiores do Amazon EMR incluem suporte para controle de acesso refinado no nível de linha, coluna ou célula com base no Lake Formation. AWS Os tópicos desta seção abordam como você pode acessar tabelas do Catálogo de dados do Glue protegidas pelo Lake Formation a partir de trabalhos Spark do EMR ou sessões interativas com controle de acesso refinado.
# Habilitar o Lake Formation com o Amazon EMR
Com o Amazon EMR 6.15.0 e versões posteriores, ao executar trabalhos do Spark no Amazon EMR em clusters EC2 que acessam dados no AWS Glue Data Catalog, você pode AWS Lake Formation usar para aplicar permissões em nível de tabela, linha, coluna e célula em tabelas baseadas em Hudi, Iceberg ou Delta Lake.
Nesta seção, abordamos como criar uma configuração de segurança e configurar o Lake Formation para trabalhar com o Amazon EMR. Também veremos como iniciar um cluster com a configuração de segurança criada para o Lake Formation.
## Etapa 1: configurar um perfil de runtime para o cluster do EMR
Para usar um perfil de runtime para o cluster do EMR, é necessário criar uma configuração de segurança. Com uma configuração de segurança, você pode aplicar opções consistentes de segurança, autorização e autenticação nos clusters.
1. Crie um arquivo chamado `lf-runtime-roles-sec-cfg.json` com a configuração a seguir.
```
{
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},
"EncryptionConfiguration": {
"EnableAtRestEncryption": false,
"EnableInTransitEncryption": true,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {}
}
}
}
```
O exemplo abaixo ilustra como usar um arquivo zip com certificados no Amazon S3 para configuração de certificados:
+ Um arquivo zip com certificados no Amazon S3 é usado como provedor de chaves. (Consulte [Fornecer certificados para criptografia de dados em trânsito com a criptografia do Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) para conhecer os requisitos necessários.)
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://MyConfigStore/artifacts/MyCerts.zip"
}
```
O exemplo abaixo ilustra como usar um provedor de chaves personalizado para a configuração do certificado:
+ Um provedor de chave personalizado é usado. (Consulte [Fornecer certificados para criptografia de dados em trânsito com a criptografia do Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) para conhecer os requisitos necessários.)
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "Custom",
"S3Object": "s3://MyConfig/artifacts/MyCerts.jar",
"CertificateProviderClass": "com.mycompany.MyCertProvider"
}
```
1. Em seguida, para garantir que a etiqueta da sessão possa autorizar o Lake Formation, defina a propriedade `LakeFormationConfiguration/AuthorizedSessionTagValue` como `Amazon EMR`.
1. Use o comando a seguir para criar uma configuração de segurança do Amazon EMR.
```
aws emr create-security-configuration \
--name 'iamconfig-with-iam-lf' \
--security-configuration file://lf-runtime-roles-sec-cfg.json
```
Como alternativa, é possível usar o [console do Amazon EMR](https://console.aws.amazon.com//emr) para criar uma configuração de segurança com configurações personalizadas.
## Etapa 2: iniciar um cluster do Amazon EMR
Agora, você já pode iniciar um cluster do EMR com a configuração de segurança criada na etapa anterior. Para obter mais informações sobre configurações de segurança, consulte [Uso de configurações de segurança para definir a segurança do cluster do Amazon EMR](emr-security-configurations.md) e [Perfis de runtime para etapas ao Amazon EMR](emr-steps-runtime-roles.md).
## Etapa 3: configurar permissões no nível de coluna, linha ou célula baseadas no Lake Formation com perfis de runtime do Amazon EMR
Para aplicar um controle de acesso refinado no nível de coluna, linha ou célula com o Lake Formation, o administrador do data lake no Lake Formation deve definir `Amazon EMR` como valor da configuração da etiqueta de sessão, `AuthorizedSessionTagValue`. O Lake Formation usa essa etiqueta de sessão para autorizar os chamadores e fornecer acesso ao data lake. É possível definir essa etiqueta de sessão na seção **Configurações de integração de aplicações** do console do Lake Formation. *123456789012*Substitua por seu próprio Conta da AWS ID.
## Etapa 4: Configurar subsídios do AWS Glue e do Lake Formation para funções de tempo de execução do Amazon EMR
Para continuar com a configuração do controle de acesso baseado em Lake Formation com funções de tempo de execução do Amazon EMR, você deve configurar subsídios do AWS Glue e do Lake Formation para funções de tempo de execução do Amazon EMR. Para permitir que os perfis de runtime do IAM interajam com o Lake Formation, conceda a eles acesso com `lakeformation:GetDataAccess` e `glue:Get*`.
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 na API `glue:Get*`. Para obter mais detalhes sobre o controle de acesso do Lake Formation, consulte a [visão geral do controle de acesso do Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-overview.html).
1. Crie o arquivo `emr-runtime-roles-lake-formation-policy.json` com o conteúdo a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LakeFormationManagedAccess",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"glue:Get*",
"glue:Create*",
"glue:Update*"
],
"Resource": [
"*"
]
}
]
}
```
------
1. Crie a política do IAM relacionada ao IAM.
```
aws iam create-policy \
--policy-name emr-runtime-roles-lake-formation-policy \
--policy-document file://emr-runtime-roles-lake-formation-policy.json
```
1. Para atribuir essa política aos perfis de runtime do IAM, siga as etapas descritas em [Managing AWS Lake Formation permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html).
Já é possível usar perfis de runtime e o Lake Formation para aplicar permissões em nível de tabela e coluna. Você também pode usar uma identidade de origem para controlar ações e monitorar operações com AWS CloudTrail.
Para cada perfil do IAM que você pretende usar como perfil de runtime, defina a política de confiança a seguir, substituindo `EMR_EC2_DefaultRole` pelo perfil do perfil de instância. Para modificar a política de confiança de um perfil do IAM, consulte [Modificar a política de confiança de um perfil](https://docs.aws.amazon.com//IAM/latest/UserGuide/roles-managingrole-editing-console.html).
```
{
"Sid":"AllowAssumeRole",
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam:::role/EMR_EC2_DefaultRole"
},
"Action":[
"sts:AssumeRole",
"sts:TagSession"
]
}
```
Para obter um end-to-end exemplo detalhado, consulte [Introdução às funções de tempo de execução para as etapas do Amazon EMR.](https://aws.amazon.com/blogs/big-data/introducing-runtime-roles-for-amazon-emr-steps-use-iam-roles-and-aws-lake-formation-for-access-control-with-amazon-emr/)
Para obter informações sobre como fazer a integração com o Iceberg e o AWS Glue Data Catalog para uma hierarquia de vários catálogos, consulte [Configurar o Spark para acessar uma hierarquia de vários catálogos no Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html#emr-lakehouse-using-spark-access). AWS
# Suporte ao formato de tabela aberta
As versões 6.15.0 e superiores do Amazon EMR incluem suporte para controle de acesso refinado AWS Lake Formation com base em tabelas do Hive, Apache Iceberg, Apache Hudi e Delta Lake quando você lê e grava dados com o Spark SQL. O Amazon EMR oferece suporte ao controle de acesso no nível de tabela, linha, coluna e célula com o Apache Hudi. As versões 6.15.0 e superiores do Amazon EMR incluem suporte para controle de acesso refinado em nível de linha, coluna ou célula com base no AWS Lake Formation. A partir do EMR 7.12, as operações DML e DDL que modificam os dados da tabela são suportadas nas tabelas Apache Hive, Apache Iceberg e Delta Lake usando credenciais vendidas do Lake Formation.
Os tópicos desta seção abordam como você pode acessar as tabelas registradas do Lake Formation em formatos de tabela aberta a partir de trabalhos do EMR Spark ou sessões interativas com controle de acesso refinado.
## Requisitos de permissão
### Tabelas não registradas em AWS Lake Formation
Para tabelas não registradas AWS Lake Formation, a função de tempo de execução do trabalho acessa o AWS Glue Data Catalog e os dados da tabela subjacente no Amazon S3. Isso exige que a função de tempo de execução do trabalho tenha as permissões apropriadas do IAM para as operações do AWS Glue e do Amazon S3.
### Tabelas cadastradas em AWS Lake Formation
Para tabelas registradas com AWS Lake Formation, a função de tempo de execução do trabalho acessa os metadados do AWS Glue Data Catalog, enquanto as credenciais temporárias fornecidas pela Lake Formation acessam os dados da tabela subjacente no Amazon S3. As permissões do Lake Formation necessárias para executar uma operação dependem do AWS Glue Data Catalog e das chamadas de API do Amazon S3 iniciadas pelo trabalho do Spark e podem ser resumidas da seguinte forma:
+ A permissão **DESCRIBE** permite que a função de tempo de execução leia os metadados da tabela ou do banco de dados no Catálogo de Dados
+ A permissão **ALTER** permite que a função de tempo de execução modifique os metadados da tabela ou do banco de dados no Catálogo de Dados
+ A permissão **DROP** permite que a função de tempo de execução exclua metadados da tabela ou do banco de dados do Catálogo de Dados
+ A permissão **SELECT** permite que a função de tempo de execução leia dados da tabela do Amazon S3
+ A permissão **INSERT** permite que a função de tempo de execução grave dados de tabela no Amazon S3
+ A permissão **DELETE** permite que a função de tempo de execução exclua dados da tabela do Amazon S3
**nota**
O Lake Formation avalia as permissões preguiçosamente quando um trabalho do Spark chama o AWS Glue para recuperar os metadados da tabela e o Amazon S3 para recuperar os dados da tabela. Trabalhos que usam uma função de tempo de execução com permissões insuficientes não falharão até que o Spark faça uma chamada ao AWS Glue ou ao Amazon S3 que exija a permissão ausente.
**nota**
Na seguinte matriz de tabela suportada:
As operações marcadas como **Suportadas** usam exclusivamente as credenciais do Lake Formation para acessar os dados das tabelas registradas no Lake Formation. Se as permissões do Lake Formation forem insuficientes, a operação não retornará às credenciais da função de tempo de execução. Para tabelas não registradas no Lake Formation, as credenciais da função de tempo de execução do trabalho acessam os dados da tabela.
As operações marcadas como **compatíveis com permissões do IAM na localização do Amazon S3** não usam as credenciais do Lake Formation para acessar os dados da tabela subjacente no Amazon S3. Para executar essas operações, a função de tempo de execução do trabalho deve ter as permissões necessárias do Amazon S3 IAM para acessar os dados da tabela, independentemente de a tabela estar registrada no Lake Formation.
------
#### [ Hive ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-lf-fgac1.html)
------
#### [ Iceberg ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuração do Spark para Iceberg:** Se você quiser usar o formato Iceberg, defina as seguintes configurações. Substitua `DB_LOCATION` pelo caminho do Amazon S3 onde suas tabelas do Iceberg estão localizadas e os espaços reservados para a região e o ID da conta por seus próprios valores.
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.region=AWS_REGION
```
Se quiser usar o formato do Iceberg em versões anteriores do EMR, use o seguinte comando:
```
spark-sql \
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=s3://DB_LOCATION
--conf spark.sql.catalog.spark_catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog
--conf spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.client.assume-role.region=AWS_REGION
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Exemplos:**
Aqui estão alguns exemplos de como trabalhar com tabelas Iceberg:
```
-- Create an Iceberg table
CREATE TABLE my_iceberg_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING ICEBERG;
-- Insert data
INSERT INTO my_iceberg_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_iceberg_table;
```
------
#### [ Hudi ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuração do Spark para Hudi:**
Para iniciar o shell Spark no EMR 7.10 ou versões superiores, use o comando a seguir:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
```
Para iniciar o shell Spark em versões anteriores do EMR, use o comando abaixo em vez disso:
```
spark-sql
--jars /usr/lib/hudi/hudi-spark-bundle.jar \
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog \
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
**Exemplos:**
Aqui estão alguns exemplos de como trabalhar com tabelas Hudi:
```
-- Create a Hudi table
CREATE TABLE my_hudi_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING HUDI
TBLPROPERTIES (
'type' = 'cow',
'primaryKey' = 'id'
);
-- Insert data
INSERT INTO my_hudi_table VALUES (1, 'Alice', current_timestamp());
-- Query the latest snapshot
SELECT * FROM my_hudi_table;
```
Para consultar o último instantâneo das copy-on-write tabelas:
```
SELECT * FROM my_hudi_cow_table
```
```
spark.read.table("my_hudi_cow_table")
```
Para consultar os dados compactados mais recentes das tabelas `MOR`, você pode consultar a tabela otimizada para leitura que tem o sufixo `_ro`:
```
SELECT * FROM my_hudi_mor_table_ro
```
```
spark.read.table("my_hudi_mor_table_ro")
```
------
#### [ Delta Lake ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuração do Spark para Delta Lake:**
Para usar o Delta Lake com o Lake Formation no EMR 7.10 e superior, execute o seguinte comando:
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog
```
Para usar o Delta Lake com o Lake Formation no EMR 6.15 a 7.9, execute o seguinte
```
spark-sql \
--conf spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension,com.amazonaws.emr.recordserver.connector.spark.sql.RecordServerSQLExtension \
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog \
--conf spark.sql.catalog.spark_catalog.lf.managed=true
```
Se quiser que o Lake Formation use o servidor de registros para gerenciar o catálogo do Spark, defina `spark.sql.catalog..lf.managed` como verdadeiro.
**Exemplos:**
Aqui estão alguns exemplos de como trabalhar com tabelas Delta Lake:
```
-- Create a Delta Lake table
CREATE TABLE my_delta_table (
id BIGINT,
name STRING,
created_at TIMESTAMP
) USING DELTA;
-- Insert data
INSERT INTO my_delta_table VALUES (1, 'Alice', current_timestamp());
-- Query the table
SELECT * FROM my_delta_table;
-- Update data
UPDATE my_delta_table SET name = 'Alice Smith' WHERE id = 1;
-- Merge data
MERGE INTO my_delta_table AS target
USING (SELECT 2 as id, 'Bob' as name, current_timestamp() as created_at) AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;
```
**Criação de uma tabela Delta Lake no AWS Glue Data Catalog**
O Amazon EMR com Lake Formation não oferece suporte a comandos DDL e à criação de tabelas Delta em versões do EMR anteriores à 7.12. Siga estas etapas para criar tabelas no AWS Glue Data Catalog.
1. Use o exemplo a seguir para criar uma tabela do Delta. Certifique-se de que sua localização no S3 exista.
```
spark-sql \
--conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \
--conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"
> CREATE DATABASE if not exists LOCATION 's3:///transactionaldata/native-delta//';
> CREATE TABLE (x INT, y STRING, z STRING) USING delta;
> INSERT INTO VALUES (1, 'a1', 'b1');
```
1. Para ver os detalhes da sua mesa, acesse [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. No painel de navegação à esquerda, expanda **Data Catalog**, escolha **Tabelas** e a tabela que você criou. Em **Esquema**, você verá que a tabela Delta que você criou com o Spark armazena todas as colunas em um tipo de dados do `array` AWS Glue.
1. Para definir filtros em nível de coluna e célula no Lake Formation, remova a coluna `col` do esquema e, em seguida, adicione as colunas que estão no esquema da tabela. Neste exemplo, adicione as colunas `x`, `y` e `z`.
------
Com esse recurso, você pode executar consultas de instantâneos em copy-on-write tabelas para consultar o instantâneo mais recente da tabela em um determinado instante de confirmação ou compactação. Atualmente, um cluster do Amazon EMR habilitado pelo Lake Formation deve recuperar a coluna de tempo de confirmação do Hudi para realizar consultas incrementais e consultas de viagem no tempo. Ele não é compatível com a sintaxe `timestamp as of` e a função `Spark.read()` do Spark. A sintaxe correta é `select * from table where _hoodie_commit_time <= point_in_time`. Para obter mais informações, consulte [Point in time Time-Travel queries on Hudi table](https://cwiki.apache.org/confluence/display/HUDI/RFC+-+07+%3A+Point+in+time+Time-Travel+queries+on+Hudi+table).
**nota**
A performance das leituras nos clusters do Lake Formation pode ser mais lenta devido às otimizações sem suporte. Esses atributos incluem listagem de arquivos com base nos metadados do Hudi e salto de dados. É recomendável testar a performance da aplicação para garantir que ela atenda aos seus requisitos.
# Trabalho com vizualizações do Catálogo de dados do Glue no Amazon EMR
**nota**
A criação e o gerenciamento de visualizações do AWS Glue Data Catalog para uso com o EMR no EC2 estão disponíveis com o Amazon [EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-7100-release.html) versão 7.10.0 e versões posteriores.
Você pode criar e gerenciar visualizações no AWS Glue Data Catalog para uso com o EMR no EC2. Elas são comumente conhecidas como visualizações do AWS Glue Data Catalog. Essas visualizações são úteis porque oferecem suporte a vários mecanismos de consulta SQL, para que você possa acessar a mesma visualização em diferentes AWS serviços, como EMR no EC2 e Amazon Redshift. Amazon Athena
Ao criar uma exibição no Catálogo de Dados, você pode usar concessões de recursos e controles de acesso baseados em tags AWS Lake Formation para conceder acesso a ela. Usando esse método de controle de acesso, você não precisa configurar acesso adicional às tabelas referenciadas ao criar a exibição. Esse método de concessão de permissões é chamado de semântica definidora, e essas exibições são chamadas de vizualizações definidoras. Para obter mais informações sobre o controle de acesso no Lake Formation, consulte [Conceder e revogar permissões nos recursos do Catálogo de Dados no](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html) Guia do Desenvolvedor do AWS Lake Formation.
As vizualizações do Data Catalog são úteis para os seguintes casos de uso:
+ **Controle de acesso granular**: é possível criar uma visualização que restringe o acesso aos dados com base nas permissões necessárias ao usuário. Por exemplo, você pode usar as exibições do Data Catalog para evitar que funcionários que não trabalham no departamento de RH vejam informações de identificação pessoal (PII).
+ **Definição completa da exibição**: ao aplicar filtros à sua visualização no Catálogo de dados, você garante que os registros de dados em uma exibição do Catálogo de dados estejam sempre completos.
+ **Segurança aprimorada**: a definição da consulta usada para criar a exibição deve estar completa. Esse benefício significa que as vizualizações no Data Catalog não são suscetíveis a comandos SQL de acessos mal-intencionados.
+ **Compartilhamento simples de dados** — compartilhe dados com outras AWS contas sem mover dados. Para obter mais informações, consulte [Cross-account data sharing in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html).
## Criação de uma visualização do Catálogo de Dados
Há maneiras diferentes de criar uma exibição do Catálogo de dados. Isso inclui o uso do AWS CLI ou do Spark SQL. Veja alguns exemplos.
------
#### [ Using SQL ]
Veja a seguir a sintaxe para a criação de uma exibição do Catálogo de dados. Observe o tipo de visualização `MULTI DIALECT`. Isso distingue a exibição do Catálogo de dados de outras visualizações. O predicado `SECURITY` é especificado como `DEFINER`. Isso indica uma visualização do Catálogo de dados com semântica `DEFINER`.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW [IF NOT EXISTS] view_name
[(column_name [COMMENT column_comment], ...) ]
[ COMMENT view_comment ]
[TBLPROPERTIES (property_name = property_value, ... )]
SECURITY DEFINER
AS query;
```
Veja a seguir um exemplo de instrução `CREATE`, seguindo a sintaxe:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY order_date
```
Você também pode criar uma exibição no modo de simulação, usando SQL, para testar a criação da exibição, sem realmente criar o recurso. O uso dessa opção resulta em uma “execução seca” que valida a entrada e, se a validação for bem-sucedida, retorna o JSON do objeto da tabela AWS Glue que representará a visualização. Nesse caso, a visualização real não é criada.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW view_name
SECURITY DEFINER
[ SHOW VIEW JSON ]
AS view-sql
```
------
#### [ Using the AWS CLI ]
**nota**
Quando você usa o comando da CLI, o SQL usado para criar a exibição não é analisado. Isso pode resultar em um caso em que a exibição é criada, mas as consultas não são bem-sucedidas. Certifique-se de testar sua sintaxe SQL antes de criar a exibição.
Use o seguinte comando da CLI para criar uma visualização:
```
aws glue create-table --cli-input-json '{
"DatabaseName": "database",
"TableInput": {
"Name": "view",
"StorageDescriptor": {
"Columns": [
{
"Name": "col1",
"Type": "data-type"
},
...
{
"Name": "col_n",
"Type": "data-type"
}
],
"SerdeInfo": {}
},
"ViewDefinition": {
"SubObjects": [
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-table1",
...
"arn:aws:glue:aws-region:aws-account-id:table/database/referenced-tableN",
],
"IsProtected": true,
"Representations": [
{
"Dialect": "SPARK",
"DialectVersion": "1.0",
"ViewOriginalText": "Spark-SQL",
"ViewExpandedText": "Spark-SQL"
}
]
}
}
}'
```
------
## Operações compatíveis para visualizações
Os fragmentos de comandos apresentados a seguir mostram como é possível trabalhar com as visualizações do Catálogo de Dados de diferentes formas:
+ **CREATE VIEW**
Cria uma visualização do Catálogo de Dados. A seguir, um exemplo que demonstra a criação da visualização usando uma tabela existente:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER AS SELECT * FROM my_catalog.my_database.source_table
```
+ **ALTER VIEW**
Sintaxe disponível:
+ `ALTER VIEW view_name [FORCE] ADD DIALECT AS query`
+ `ALTER VIEW view_name [FORCE] UPDATE DIALECT AS query`
+ `ALTER VIEW view_name DROP DIALECT`
É possível usar a opção `FORCE ADD DIALECT` para aplicar a atualização do esquema e dos objetos secundários de acordo com o novo dialeto do mecanismo. Lembre-se de que essa ação pode resultar em erros de consulta, caso a opção `FORCE` não seja usada para atualizar os demais dialetos do mecanismo. A seguir, um exemplo que demonstra a aplicação:
```
ALTER VIEW catalog_view FORCE ADD DIALECT
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY orderdate;
```
A seguir, um exemplo que demonstra a alteração de uma visualização para a atualização do dialeto:
```
ALTER VIEW catalog_view UPDATE DIALECT AS
SELECT count(*) FROM my_catalog.my_database.source_table;
```
+ **DESCRIBE VIEW**
Sintaxe disponível para descrever uma visualização:
+ `SHOW COLUMNS {FROM|IN} view_name [{FROM|IN} database_name]`— Se o usuário tiver as permissões necessárias de AWS Glue e Lake Formation para descrever a visualização, ele poderá listar as colunas. A seguir, alguns exemplos de comandos que demonstram como visualizar colunas:
```
SHOW COLUMNS FROM my_database.source_table;
SHOW COLUMNS IN my_database.source_table;
```
+ `DESCRIBE view_name`— Se o usuário tiver as permissões necessárias de AWS Glue e Lake Formation para descrever a visualização, ele poderá listar as colunas na exibição junto com seus metadados.
+ **DROP VIEW**
Sintaxe disponível:
+ `DROP VIEW [ IF EXISTS ] view_name`
A seguir, um exemplo de instrução `DROP` que demonstra como realizar um teste para verificar a existência da visualização antes de sua remoção:
```
DROP VIEW IF EXISTS catalog_view;
```
+ **MOSTRAR CRIAR VISUALIZAÇÃO**
+ `SHOW CREATE VIEW view_name`: mostra a instrução SQL responsável pela criação da visualização especificada. A seguir, um exemplo que demonstra o processo de criação de uma visualização no Catálogo de Dados:
```
SHOW CREATE TABLE my_database.catalog_view;
CREATE PROTECTED MULTI DIALECT VIEW my_catalog.my_database.catalog_view (
net_profit,
customer_id,
item_id,
sold_date)
TBLPROPERTIES (
'transient_lastDdlTime' = '1736267222')
SECURITY DEFINER AS SELECT * FROM
my_database.store_sales_partitioned_lf WHERE customer_id IN (SELECT customer_id from source_table limit 10)
```
+ **SHOW VIEWS**
Lista todas as visualizações existentes no catálogo, incluindo as visualizações regulares, as visualizações com múltiplos dialetos (MDV, na sigla em inglês) e as MDVs sem suporte ao dialeto Spark. A sintaxe disponível é a seguinte:
+ `SHOW VIEWS [{ FROM | IN } database_name] [LIKE regex_pattern]`:
A seguir, um exemplo que demonstra um comando para mostrar as visualizações:
```
SHOW VIEWS IN marketing_analytics LIKE 'catalog_view*';
```
Para obter mais informações sobre como criar e configurar visualizações do catálogo de dados, consulte Como criar visualizações do catálogo de [dados do AWS Glue no Guia](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html) do AWS Lake Formation desenvolvedor.
## Consulta de uma visualização do Catálogo de Dados
Depois de criar uma visualização do catálogo de dados, você pode consultá-la usando uma tarefa do Amazon EMR Spark que tenha um controle de acesso AWS Lake Formation refinado ativado. O perfil de runtime do trabalho deve ter a permissão `SELECT` do Lake Formation na visualização do Catálogo de dados. Não é necessário conceder acesso às tabelas subjacentes referenciadas na visualização.
Depois de configurar tudo, você pode consultar sua exibição. Por exemplo, depois de criar uma aplicação do Amazon EMR no EMR Studio, é possível executar a consulta a seguir para acessar uma exibição.
```
SELECT * from my_database.catalog_view LIMIT 10;
```
Uma função útil é `invoker_principal`. Ela retorna o identificador exclusivo do perfil de runtime do trabalho do EMRS. Isso pode ser usado para controlar a saída da visualização, com base na entidade principal de invocação. Você pode usar isso para adicionar uma condição à sua visualização que refina os resultados da consulta, com base no perfil de chamada. O perfil de runtime do trabalho deve ter permissão para a ação `LakeFormation:GetDataLakePrincipal` do IAM usar essa função.
```
select invoker_principal();
```
Você pode adicionar essa função a uma cláusula `WHERE`, por exemplo, para refinar os resultados da consulta.
## Considerações e limitações
Quando você cria exibições do Catálogo de dados, o seguinte se aplica:
+ Você só pode criar exibições do Catálogo de dados com o Amazon EMR 7.10 e versões superiores.
+ O responsável pela definição da visualização do Catálogo de Dados deve ter permissão de acesso `SELECT` nas tabelas de base subjacentes acessadas pela visualização. A operação de criação da visualização do Catálogo de Dados não será bem-sucedida caso uma das tabelas de base tenha filtros do Lake Formation atribuídos ao perfil “definer”.
+ As tabelas de base não devem ter a permissão de data lake `IAMAllowedPrincipals` no Lake Formation. Se presente, o erro de *visualizações de vários dialetos só pode fazer referência a tabelas sem a permissão do IAMAllowed Principal.*
+ A localização da tabela no Amazon S3 deve ser registrada como uma localização de data lake do Lake Formation. Se a tabela não estiver registrada, o erro *Visualizações de vários dialetos só podem fazer referência a tabelas gerenciadas pelo Lake Formation* ocorrerá. Para obter informações sobre como registrar locais do Amazon S3 em Lake Formation, consulte [Registro de um local do Amazon S3](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html) no Guia do desenvolvedor. AWS Lake Formation
+ Você só pode criar vizualizações `PROTECTED` do Data Catalog. Não há suporte para exibições `UNPROTECTED`.
+ Você não pode referenciar tabelas em outra AWS conta em uma definição de exibição do Catálogo de Dados. Além disso, não é possível referenciar uma tabela da mesma conta que esteja em uma região diferente.
+ Para compartilhar dados entre contas ou regiões, a visualização inteira deve ser compartilhada entre contas e entre regiões, usando links de recurso do Lake Formation.
+ As funções definidas pelo usuário (UDFs) não são suportadas.
+ É possível usar visualizações baseadas em tabelas do Iceberg. Os formatos de tabela aberta Apache Hudi e Delta Lake também são compatíveis.
+ Não é possível fazer referência a outras vizualizações nas exibições do Data Catalog.
+ Um esquema de visualização do AWS Glue Data Catalog é sempre armazenado em letras minúsculas. Por exemplo, se você usar uma instrução DDL para criar uma exibição do Catálogo de dados do Glue com uma coluna chamada `Castle`, a coluna criada no Catálogo de dados do Glue será transformada em minúsculas, para `castle`. Se você especificar o nome da coluna em uma consulta DML como `Castle` ou `CASTLE`, o EMR Spark mudará o nome para letras minúsculas para você executar a consulta. Porém, o título da coluna é exibido usando as letras maiúsculas e minúsculas que você especificou na consulta.
Se quiser que uma consulta falhe em um caso em que o nome da coluna especificado na consulta DML não corresponda ao nome da coluna no Catálogo de dados do Glue, você pode definir `spark.sql.caseSensitive=true`.
# Considerações sobre o Amazon EMR com o Lake Formation
O Amazon EMR com Lake Formation está disponível em [todas as regiões disponíveis](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-region.html).
## Considerações sobre o Amazon EMR com Lake Formation para a versão 7.9 e anteriores
Considere o seguinte ao usar AWS Lake Formation no EMR 7.9 e versões anteriores.
+ O [controle de acesso refinado](emr-lf-enable.md#emr-lf-fgac-perms) no nível de linha, coluna e célula está disponível em clusters com versões 6.15 e superiores do Amazon EMR.
+ Os usuários com acesso a uma tabela podem acessar todas as propriedades da tabela. Se você tiver controle de acesso baseado no Lake Formation em uma tabela, revise a tabela para garantir que as propriedades não contenham dados ou informações sigilosas.
+ Os clusters do Amazon EMR com Lake Formation não oferecem suporte ao retorno do Spark para o HDFS quando o Spark coleta estatísticas de tabelas. Isso normalmente ajuda a otimizar a performance da consulta.
+ As operações que oferecem suporte a controles de acesso baseados no Lake Formation com tabelas não governadas do Apache Spark incluem `INSERT INTO` e `INSERT OVERWRITE`.
+ As operações que oferecem suporte a controles de acesso baseados no Lake Formation com Apache Spark e Apache Hive incluem `SELECT`, `DESCRIBE`, `SHOW DATABASE`, `SHOW TABLE`, `SHOW COLUMN` e `SHOW PARTITION`.
+ O Amazon EMR não oferece suporte ao controle de acesso às seguintes operações baseadas no Lake Formation:
+ Grava em tabelas controladas
+ O Amazon EMR não oferece suporte a `CREATE TABLE`. O Amazon EMR 6.10.0 e versões superiores oferecem suporte a `ALTER TABLE`.
+ Instruções DML que não sejam comandos `INSERT`.
+ Há diferenças de performance entre a mesma consulta com e sem controle de acesso baseado no Lake Formation.
+ Você só pode usar o Amazon EMR com o Lake Formation para trabalhos do Spark.
+ A propagação de identidades confiáveis não é compatível com a hierarquia de vários catálogos no Catálogo de dados do Glue. Para obter mais informações, consulte [Trabalhando com uma hierarquia de vários catálogos no AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Considerações sobre o Amazon EMR com Lake Formation para a versão 7.10 e posteriores
Considere o seguinte ao usar o Amazon EMR com o AWS Lake Formation EMR 7.10 e versões posteriores.
+ O Amazon EMR oferece suporte ao controle de acesso refinado por meio do Lake Formation apenas para tabelas Apache Hive, tabelas do Iceberg, Apache Delta e Apache Hudi. Os formatos do Apache Hive incluem Parquet, ORC e xSV CSV.
+ Para aplicações habilitadas para o Lake Formation, os logs do Spark são gravados no Amazon S3 em dois grupos: logs de espaço do sistema e logs de espaço do usuário. Os logs de espaço do sistema podem conter informações confidenciais, como o esquema completo da tabela. Para proteger esses dados, o Amazon EMR armazena os logs de espaço do sistema em um local separado dos logs de espaço do usuário. É altamente recomendável que os administradores de contas não concedam aos usuários acesso aos logs de espaço do sistema.
+ Se você registrar um local de tabela no Lake Formation, o acesso aos dados será controlado exclusivamente pelas permissões da função usada para registro, e não pela função de runtime do trabalho do Amazon EMR. Se o perfil de registro estiver incorretamente configurado, os trabalhos que tentarem acessar a tabela falharão.
+ Você não pode desativar `DynamicResourceAllocation` para trabalhos do Lake Formation.
+ Você só pode usar o Lake Formation com trabalhos do Spark.
+ O Amazon EMR com Lake Formation oferece suporte apenas a uma única sessão do Spark durante todo o trabalho.
+ O Amazon EMR com Lake Formation só oferece suporte a consultas de tabelas entre contas compartilhadas por meio de links de recursos.
+ As seguintes opções não são compatíveis:
+ Conjuntos de dados distribuídos resilientes (RDD)
+ Streaming do Spark
+ Gravação com as permissões concedidas pelo Lake Formation
+ Controle de acesso para colunas aninhadas
+ O Amazon EMR bloqueia funcionalidades que podem prejudicar o isolamento completo do driver do sistema, incluindo as seguintes:
+ UDTs, Hive UDFs e qualquer função definida pelo usuário que envolva classes personalizadas
+ Fontes de dados personalizadas
+ Fornecimento de JARs adicionais para extensão, conector ou metastore do Spark
+ Comando `ANALYZE TABLE`
+ Para impor controles de acesso, `EXPLAIN PLAN` e operações de DDL, como `DESCRIBE TABLE`, não expõem informações restritas.
+ O Amazon EMR restringe o acesso aos logs do Spark do driver do sistema em aplicações habilitadas para Lake Formation. Como o driver do sistema é executado com permissões elevadas, os eventos e logs que o driver do sistema gera podem incluir informações confidenciais. Para impedir que usuários ou códigos não autorizados acessem esses dados sensíveis, o Amazon EMR desabilita o acesso aos logs do driver do sistema.
Os logs do perfil do sistema são sempre mantidos no armazenamento gerenciado: essa é uma configuração obrigatória que não pode ser desabilitada. Esses registros são armazenados com segurança e criptografados usando uma chave KMS gerenciada pelo cliente ou uma chave KMS AWS gerenciada.
[Se seu aplicativo Amazon EMR estiver em uma sub-rede privada com endpoints VPC para o Amazon S3 e você anexar uma política de endpoint para controlar o acesso, antes que seus trabalhos possam enviar dados de log para o AWS Amazon S3 gerenciado, você deve incluir as permissões detalhadas em Armazenamento gerenciado em sua política de VPC para o endpoint do gateway S3.](logging.html#jobs-log-storage-managed-storage) Para solicitações de solução de problemas, entre em contato com AWS o suporte.
+ Se você registrou uma localização de tabela no Lake Formation, o caminho de acesso aos dados passa pelas credenciais armazenadas do Lake Formation, independentemente da permissão do IAM para o perfil de runtime do trabalho do Amazon EMR. Se você configurar incorretamente o perfil registrado com a localização da tabela, os trabalhos enviados que usam o perfil com a permissão do IAM para o S3 na localização da tabela falharão.
+ Gravar em uma tabela do Lake Formation usa a permissão do IAM em vez das permissões concedidas pelo Lake Formation. Se o runtime do trabalho tiver as permissões necessárias do S3, será possível usá-lo para executar operações de gravação.
Observe estas considerações e limitações ao usar o Apache Iceberg:
+ Você só pode usar o Apache Iceberg com o catálogo de sessões e não com catálogos nomeados arbitrariamente.
+ As tabelas do Iceberg registradas no Lake Formation oferecem suporte apenas às tabelas de metadados `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` e `refs`. O Amazon EMR oculta as colunas que podem conter dados confidenciais, como `partitions`, `path` e `summaries`. Essa limitação não se aplica às tabelas do Iceberg que não estão registradas no Lake Formation.
+ As tabelas que você não registra no Lake Formation oferecem suporte a todos os procedimentos armazenados do Iceberg. Os procedimentos `register_table` e `migrate` não são compatíveis com nenhuma tabela.
+ Recomendamos que você use o Iceberg DataFrameWriter V2 em vez do V1.
## Considerações sobre o Amazon EMR com Lake Formation para a versão 7.12 e posterior
### Geral
Analise as seguintes limitações ao usar o Lake Formation com o Amazon EMR.
+ Você não pode desativar `DynamicResourceAllocation` para trabalhos do Lake Formation.
+ Você só pode usar o Lake Formation com trabalhos do Spark.
+ O Amazon EMR com Lake Formation oferece suporte apenas a uma única sessão do Spark durante todo o trabalho.
+ O Amazon EMR com Lake Formation só oferece suporte a consultas de tabelas entre contas compartilhadas por meio de links de recursos.
+ As seguintes opções não são compatíveis:
+ Conjuntos de dados distribuídos resilientes (RDD)
+ Streaming do Spark
+ Controle de acesso para colunas aninhadas
+ O Amazon EMR bloqueia funcionalidades que podem prejudicar o isolamento completo do driver do sistema, incluindo as seguintes:
+ UDTs, Hive UDFs e qualquer função definida pelo usuário que envolva classes personalizadas
+ Fontes de dados personalizadas
+ Fornecimento de JARs adicionais para extensão, conector ou metastore do Spark
+ Comando `ANALYZE TABLE`
+ [Se seu aplicativo Amazon EMR estiver em uma sub-rede privada com endpoints VPC para o Amazon S3 e você anexar uma política de endpoint para controlar o acesso, antes que seus trabalhos possam enviar dados de log para o AWS Amazon S3 gerenciado, você deve incluir as permissões detalhadas em Armazenamento gerenciado em sua política de VPC para o endpoint do gateway S3.](logging.html#jobs-log-storage-managed-storage) Para solicitações de solução de problemas, entre em contato com AWS o suporte.
+ A partir do Amazon EMR 7.9.0, o Spark FGAC oferece suporte ao AFile sistema S3 quando usado com o esquema s3a://.
+ O Amazon EMR 7.11 oferece suporte à criação de tabelas gerenciadas usando CTAS.
+ O Amazon EMR 7.12 oferece suporte à criação de tabelas gerenciadas e externas usando CTAS.
## Permissões
+ Para aplicar controles de acesso, as operações EXPLAIN PLAN e DDL, como DESCRIBE TABLE, não expõem informações restritas.
+ Quando você registra a localização de uma tabela no Lake Formation, o acesso aos dados usa as credenciais armazenadas do Lake Formation em vez das permissões IAM da função de tempo de execução de trabalho do EMR Serverless. Os trabalhos falharão se a função registrada para a localização da tabela estiver configurada incorretamente, mesmo quando a função de tempo de execução tiver permissões do S3 IAM para essa localização.
+ A partir do Amazon EMR 7.12, você pode gravar nas tabelas existentes do Hive e do Iceberg usando DataFrameWriter (V2) com as credenciais do Lake Formation no modo de acréscimo. Para operações de substituição ou ao criar novas tabelas, o EMR usa as credenciais da função de tempo de execução para modificar os dados da tabela.
+ As seguintes limitações se aplicam ao usar exibições ou tabelas em cache como dados de origem (essas limitações não se aplicam às visualizações do AWS Glue Data Catalog):
+ Para operações MERGE, DELETE e UPDATE
+ Compatível: uso de visualizações e tabelas em cache como tabelas de origem.
+ Não suportado: uso de visualizações e tabelas em cache em cláusulas de atribuição e condição.
+ Para as operações CREATE OR REPLACE e REPLACE TABLE AS SELECT:
+ Não suportado: uso de visualizações e tabelas em cache como tabelas de origem.
+ As tabelas Delta Lake com dados UDFs na fonte suportam as operações MERGE, DELETE e UPDATE somente quando o vetor de exclusão está ativado.
## Registros e depuração
+ O Amazon EMR restringe o acesso aos logs do Spark do driver do sistema em aplicações habilitadas para Lake Formation. Como o driver do sistema é executado com permissões elevadas, os eventos e logs que o driver do sistema gera podem incluir informações confidenciais. Para impedir que usuários ou códigos não autorizados acessem esses dados sensíveis, o Amazon EMR desabilita o acesso aos logs do driver do sistema.
Os logs do perfil do sistema são sempre mantidos no armazenamento gerenciado: essa é uma configuração obrigatória que não pode ser desabilitada. Esses registros são armazenados com segurança e criptografados usando uma chave KMS gerenciada pelo cliente ou uma chave KMS AWS gerenciada.
## Iceberg
Analise as seguintes considerações ao usar o Apache Iceberg:
+ Você só pode usar o Apache Iceberg com o catálogo de sessões e não com catálogos nomeados arbitrariamente.
+ As tabelas do Iceberg registradas no Lake Formation oferecem suporte apenas às tabelas de metadados `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` e `refs`. O Amazon EMR oculta as colunas que podem conter dados confidenciais, como `partitions`, `path` e `summaries`. Essa limitação não se aplica às tabelas do Iceberg que não estão registradas no Lake Formation.
+ As tabelas não registradas no Lake Formation oferecem suporte a todos os procedimentos armazenados do Iceberg. Os procedimentos `register_table` e `migrate` não são compatíveis com nenhuma tabela.
+ Sugerimos que você use o Iceberg DataFrameWriter V2 em vez do V1.
# API de controle de acesso refinado nativo do Spark permitida PySpark
Para manter a segurança e os controles de acesso aos dados, o controle de acesso refinado (FGAC) do Spark restringe determinadas funções. PySpark Essas restrições são aplicadas por meio de:
+ Bloqueio explícito que impede a execução da função
+ Incompatibilidades de arquitetura que tornam as funções não funcionais
+ Funções que podem gerar erros, retornar mensagens de acesso negado ou não fazer nada quando chamadas
Os seguintes PySpark recursos não são compatíveis com o Spark FGAC:
+ Operações RDD (bloqueadas com a exceção do Spark) RDDUnsupported
+ Spark Connect (não suportado)
+ Spark Streaming (não suportado)
Embora tenhamos testado as funções listadas em um ambiente Native Spark FGAC e confirmado que elas funcionam conforme o esperado, nossos testes normalmente abrangem apenas o uso básico de cada API. Funções com vários tipos de entrada ou caminhos lógicos complexos podem ter cenários não testados.
Para qualquer função não listada aqui e que não faça parte claramente das categorias não suportadas acima, recomendamos:
+ Testando-os primeiro em um ambiente gama ou em uma implantação em pequena escala
+ Verificando seu comportamento antes de usá-los na produção
**nota**
Se você ver um método de classe listado, mas não sua classe base, o método ainda deve funcionar — significa apenas que não verificamos explicitamente o construtor da classe base.
A PySpark API é organizada em módulos. O suporte geral para métodos em cada módulo está detalhado na tabela abaixo.
| Nome do módulo | Status | Observações |
| --- | --- | --- |
| pyspark\$1core | Compatível | Este módulo contém as principais classes do RDD e, na maioria das vezes, essas funções não são suportadas. |
| pyspark\$1sql | Compatível | |
| teste\$1de\$1pyspark | Compatível | |
| pyspark\$1resource | Compatível | |
| pyspark\$1streaming | Bloqueado | O uso do streaming está bloqueado no Spark FGAC. |
| pyspark\$1mllib | Experimental | Este módulo contém operações de ML baseadas em RDD, e essas funções geralmente não são suportadas. Este módulo não foi totalmente testado. |
| pyspark\$1ml | Experimental | Esse módulo contém operações de ML DataFrame baseadas, e essas funções são suportadas principalmente. Este módulo não foi totalmente testado. |
| pyspark\$1pandas | Compatível | |
| pyspark\$1pandas\$1slow | Compatível | |
| pyspark\$1connect | Bloqueado | O uso do Spark Connect está bloqueado no Spark FGAC. |
| pyspark\$1pandas\$1connect | Bloqueado | O uso do Spark Connect está bloqueado no Spark FGAC. |
| pyspark\$1pandas\$1slow\$1connect | Bloqueado | O uso do Spark Connect está bloqueado no Spark FGAC. |
| pyspark\$1errors | Experimental | Este módulo não foi totalmente testado. Classes de erro personalizadas não podem ser utilizadas. |
**Lista de permissões da API**
Para uma lista que pode ser baixada e mais fácil de pesquisar, um arquivo com os módulos e classes está disponível nas [funções do Python permitidas no](samples/Python functions allowed in Native FGAC.zip) FGAC nativo.
# Acesso completo à tabela do Lake Formation para o Amazon EMR no EC2
Com as versões 7.8.0 e superiores do Amazon EMR, você pode aproveitar o Lake AWS Formation com o Glue Data Catalog, onde a função de tempo de execução do trabalho tem permissões completas de tabela sem as limitações do controle de acesso refinado. Esse recurso permite que você leia e grave em tabelas protegidas pelo Lake Formation a partir do Amazon EMR em trabalhos em lote e interativos do EC2 Spark. Consulte as seções a seguir para saber mais sobre o Lake Formation e como usá-lo com o Amazon EMR no EC2.
## Como usar o Lake Formation com acesso total à tabela
Você pode acessar as tabelas do catálogo do Glue Data protegidas pelo AWS Lake Formation do Amazon EMR em trabalhos do EC2 Spark ou sessões interativas em que a função de tempo de execução do trabalho tem acesso total à tabela. Você não precisa habilitar o AWS Lake Formation no aplicativo Amazon EMR no EC2. Quando um trabalho do Spark é configurado para Full Table Access (FTA), as credenciais do AWS Lake Formation são usadas para os dados do read/write S3 das tabelas registradas do AWS Lake Formation, enquanto as credenciais da função de tempo de execução do trabalho são usadas para read/write tabelas não registradas no Lake Formation. AWS
**Importante**
Não ative o AWS Lake Formation para um controle de acesso refinado. Um trabalho não pode executar simultaneamente o Acesso total à tabela (FTA) e o Controle de acesso refinado (FGAC) no mesmo cluster ou aplicação EMR.
### Etapa 1: habilitar o acesso total à tabela no Lake Formation
Para usar o modo Full Table Access (FTA), você deve permitir que mecanismos de consulta de terceiros acessem dados sem a validação da tag de sessão do IAM no AWS Lake Formation. Para habilitar, siga as etapas em [Application integration for full table access](https://docs.aws.amazon.com/lake-formation/latest/dg/full-table-credential-vending.html).
**nota**
Ao acessar tabelas entre contas, o acesso completo à tabela deve ser habilitado nas contas de produtor e consumidor. Da mesma forma, ao acessar tabelas entre regiões, essa configuração deve ser habilitada nas regiões produtora e consumidora.
### Etapa 2: configurar permissões do IAM para o perfil de runtime do trabalho
Para acesso de leitura ou gravação aos dados subjacentes, além das permissões do Lake Formation, um perfil de runtime do trabalho precisa da permissão `lakeformation:GetDataAccess` do IAM. Com essa permissão, o Lake Formation concede a solicitação de credenciais temporárias para acessar os dados.
Confira a seguir um exemplo de política de como fornecer permissões do IAM para acesso a um script no S3, upload de logs no Amazon S3, permissões da API do AWS Glue e permissão para acessar o Lake Formation.
#### Etapa 2.1: configurar permissões do Lake Formation
+ Os trabalhos Spark que leem dados do S3 necessitam de permissão SELECT do Lake Formation.
+ O Spark faz com que write/delete os dados no S3 exijam a permissão Lake Formation ALL (SUPER).
+ Os trabalhos do Spark que interagem com o Catálogo de dados do Glue exigem as permissões DESCRIBE, ALTER, DROP, conforme apropriado.
Para obter mais informações, consulte [Conceder permissões em recursos do Catálogo de dados](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
### Etapa 3: inicializar uma sessão do Spark para acesso total à tabela usando o Lake Formation
#### Pré-requisitos
AWS O Glue Data Catalog deve ser configurado como um metastore para acessar as tabelas do Lake Formation.
Defina as seguintes configurações para configurar o catálogo do Glue como umo metastore:
```
--conf spark.sql.catalogImplementation=hive
--conf spark.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory
```
Para obter mais informações sobre como habilitar o catálogo de dados para o Amazon EMR no EC2, consulte Configuração do [Metastore para o Amazon](metastore-config.html) EMR no EC2.
Para acessar tabelas registradas no AWS Lake Formation, as seguintes configurações precisam ser definidas durante a inicialização do Spark para configurar o Spark para usar as credenciais do Lake Formation AWS .
------
#### [ Hive ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Iceberg ]
```
--conf spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog
--conf spark.sql.catalog.spark_catalog.warehouse=S3_DATA_LOCATION
--conf spark.sql.catalog.spark_catalog.client.region=REGION
--conf spark.sql.catalog.spark_catalog.type=glue
--conf spark.sql.catalog.spark_catalog.glue.account-id=ACCOUNT_ID
--conf spark.sql.catalog.spark_catalog.glue.lakeformation-enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Delta Lake ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
```
------
#### [ Hudi ]
```
‐‐conf spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver
--conf spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true
--conf spark.hadoop.fs.s3.folderObject.autoAction.disabled=true
--conf spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true
--conf spark.sql.catalog.createDirectoryAfterTable.enabled=true
--conf spark.sql.catalog.dropDirectoryBeforeTable.enabled=true
--conf spark.jars=/usr/lib/hudi/hudi-spark-bundle.jar
--conf spark.sql.extensions=org.apache.spark.sql.hudi.HoodieSparkSessionExtension
--conf spark.sql.catalog.spark_catalog=org.apache.spark.sql.hudi.catalog.HoodieCatalog
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer
```
------
+ `spark.hadoop.fs.s3.credentialsResolverClass=com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver`: Configure o EMR Filesystem (EMRFS) ou o EMR S3A para usar as credenciais do Lake Formation S3 para tabelas registradas do Lake AWS Formation. Se a tabela não estiver registrada, use as credenciais do perfil de runtime do trabalho.
+ `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` e `spark.hadoop.fs.s3.folderObject.autoAction.disabled=true`: configure o EMRFS para usar o cabeçalho do tipo de conteúdo application/x-directory em vez do sufixo \$1folder\$1 ao criar pastas do S3. Isso é necessário ao ler tabelas do Lake Formation, pois as credenciais do Lake Formation não permitem a leitura de pastas de tabelas com o sufixo \$1folder\$1.
+ `spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true`: configure o Spark para ignorar a validação da ausência do local da tabela antes da criação. Isso é necessário para tabelas registradas do Lake Formation, pois as credenciais do Lake Formation para verificar o local vazio só estão disponíveis após a criação da tabela do Catálogo de dados do Glue. Sem essa configuração, as credenciais do perfil de runtime do trabalho validarão o local da tabela vazia.
+ `spark.sql.catalog.createDirectoryAfterTable.enabled=true`: configure o Spark para criar a pasta do Amazon S3 após a criação da tabela no metastore do Hive. Isso é necessário para tabelas registradas no Lake Formation, pois as credenciais do Lake Formation para criar a pasta do S3 só ficam disponíveis após a criação da tabela no Catálogo de dados do Glue.
+ `spark.sql.catalog.dropDirectoryBeforeTable.enabled=true`: configure o Spark para encerrar a pasta do S3 antes da exclusão da tabela no metastore do Hive. Isso é necessário para tabelas registradas do Lake Formation, pois as credenciais do Lake Formation para encerrar a pasta do S3 não estão disponíveis após a exclusão da tabela do Catálogo de dados do Glue.
+ `spark.sql.catalog..glue.lakeformation-enabled=true`: Configure o catálogo do Iceberg para usar as credenciais do AWS Lake Formation S3 para tabelas registradas do Lake Formation. Se a tabela não estiver registrada, use as credenciais de ambiente padrão.
#### Configurar o modo de acesso total à tabela no SageMaker Unified Studio
Para acessar as tabelas registradas do Lake Formation a partir de sessões interativas do Spark em JupyterLab notebooks, use o modo de permissão de compatibilidade. Use o comando mágico %%configure para definir sua configuração do Spark. Escolha a configuração com base no seu tipo de tabela:
------
#### [ For Hive tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Iceberg tables ]
```
%%configure -f
{
"conf": {
"spark.sql.catalog.spark_catalog": "org.apache.iceberg.spark.SparkSessionCatalog",
"spark.sql.catalog.spark_catalog.warehouse": "S3_DATA_LOCATION",
"spark.sql.catalog.spark_catalog.client.region": "REGION",
"spark.sql.catalog.spark_catalog.type": "glue",
"spark.sql.catalog.spark_catalog.glue.account-id": "ACCOUNT_ID",
"spark.sql.catalog.spark_catalog.glue.lakeformation-enabled": "true",
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": "true",
}
}
```
------
#### [ For Delta Lake tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true
}
}
```
------
#### [ For Hudi tables ]
```
%%configure -f
{
"conf": {
"spark.hadoop.fs.s3.credentialsResolverClass": "com.amazonaws.glue.accesscontrol.AWSLakeFormationCredentialResolver",
"spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject": true,
"spark.hadoop.fs.s3.folderObject.autoAction.disabled": true,
"spark.sql.catalog.skipLocationValidationOnCreateTable.enabled": true,
"spark.sql.catalog.createDirectoryAfterTable.enabled": true,
"spark.sql.catalog.dropDirectoryBeforeTable.enabled": true,
"spark.jars": "/usr/lib/hudi/hudi-spark-bundle.jar",
"spark.sql.extensions": "org.apache.spark.sql.hudi.HoodieSparkSessionExtension",
"spark.sql.catalog.spark_catalog": "org.apache.spark.sql.hudi.catalog.HoodieCatalog",
"spark.serializer": "org.apache.spark.serializer.KryoSerializer"
}
}
```
------
Substitua os espaços reservados:
+ `S3_DATA_LOCATION`: caminho do bucket do S3
+ `REGION`: AWS região (por exemplo, us-east-1)
+ `ACCOUNT_ID`: ID AWS da sua conta
**nota**
Você precisa definir essas configurações antes de executar qualquer operação do Spark em seu caderno.
#### Operações com Suporte
Essas operações usarão as credenciais do AWS Lake Formation para acessar os dados da tabela.
+ CRIAR TABELA
+ ALTER TABLE
+ INSERT INTO
+ INSERT OVERWRITE
+ UPDATE
+ MERGE INTO
+ DELETE FROM
+ ANALYZE TABLE
+ REPAIR TABLE
+ DESCARTAR TABELA
+ Consultas de fontes de dados do Spark
+ Gravações na fonte de dados do Spark
**nota**
As operações não listadas acima continuarão usando as permissões do IAM para acessar os dados da tabela.
#### Considerações
+ Se uma tabela do Hive for criada usando um trabalho que não tem acesso total à tabela habilitado e nenhum registro for inserido, as leituras ou gravações subsequentes de um trabalho com acesso total à tabela falharão. Isso ocorre porque o EMR Spark sem acesso total à tabela adiciona o sufixo `$folder$` ao nome da pasta da tabela. Para resolver isso, você tem as seguintes opções:
+ Insira pelo menos uma linha na tabela diretamente de um trabalho no qual o FTA não esteja habilitado.
+ Configure o trabalho no qual o FTA não está habilitado para não usar o sufixo `$folder$` no nome da pasta no S3. É possível fazer isso definindo a configuração `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` do Spark.
+ Crie uma pasta S3 no local da tabela `s3://path/to/table/table_name` usando o console AWS S3 ou a CLI do AWS S3.
+ O acesso total à tabela é compatível com o sistema de arquivos do EMR (EMRFS) a partir da versão 7.8.0 do Amazon EMR e com o sistema de arquivos S3A a partir da versão 7.10.0 do Amazon EMR.
+ O Full Table Access é compatível com as tabelas Hive, Iceberg, Delta e Hudi.
+ **Considerações sobre o Hudi FTA Write Support:**
+ As gravações do Hudi FTA exigem o uso HoodieCredentialedHadoopStorage para venda de credenciais durante a execução do trabalho. Defina a seguinte configuração ao executar trabalhos do Hudi: `hoodie.storage.class=org.apache.spark.sql.hudi.storage.HoodieCredentialedHadoopStorage`
+ O suporte de gravação do Full Table Access (FTA) para Hudi está disponível a partir da versão 7.12 do Amazon EMR.
+ Atualmente, o suporte de gravação do Hudi FTA funciona apenas com as configurações padrão do Hudi. As configurações Hudi personalizadas ou não padrão podem não ser totalmente compatíveis e podem resultar em um comportamento inesperado.
+ O agrupamento para tabelas Hudi Merge-On-Read (MOR) não é suportado neste momento no modo de gravação FTA.
+ Os trabalhos que mencionam tabelas com regras de controle de acesso de alta granularidade (FGAC) do Lake Formation ou visualizações do catálogo de dados do Glue falharão. Para consultar uma tabela com regras de FGAC ou uma visualização do Catálogo de dados do Glue, você precisará usar o modo FGAC. Você pode ativar o modo FGAC seguindo as etapas descritas na AWS documentação: Usando o [Amazon EMR no EC2 com o Lake AWS Formation](emr-serverless-lf-enable.html) para um controle de acesso refinado.
+ O acesso total à tabela não é compatível com Spark Streaming.
+ Ao gravar o Spark DataFrame em uma tabela do Lake Formation, somente o modo APPEND é compatível com as tabelas Hive e Iceberg: `df.write.mode("append").saveAsTable(table_name)`
+ A criação de tabelas externas requer permissões do IAM.
+ Como o Lake Formation armazena temporariamente as credenciais em um trabalho Spark, um trabalho em lote do Spark ou uma sessão interativa em execução no momento pode não refletir as alterações de permissão.
+ Você deve usar um perfil definido pelo usuário e não um perfil vinculado ao serviço:[Requisitos do Lake Formation para perfis](https://docs.aws.amazon.com/lake-formation/latest/dg/registration-role.html).
#### Hudi FTA Write Support - Operações suportadas
A tabela a seguir mostra as operações de gravação suportadas para tabelas Hudi Copy-On-Write (COW) e Merge-On-Read (MOR) no modo Full Table Access:
**Operações de gravação suportadas pelo Hudi FTA**
| Tipo de tabela | Operation | Comando SQL Write | Status |
| --- | --- | --- | --- |
| VACA | INSERT | INSERT INTO TABLE | Compatível |
| VACA | INSERT | INSERIR NA TABELA - PARTIÇÃO (estática, dinâmica) | Compatível |
| VACA | INSERT | INSERT OVERWRITE | Compatível |
| VACA | INSERT | INSERIR SUBSTITUIÇÃO - PARTIÇÃO (estática, dinâmica) | Compatível |
| UPDATE | UPDATE | UPDATE TABLE | Compatível |
| VACA | UPDATE | TABELA DE ATUALIZAÇÃO - Alterar partição | Não suportado |
| DELETE | DELETE | DELETE FROM TABLE | Compatível |
| ALTER | ALTER | ALTERAR TABELA - RENOMEAR PARA | Não suportado |
| VACA | ALTER | ALTERE A TABELA - DEFINA AS PROPRIEDADES DA TABELA | Compatível |
| VACA | ALTER | ALTERAR TABELA - DESDEFINIR TBLPROPERTIES | Compatível |
| VACA | ALTER | ALTERAR TABELA - ALTERAR COLUNA | Compatível |
| VACA | ALTER | ALTERAR TABELA - ADICIONAR COLUNAS | Compatível |
| VACA | ALTER | ALTERAR TABELA - ADICIONAR PARTIÇÃO | Compatível |
| VACA | ALTER | ALTERAR TABELA - SOLTAR PARTIÇÃO | Compatível |
| VACA | ALTER | ALTERAR TABELA - RECUPERAR PARTIÇÕES | Compatível |
| VACA | ALTER | REPARAR PARTIÇÕES DE SINCRONIZAÇÃO DE TABELAS | Compatível |
| DROP | DROP | DESCARTAR TABELA | Compatível |
| VACA | DROP | TABELA SUSPENSA - PURGA | Compatível |
| CREATE | CREATE | CRIAR TABELA - Gerenciado | Compatível |
| VACA | CREATE | CRIAR TABELA - PARTICIONAR POR | Compatível |
| VACA | CREATE | CRIAR TABELA SE NÃO EXISTIR | Compatível |
| VACA | CREATE | CREATE TABLE LIKE | Compatível |
| VACA | CREATE | CRIAR TABELA COMO SELEÇÃO | Compatível |
| CREATE | CREATE | CRIAR TABELA com LOCALIZAÇÃO - Tabela externa | Não suportado |
| QUADRO DE DADOS (INSERIR) | QUADRO DE DADOS (INSERIR) | saveAsTable.Sobrescrever | Compatível |
| VACA | QUADRO DE DADOS (INSERIR) | saveAsTable.Anexar | Não suportado |
| VACA | QUADRO DE DADOS (INSERIR) | saveAsTable.Ignorar | Compatível |
| VACA | QUADRO DE DADOS (INSERIR) | saveAsTable.ErrorIfExists | Compatível |
| VACA | QUADRO DE DADOS (INSERIR) | saveAsTable - Tabela externa (Caminho) | Não suportado |
| VACA | QUADRO DE DADOS (INSERIR) | salvar (caminho) - DF v1 | Não suportado |
| MAIS | INSERT | INSERT INTO TABLE | Compatível |
| MAIS | INSERT | INSERIR NA TABELA - PARTIÇÃO (estática, dinâmica) | Compatível |
| MAIS | INSERT | INSERT OVERWRITE | Compatível |
| MAIS | INSERT | INSERIR SUBSTITUIÇÃO - PARTIÇÃO (estática, dinâmica) | Compatível |
| UPDATE | UPDATE | UPDATE TABLE | Compatível |
| MAIS | UPDATE | TABELA DE ATUALIZAÇÃO - Alterar partição | Não suportado |
| DELETE | DELETE | DELETE FROM TABLE | Compatível |
| ALTER | ALTER | ALTERAR TABELA - RENOMEAR PARA | Não suportado |
| MAIS | ALTER | ALTERE A TABELA - DEFINA AS PROPRIEDADES DA TABELA | Compatível |
| MAIS | ALTER | ALTERAR TABELA - DESDEFINIR TBLPROPERTIES | Compatível |
| MAIS | ALTER | ALTERAR TABELA - ALTERAR COLUNA | Compatível |
| MAIS | ALTER | ALTERAR TABELA - ADICIONAR COLUNAS | Compatível |
| MAIS | ALTER | ALTERAR TABELA - ADICIONAR PARTIÇÃO | Compatível |
| MAIS | ALTER | ALTERAR TABELA - SOLTAR PARTIÇÃO | Compatível |
| MAIS | ALTER | ALTERAR TABELA - RECUPERAR PARTIÇÕES | Compatível |
| MAIS | ALTER | REPARAR PARTIÇÕES DE SINCRONIZAÇÃO DE TABELAS | Compatível |
| DROP | DROP | DESCARTAR TABELA | Compatível |
| MAIS | DROP | TABELA SUSPENSA - PURGA | Compatível |
| CREATE | CREATE | CRIAR TABELA - Gerenciado | Compatível |
| MAIS | CREATE | CRIAR TABELA - PARTICIONAR POR | Compatível |
| MAIS | CREATE | CRIAR TABELA SE NÃO EXISTIR | Compatível |
| MAIS | CREATE | CREATE TABLE LIKE | Compatível |
| MAIS | CREATE | CRIAR TABELA COMO SELEÇÃO | Compatível |
| CREATE | CREATE | CRIAR TABELA com LOCALIZAÇÃO - Tabela externa | Não suportado |
| QUADRO DE DADOS (UPSERT) | QUADRO DE DADOS (UPSERT) | saveAsTable.Sobrescrever | Compatível |
| MAIS | QUADRO DE DADOS (UPSERT) | saveAsTable.Anexar | Não suportado |
| MAIS | QUADRO DE DADOS (UPSERT) | saveAsTable.Ignorar | Compatível |
| MAIS | QUADRO DE DADOS (UPSERT) | saveAsTable.ErrorIfExists | Compatível |
| MAIS | QUADRO DE DADOS (UPSERT) | saveAsTable - Tabela externa (Caminho) | Não suportado |
| MAIS | QUADRO DE DADOS (UPSERT) | salvar (caminho) - DF v1 | Não suportado |
| DATAFRAME (EXCLUIR) | DATAFRAME (EXCLUIR) | saveAsTable.Anexar | Não suportado |
| MAIS | DATAFRAME (EXCLUIR) | saveAsTable - Tabela externa (Caminho) | Não suportado |
| MAIS | DATAFRAME (EXCLUIR) | salvar (caminho) - DF v1 | Não suportado |
| QUADRO DE DADOS (BULK\$1INSERT) | QUADRO DE DADOS (BULK\$1INSERT) | saveAsTable.Sobrescrever | Compatível |
| MAIS | QUADRO DE DADOS (BULK\$1INSERT) | saveAsTable.Anexar | Não suportado |
| MAIS | QUADRO DE DADOS (BULK\$1INSERT) | saveAsTable.Ignorar | Compatível |
| MAIS | QUADRO DE DADOS (BULK\$1INSERT) | saveAsTable.ErrorIfExists | Compatível |
| MAIS | QUADRO DE DADOS (BULK\$1INSERT) | saveAsTable - Tabela externa (Caminho) | Não suportado |
| MAIS | QUADRO DE DADOS (BULK\$1INSERT) | salvar (caminho) - DF v1 | Não suportado |
# Integrar o Amazon EMR com o Apache Ranger
Desde a versão 5.32.0 do Amazon EMR, você pode iniciar um cluster que se integre nativamente ao Apache Ranger. O Apache Ranger é uma estrutura de código aberto para habilitar, monitorar e gerenciar uma segurança de dados abrangente em toda a plataforma Hadoop. Para obter mais informações, consulte [Apache Ranger](https://ranger.apache.org/). Com a integração nativa, você pode trazer seu próprio Apache Ranger para aplicar um controle de acesso detalhado aos dados no Amazon EMR.
Esta seção fornece uma visão geral conceitual da integração do Amazon EMR com o Apache Ranger. Também inclui os pré-requisitos e as etapas necessárias para iniciar um cluster do Amazon EMR integrado ao Apache Ranger.
Integrar o Amazon EMR de maneira nativa com o Apache Ranger oferece os seguintes benefícios principais:
+ Controle de acesso refinado aos bancos de dados e tabelas do Hive Metastore, que permite definir políticas de filtragem de dados no nível de banco de dados, tabela e coluna para aplicações Apache Spark e Apache Hive. A filtragem em nível de linha e o mascaramento de dados são compatíveis com aplicações Hive.
+ A capacidade de usar suas políticas atuais do Hive diretamente com o Amazon EMR para aplicações Hive.
+ Controle de acesso aos dados do Amazon S3 no nível do prefixo e do objeto, o que permite definir políticas de filtragem de dados para acesso aos dados do S3 usando o sistema de arquivos do EMR.
+ A capacidade de usar o CloudWatch Logs para auditoria centralizada.
+ O Amazon EMR instala e gerencia os plug-ins do Apache Ranger por você.
**Importante**
O Amazon EMR não oferece suporte à integração com o Apache Ranger a partir da versão 7.4 do Amazon EMR. Para obter mais informações, consulte [Amazon EMR versão](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-740-release.html) 7.4.0.
# Apache Ranger com o Amazon EMR
O Apache Ranger é um framework para habilitar, monitorar e gerenciar uma segurança de dados abrangente em toda a plataforma Hadoop.
O Apache Ranger tem os seguintes atributos:
+ Administração de segurança centralizada para gerenciar todas as tarefas relacionadas à segurança em uma interface central ou usando REST APIs.
+ Autorização refinada para realizar uma ação ou operação específica usando um componente ou ferramenta do Hadoop, gerenciada por meio de uma ferramenta de administração central.
+ Um método de autorização padronizado em todos os componentes do Hadoop.
+ Suporte aprimorado para diversos métodos de autorização.
+ Auditoria centralizada do acesso do usuário e das ações administrativas (relacionadas à segurança) em todos os componentes do Hadoop.
O Apache Ranger usa dois componentes principais para autorização:
+ **Servidor de administração de políticas Apache Ranger**: esse servidor permite definir as políticas de autorização para aplicações Hadoop. Ao fazer a integração com o Amazon EMR, você pode definir e aplicar políticas para que o Apache Spark e o Hive acessem o Hive Metastore e acessem o [sistema de arquivos do EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs) de dados do Amazon S3. É possível configurar um novo servidor de administração de políticas Apache Ranger ou usar um já existente para se integrar ao Amazon EMR.
+ **Plug-in Apache Ranger**: esse plug-in valida o acesso de um usuário em relação às políticas de autorização definidas no servidor de administração de políticas do Apache Ranger. O Amazon EMR instala e configura automaticamente o plug-in Apache Ranger para cada aplicação Hadoop selecionada na configuração do Apache Ranger.
**Topics**
+ [Arquitetura da integração do Amazon EMR com o Apache Ranger](emr-ranger-architecture.md)
+ [Componentes do Amazon EMR para uso com o Apache Ranger](emr-ranger-components.md)
# Arquitetura da integração do Amazon EMR com o Apache Ranger
![\[Diagrama de arquitetura do Amazon EMR e do Apache Ranger.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/emr-ranger-architecture.png)
# Componentes do Amazon EMR para uso com o Apache Ranger
O Amazon EMR possibilita um controle de acesso refinado com o Apache Ranger por meio dos componentes a seguir. Consulte o [diagrama de arquitetura](emr-ranger-architecture.md) para ter uma representação visual desses componentes do Amazon EMR com os plug-ins do Apache Ranger.
**Agente secreto**: o agente secreto armazena e distribui segredos com segurança para outros componentes ou aplicações do Amazon EMR. Os segredos podem incluir credenciais temporárias de usuário, chaves de criptografia ou tickets Kerberos. O agente secreto é executado em todos os nós do cluster e intercepta chamadas ao serviço de metadados da instância. Para solicitações às credenciais do perfil do perfil de instância, o agente secreto fornece as credenciais dependendo do usuário solicitante e dos recursos solicitados após autorizar a solicitação com o plug-in EMRFS S3 do Ranger. O agente secreto é executado como *`emrsecretagent`*usuário e grava os registros no emr/secretagent/log diretório /. O processo depende de um conjunto específico de regras `iptables` para funcionar. É importante garantir que não `iptables` esteja desabilitado. Se você personalizar a configuração `iptables`, as regras da tabela NAT deverão ser preservadas e deixadas inalteradas.
**Servidor de registros do EMR**: p servidor de registros recebe solicitações para acessar dados do Spark. Em seguida, ele autoriza as solicitações encaminhando os recursos solicitados ao plug-in Spark Ranger para Amazon EMR. O servidor de registros lê dados do Amazon S3 e retorna dados filtrados que o usuário está autorizado a acessar com base na política do Ranger. O servidor de registros é executado em cada nó do cluster como usuário emr\$1record\$1server e grava registros no diretório/-record-server. var/log/emr
# Considerações sobre o uso do Amazon EMR com o Apache Ranger
## Aplicações compatíveis com o Amazon EMR com Apache Ranger
A integração entre o Amazon EMR e o Apache Ranger, na qual o EMR instala os plug-ins do Ranger, atualmente, oferece suporte às seguintes aplicações:
+ Apache Spark (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Hive (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Acesso ao S3 por meio do EMRFS (disponível no EMR 5.32\$1 e EMR 6.3\$1)
As seguintes aplicações podem ser instaladas em um cluster do EMR e talvez precisem ser configuradas para atender a suas necessidades de segurança:
+ Apache Hadoop (disponível no EMR 5.32\$1 e EMR 6.3\$1, inclusive YARN e HDFS)
+ Apache Livy (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Zeppelin (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Apache Hue (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Ganglia (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ HCatalog (Disponível com EMR 5.32\$1 e EMR 6.3\$1)
+ Mahout (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ MXNet (Disponível com EMR 5.32\$1 e EMR 6.3\$1)
+ TensorFlow (Disponível com EMR 5.32\$1 e EMR 6.3\$1)
+ Tez (disponível no EMR 5.32\$1 e EMR 6.3\$1)
+ Trino (disponível no EMR 6.7\$1)
+ ZooKeeper (Disponível com EMR 5.32\$1 e EMR 6.3\$1)
**Importante**
As aplicações listadas acima são as únicas com suporte no momento. Para garantir a segurança do cluster, você tem permissão para criar um cluster do EMR somente com as aplicações da lista acima quando o Apache Ranger está habilitado.
No momento, não há suporte para outros aplicativos. Para garantir a segurança do cluster, tentar instalar outras aplicações causará a rejeição do cluster.
AWS Os formatos Glue Data Catalog e Open Table, como Apache Hudi, Delta Lake e Apache Iceberg, não são compatíveis.
**Recursos do Amazon EMR compatíveis com o Apache Ranger**
Os seguintes recursos do Amazon EMR são compatíveis quando você usa o Amazon EMR com o Apache Ranger:
+ Criptografia de dados em repouso e em trânsito
+ Autenticação Kerberos (obrigatória)
+ Grupos de instâncias, frotas de instâncias e instâncias spot
+ Reconfiguração de aplicações em um cluster em execução
+ Criptografia do lado do servidor (SSE) do EMRFS
**nota**
As configurações de criptografia do Amazon EMR governam o SSE. Para obter mais informações, consulte [Encryption Options](emr-data-encryption-options.md).
## Limitações de aplicação
Há várias limitações que você deve conhecer ao integrar o Amazon EMR e o Apache Ranger:
+ No momento, você não pode usar o console para criar uma configuração de segurança que especifique a opção de integração do AWS Ranger no. AWS GovCloud (US) Region A configuração de segurança do pode ser feita usando a CLI.
+ O Kerberos precisa estar instalado no cluster.
+ Aplicativos UIs (interfaces de usuário), como a interface do usuário do YARN Resource Manager, a interface do usuário do HDFS e a NameNode interface do usuário do Livy, não são configurados com autenticação por padrão.
+ As permissões padrão `umask` do HDFS são configuradas para que os objetos criados sejam definidos como `world wide readable` por padrão.
+ O Amazon EMR não oferece suporte ao modo de alta disponibilidade (múltiplo primário) com o Apache Ranger.
+ Para ver outras limitações, consulte as limitações de cada aplicação.
**nota**
As configurações de criptografia do Amazon EMR governam o SSE. Para obter mais informações, consulte [Encryption Options](emr-data-encryption-options.md).
## Limitações de plug-in
Cada plug-in tem limitações específicas. Para ver as limitações do plug-in Apache Hive, consulte as [limitações do plug-in Apache Hive](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-hive.html#emr-ranger-hive-limitations). Para ver as limitações do plug-in Apache Spark, consulte as [limitações do plug-in Apache Spark](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-spark.html#emr-ranger-spark-limitations). Para ver as limitações do plug-in EMRFS S3, consulte as [limitações do plug-in EMRFS S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-emrfs.html#emr-ranger-emrfs-limitations).
# Configurar o Amazon EMR para Apache Ranger
Antes de instalar o Apache Ranger, leia as informações desta seção para garantir que o Amazon EMR esteja configurado corretamente.
**Topics**
+ [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md)
+ [Perfis do IAM para integração nativa com o Apache Ranger](emr-ranger-iam.md)
+ [Criar a configuração de segurança do EMR](emr-ranger-security-config.md)
+ [Armazene certificados TLS em AWS Secrets Manager](emr-ranger-tls-certificates.md)
+ [Como iniciar um cluster do EMR com o Apache Ranger](emr-ranger-start-emr-cluster.md)
+ [Configurar o Zeppelin para clusters do Amazon EMR habilitados para Apache Ranger](emr-ranger-configure-zeppelin.md)
+ [Problemas conhecidos da integração do Amazon EMR](emr-ranger-security-considerations.md)
# Configure um servidor Ranger Admin para integração com o Amazon EMR
Para a integração com o Amazon EMR, os plug-ins da aplicação Apache Ranger devem se comunicar com o servidor de administração usando TLS/SSL.
**Pré-requisito: habilitar SSL do servidor Ranger Admin**
O Apache Ranger no Amazon EMR exige comunicação SSL bidirecional entre os plug-ins e o servidor Ranger Admin. Para garantir que os plug-ins se comuniquem com o servidor Apache Ranger via SSL, habilite o seguinte atributo em ranger-admin-site .xml no servidor Ranger Admin.
```
ranger.service.https.attrib.ssl.enabled
true
```
Além disso, as configurações a seguir são necessárias.
```
ranger.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.file
__
ranger.service.https.attrib.keystore.pass
__
ranger.service.https.attrib.keystore.keyalias
ranger.service.https.attrib.clientAuth
want
ranger.service.https.port
6182
```
# Certificados TLS para integração do Apache Ranger com o Amazon EMR
A integração do Apache Ranger com o Amazon EMR exige que o tráfego dos nós do Amazon EMR para o servidor Ranger Admin seja criptografado usando TLS e que os plug-ins do Ranger sejam autenticados no servidor Apache Ranger usando autenticação TLS mútua bidirecional. O serviço Amazon EMR precisa do certificado público do servidor Ranger Admin (especificado no exemplo anterior) e do certificado privado.
**Certificados de plug-in do Apache Ranger**
Os certificados TLS públicos de plug-in do Apache Ranger devem estar acessíveis ao servidor Apache Ranger Admin para validar quando os plug-ins se conectam. Há três métodos diferentes para isso.
**Método 1: configurar um armazenamento confiável no servidor Apache Ranger Admin**
Preencha as seguintes configurações em ranger-admin-site .xml para configurar um armazenamento confiável.
```
ranger.truststore.file
ranger.truststore.password
```
**Método 2: carregar o certificado no Java cacerts truststore**
Se o servidor Ranger Admin não especificar um armazenamento confiável em suas opções da JVM, você poderá colocar os certificados públicos do plug-in no armazenamento cacerts padrão.
**Método 3: criar um armazenamento confiável e especificar como parte das opções da JVM**
Em `{RANGER_HOME_DIRECTORY}/ews/ranger-admin-services.sh`, modifique `JAVA_OPTS` para incluir `"-Djavax.net.ssl.trustStore="` e `"-Djavax.net.ssl.trustStorePassword="`. Por exemplo, adicione a linha a seguir após o JAVA\$1OPTS atual.
```
JAVA_OPTS=" ${JAVA_OPTS} -Djavax.net.ssl.trustStore=${RANGER_HOME}/truststore/truststore.jck -Djavax.net.ssl.trustStorePassword=changeit"
```
**nota**
Essa especificação pode expor a senha do truststore se algum usuário conseguir fazer login no servidor Apache Ranger Admin e ver os processos em execução, como ao usar o comando `ps`.
**Usar certificados autoassinados**
Não é recomendável usar certificados autoassinados como certificados. Os certificados autoassinados não podem ser revogados e podem não estar em conformidade com os requisitos internos de segurança.
# Instalação da definição de serviço para integração do Ranger com o Amazon EMR
Uma definição de serviço é usada pelo servidor Ranger Admin para descrever os atributos das políticas de uma aplicação. As políticas são então armazenadas em um repositório de políticas para que os clientes baixem.
Para poder configurar as definições de serviço, as chamadas REST deverão ser feitas para o servidor Ranger Admin. Consulte [Apache Ranger Public APIsv2](https://ranger.apache.org/apidocs/resource_PublicAPIsv2.html#resource_PublicAPIsv2_createServiceDef_POST) para obter informações APIs obrigatórias na seção a seguir.
**Instalar a definição de serviço do Apache Spark**
Para instalar a definição de serviço do Apache Spark, consulte [Plug-in do Apache Spark para integração do Ranger com Amazon EMR](emr-ranger-spark.md).
**Instalar a definição de serviço do EMRFS**
Para instalar a definição de serviço do S3 para Amazon EMR, consulte [Plug-in EMRFS do S3 para integração do Ranger com o Amazon EMR](emr-ranger-emrfs.md).
**Usar a definição de serviço do Hive**
O Apache Hive pode usar a definição de serviço do Ranger já existente que vem com o Apache Ranger 2.0 e versões posteriores. Para obter mais informações, consulte [Plug-in do Apache Hive para integração do Ranger com Amazon EMR](emr-ranger-hive.md).
# Regras de tráfego de rede para integração com o Amazon EMR
Quando o Apache Ranger é integrado ao cluster do EMR, o cluster precisa se comunicar com outros servidores e com a AWS.
Todos os nós do Amazon EMR, inclusive os nós centrais e de tarefa, devem ser capazes de se comunicar com os servidores Apache Ranger Admin para baixar as políticas. Se o administrador do Apache Ranger estiver em execução no Amazon EC2, você precisará atualizar o grupo de segurança para poder receber tráfego do cluster do EMR.
Além de se comunicar com o servidor Ranger Admin, todos os nós precisam ser capazes de se comunicar com os seguintes serviços: AWS
+ Amazon S3
+ AWS KMS (se estiver usando o EMRFS SSE-KMS)
+ Amazon CloudWatch
+ AWS STS
Se você planeja executar seu cluster do EMR em uma sub-rede privada, configure a VPC para poder se comunicar com esses serviços usando [AWS PrivateLink e endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html), conforme o *Guia do Usuário da Amazon VPC* ou usando a [instância de conversão de endereços de rede (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html), seguindo o *Guia do usuário da Amazon VPC*.
# Perfis do IAM para integração nativa com o Apache Ranger
A integração entre o Amazon EMR e o Apache Ranger depende de três perfis principais que você deve criar antes de iniciar o cluster:
+ Um perfil de instância do Amazon EC2 personalizado para o Amazon EMR
+ Um perfil do IAM para mecanismos do Apache Ranger
+ Uma função do IAM para outros AWS serviços
Esta seção fornece uma visão geral desses perfis e das políticas que devem ser incluídas para cada perfil do IAM. Para obter mais informações sobre como criar esses perfis, consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md).
# Perfil de instância do EC2 no Amazon EMR
O Amazon EMR usa um perfil de serviço do IAM para realizar ações a seu favor a fim de provisionar e gerenciar clusters. O perfil de serviço para instâncias do EC2 do cluster, também chamada de perfil de instância do EC2 para Amazon EMR, é um tipo especial de perfil de serviço atribuído ao iniciar cada instância do EC2 do cluster.
Para definir permissões para a interação do cluster EMR com dados do Amazon S3 e com o metastore Hive protegido pelo Apache Ranger e AWS outros serviços, defina um perfil de instância EC2 personalizado para usar em vez do quando você iniciar seu cluster. `EMR_EC2_DefaultRole`
Para obter mais informações, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md) e [Personalização de perfis do IAM com o Amazon EMR](emr-iam-roles-custom.md).
Você precisa adicionar as seguintes instruções ao perfil de instância EC2 padrão do Amazon EMR para poder marcar sessões e acessar AWS Secrets Manager o que armazena certificados TLS.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam:::role/",
"arn:aws:iam:::role/"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:::secret:*",
"arn:aws:secretsmanager:::secret:*"
]
}
```
**nota**
Para obter as permissões do Secrets Manager, não esqueça o caractere curinga (“\$1”) no final do nome do segredo, senão as solicitações falharão. O curinga serve para versões de segredo.
**nota**
Limite o escopo da AWS Secrets Manager política somente aos certificados necessários para o provisionamento.
# Perfil do IAM para Apache Ranger
Esse perfil fornece credenciais para mecanismos de execução confiáveis, como Apache Hive e Amazon EMR Record Server, para acessar os dados do Amazon S3. Use somente esse perfil para acessar dados do Amazon S3, incluindo chaves do KMS, se você estiver usando o SSE-KMS do S3.
Esse perfil deve ser criado com a política mínima indicada no exemplo a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CloudwatchLogsPermissions",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Resource": [
"arn:aws:logs:*:123456789012:log-group:CLOUDWATCH_LOG_GROUP_NAME_IN_SECURITY_CONFIGURATION:*"
]
},
{
"Sid": "BucketPermissionsInS3Buckets",
"Action": [
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1",
"arn:aws:s3:::amzn-s3-demo-bucket2"
]
},
{
"Sid": "ObjectPermissionsInS3Objects",
"Action": [
"s3:GetObject",
"s3:DeleteObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
}
]
}
```
------
**Importante**
O asterisco “\$1” no final do recurso de CloudWatch log deve ser incluído para fornecer permissão para gravar nos fluxos de log.
**nota**
Se você estiver usando a visualização de consistência do EMRFS ou a criptografia S3-SSE, adicione permissões às tabelas do DynamoDB e às chaves do KMS para que os mecanismos de execução possam interagir com esses mecanismos.
O perfil do IAM para Apache Ranger é assumido pelo perfil do perfil de instância do EC2. Use o exemplo a seguir para criar uma política de confiança que permita que o perfil do IAM para o Apache Ranger seja assumido pelo perfil do perfil de instância do EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Função do IAM para outros AWS serviços de integração com o Amazon EMR
Essa função fornece aos usuários que não são mecanismos de execução confiáveis credenciais para interagir com os AWS serviços, se necessário. Não use esse perfil do IAM para permitir o acesso aos dados do Amazon S3, a menos que sejam dados que devam ser acessados por todos os usuários.
Esse perfil será assumido pelo perfil do perfil de instância do EC2. Use o exemplo a seguir para criar uma política de confiança que permita que o perfil do IAM para o Apache Ranger seja assumido pelo perfil do perfil de instância do EC2.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Validação de permissões para a integração do Amazon EMR com o Apache Ranger
Consulte [Solução de problemas do Apache Ranger](emr-ranger-troubleshooting.md) para ver instruções sobre como validar permissões.
# Criar a configuração de segurança do EMR
**Criar uma configuração de segurança do Amazon EMR para Apache Ranger**
Antes de iniciar um cluster do Amazon EMR integrado ao Apache Ranger, crie uma configuração de segurança.
------
#### [ Console ]
**Para criar uma configuração de segurança que especifique a opção de integração do AWS Ranger**
1. No console do Amazon EMR, selecione **Configurações de segurança** e depois **Criar**.
1. Digite um nome em **Name (Nome)** para a configuração de segurança. Esse nome é usado para especificar a configuração de segurança ao criar um cluster.
1. Em **Integração do AWS Ranger**, selecione **Habilitar controle de acesso granular gerenciado pelo Apache Ranger**.
1. Selecione o **perfil do IAM para Apache Ranger** a ser aplicado. Para obter mais informações, consulte [Perfis do IAM para integração nativa com o Apache Ranger](emr-ranger-iam.md).
1. Selecione o **Perfil do IAM para outros serviços da AWS ** a ser aplicado.
1. Configure os plug-ins para se conectar ao servidor Ranger Admin inserindo o ARN do Secrets Manager para o servidor Admin e o endereço.
1. Selecione as aplicações para configurar os plug-ins do Ranger. Insira o ARN do Secret Manager que contém o certificado TLS privado do plug-in.
Se você não configurar o Apache Spark ou o Apache Hive e eles forem selecionados como uma aplicação para seu cluster, a solicitação falhará.
1. Configure outras opções de configuração de segurança conforme apropriado e escolha **Create (Criar)**. Você deve habilitar a autenticação Kerberos usando o KDC externo ou dedicado ao cluster.
**nota**
No momento, você não pode usar o console para criar uma configuração de segurança que especifique a opção de integração do AWS Ranger no. AWS GovCloud (US) Region A configuração de segurança do pode ser feita usando a CLI.
------
#### [ CLI ]
**Criar uma configuração de segurança para integração do Apache Ranger**
1. ``Substitua pelo ID AWS da sua conta.
1. Substitua `` pela região em que o recurso está.
1. Especifique um valor para `TicketLifetimeInHours` para determinar o período durante o qual um ticket Kerberos emitido pelo KDC é válido.
1. Especifique o endereço do servidor Ranger Admin para `AdminServerURL`.
```
{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24
}
}
},
"AuthorizationConfiguration":{
"RangerConfiguration":{
"AdminServerURL":"https://__:6182",
"RoleForRangerPluginsARN":"arn:aws:iam::__:role/__",
"RoleForOtherAWSServicesARN":"arn:aws:iam::__:role/__",
"AdminServerSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"RangerPluginConfigurations":[
{
"App":"Spark",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Hive",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"EMRFS-S3",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
},
{
"App":"Trino",
"ClientSecretARN":"arn:aws:secretsmanager:__:__:secret:__",
"PolicyRepositoryName":""
}
],
"AuditConfiguration":{
"Destinations":{
"AmazonCloudWatchLogs":{
"CloudWatchLogGroup":"arn:aws:logs::__:log-group:__"
}
}
}
}
}
}
```
Esses PolicyRespositoryNames são os nomes dos serviços especificados em seu Apache Ranger Admin.
Crie uma configuração de segurança do Amazon EMR com o comando a seguir. Substitua a configuração de segurança por um nome a sua escolha. Selecione a configuração pelo nome ao criar o cluster.
```
aws emr create-security-configuration \
--security-configuration file://./security-configuration.json \
--name security-configuration
```
------
**Configurar atributos de segurança adicionais**
Para integrar o Amazon EMR ao Apache Ranger com segurança, configure os seguintes recursos de segurança do EMR:
+ Habilite a autenticação Kerberos usando o KDC externo ou dedicado ao cluster. Para instruções, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md).
+ (Opcional) Habilite a criptografia em trânsito ou em repouso. Para obter mais informações, consulte [Opções de criptografia do Amazon EMR](emr-data-encryption-options.md).
Para obter mais informações, consulte [Segurança no Amazon EMR](emr-security.md).
# Armazene certificados TLS em AWS Secrets Manager
Os plug-ins Ranger instalados em um cluster do Amazon EMR e o servidor Ranger Admin devem se comunicar por TLS para garantir que os dados da política e outras informações enviadas não possam ser lidos caso sejam interceptados. O EMR também exige que os plug-ins se autentiquem no servidor Ranger Admin fornecendo o próprio certificado TLS e realizando a autenticação TLS bidirecional. Essa configuração exigiu a criação de quatro certificados: dois pares de certificados TLS públicos e de privados. Para obter instruções sobre como instalar o certificado no servidor Ranger Admin, consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md). Para concluir a configuração, os plug-ins Ranger instalados no cluster do EMR precisam de dois certificados: o certificado TLS público do servidor de administrador e o certificado privado que o plug-in usará para se autenticar no servidor Ranger Admin. Para fornecer esses certificados TLS, eles devem estar no AWS Secrets Manager e fornecidos em uma configuração de segurança do EMR.
**nota**
É altamente recomendável, mas não obrigatório, criar um par de certificados para cada uma das aplicações para limitar o impacto se um dos certificados do plug-in for comprometido.
**nota**
É necessário rastrear e alternar os certificados antes da data de vencimento.
## Formato do certificado
A importação dos certificados para o AWS Secrets Manager é a mesma, independentemente de ser o certificado de plug-in privado ou o certificado de administrador público do Ranger. Antes de importar os certificados TLS, os certificados deverão estar no formato 509x PEM.
Este é o formato de um exemplo de certificado público:
```
-----BEGIN CERTIFICATE-----
...Certificate Body...
-----END CERTIFICATE-----
```
Este é o formato de um exemplo de certificado privado:
```
-----BEGIN PRIVATE KEY-----
...Private Certificate Body...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...Trust Certificate Body...
-----END CERTIFICATE-----
```
O certificado privado também deverá conter um certificado de confiança.
É possível validar se os certificados estão no formato correto executando o seguinte comando:
```
openssl x509 -in -text
```
## Importando um certificado para o AWS Secrets Manager
Ao criar seu segredo no Secrets Manager, escolha **Outro tipo de segredos** em **Tipo de segrdo** e cole o certificado codificado PEM no campo **Texto sem formatação**.
![\[Importando um certificado para o. AWS Secrets Manager\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-tls-cert-import.png)
# Como iniciar um cluster do EMR com o Apache Ranger
Antes de iniciar um cluster do Amazon EMR com o Apache Ranger, certifique-se de que todos os componentes atendam aos seguintes requisitos mínimos de versão:
+ Amazon EMR 5.32.0 ou versões posteriores ou 6.3.0 ou versões posteriores. É recomendável usar a versão mais recente do Amazon EMR.
+ Servidor Apache Ranger Admin 2.x.
Execute as etapas a seguir.
+ Instale o Apache Ranger, caso ainda não tenha instalado. Para obter mais informações sobre a instalação, consulte [Apache Ranger 0.5.0 installation](https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+0.5.0+Installation).
+ Verifique se há conectividade de rede entre o cluster do Amazon EMR e o servidor Apache Ranger Admin. Consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md)
+ Crie os perfis do IAM necessários. Consulte [Perfis do IAM para integração nativa com o Apache Ranger](emr-ranger-iam.md).
+ Crie uma configuração de segurança do EMR para a instalação do Apache Ranger. Veja mais informações em [Criar a configuração de segurança do EMR](emr-ranger-security-config.md).
# Configurar o Zeppelin para clusters do Amazon EMR habilitados para Apache Ranger
O tópico aborda como configurar o [Apache Zeppelin](https://zeppelin.apache.org/) para um cluster do Amazon EMR habilitado para Apache Ranger para que você possa usar o Zeppelin como um caderno para explorar dados de maneira interativa. O Zeppelin é incluído no Amazon EMR 5.0.0 e versões posteriores. As versões anteriores incluem o Zeppelin como uma aplicação sandbox. Para obter mais informações, consulte [Amazon EMR 4.x release versions](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-4x.html) no *Guia de lançamento do Amazon EMR*.
Por padrão, o Zeppelin é configurado com um login e uma senha padrão que não são seguros em um ambiente multilocatário.
Para configurar o Zeppelin, siga as etapas a seguir.
1. **Modificar o mecanismo de autenticação**.
Modifique o arquivo `shiro.ini` para implementar o mecanismo de autenticação de sua preferência. O Zeppelin oferece suporte a Active Directory, LDAP, PAM e Knox SSO. Consulte [Apache Shiro authentication for Apache Zeppelin](https://zeppelin.apache.org/docs/0.8.2/setup/security/shiro_authentication.html) para obter mais informações.
1. **Configurar o Zeppelin para representar o usuário final**
Quando você permite que o Zeppelin represente o usuário final, os trabalhos enviados pelo Zeppelin podem ser executados como esse usuário final. Adicione o seguinte à configuração de `core-site.xml`:
```
[
{
"Classification": "core-site",
"Properties": {
"hadoop.proxyuser.zeppelin.hosts": "*",
"hadoop.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Em seguida, adicione a seguinte configuração a `hadoop-kms-site.xml` localizado em `/etc/hadoop/conf`:
```
[
{
"Classification": "hadoop-kms-site",
"Properties": {
"hadoop.kms.proxyuser.zeppelin.hosts": "*",
"hadoop.kms.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
Também é possível adicionar essas configurações ao cluster do Amazon EMR usando o console seguindo as etapas descritas em [Reconfigure an instance group in the console](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html#emr-configure-apps-running-cluster-console).
1. **Permitir que o Zeppelin se torne o usuário final**
Crie um arquivo `/etc/sudoers.d/90-zeppelin-user` que contenha:
```
zeppelin ALL=(ALL) NOPASSWD:ALL
```
1. **Modificar as configurações dos intérpretes para executar trabalhos do usuário em seus próprios processos**.
Configure todos os intérpretes para instanciar os intérpretes “Por usuário” em processos “isolados”.
![\[Diagrama de arquitetura do Amazon EMR e do Apache Ranger.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/per_user.png)
1. **Modificar `zeppelin-env.sh`**
Adicione isto a `zeppelin-env.sh` que o Zeppelin comece a iniciar intérpretes como usuário final:
```
ZEPPELIN_IMPERSONATE_USER=`echo ${ZEPPELIN_IMPERSONATE_USER} | cut -d @ -f1`
export ZEPPELIN_IMPERSONATE_CMD='sudo -H -u ${ZEPPELIN_IMPERSONATE_USER} bash -c'
```
Adicione isto a `zeppelin-env.sh` para alterar as permissões padrão de caderno para somente leitura para o criador:
```
export ZEPPELIN_NOTEBOOK_PUBLIC="false"
```
Por fim, adicione o seguinte `zeppelin-env.sh` para incluir o caminho da RecordServer classe EMR após a primeira `CLASSPATH` declaração:
```
export CLASSPATH="$CLASSPATH:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-connector-common.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-spark-connector.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-client.jar:/usr/share/aws/emr/record-server/lib/aws-emr-record-server-common.jar:/usr/share/aws/emr/record-server/lib/jars/secret-agent-interface.jar"
```
1. **Reiniciar o Zeppelin.**
Execute o seguinte comando para reiniciar o Zeppelin:
```
sudo systemctl restart zeppelin
```
# Problemas conhecidos da integração do Amazon EMR
**Problemas conhecidos**
Há um problema conhecido na versão 5.32 do Amazon EMR em que as permissões `hive-site.xml` foram alteradas para que somente usuários privilegiados possam lê-las, pois pode haver credenciais armazenadas nelas. Isso pode impedir que o Hue leia `hive-site.xml` e fazer com que as páginas da Web sejam recarregadas continuamente. Se você tiver esse problema, adicione esta configuração para corrigir o problema:
```
[
{
"Classification": "hue-ini",
"Properties": {},
"Configurations": [
{
"Classification": "desktop",
"Properties": {
"server_group":"hive_site_reader"
},
"Configurations":[
]
}
]
}
]
```
Há um problema conhecido de que o plug-in EMRFS S3 para Apache Ranger atualmente não oferece suporte ao atributo Security Zone do Apache Ranger. As restrições de controle de acesso definidas usando o atributo Security Zone não são aplicadas aos clusters do Amazon EMR.
**Aplicativo UIs**
Por padrão, as IUs de aplicações não realizam autenticação. Isso inclui a ResourceManager interface do usuário, a NodeManager interface do usuário, a interface do usuário Livy, entre outras. Além disso, qualquer usuário que tenha a capacidade de acessar o UIs é capaz de visualizar informações sobre os trabalhos de todos os outros usuários.
Se esse comportamento não for desejado, você deve garantir que um grupo de segurança seja usado para restringir o acesso dos usuários UIs ao aplicativo.
**Permissões padrão do HDFS**
Por padrão, os objetos que os usuários criam no HDFS recebem permissões de leitura mundial. Isso poderá tornar os dados legíveis por usuários que não deveriam ter acesso a eles. Para alterar esse comportamento de modo que as permissões de arquivo padrão sejam definidas para leitura e gravação somente pelo criador do trabalho, execute as etapas a seguir.
Ao criar o cluster do EMR, forneça a seguinte configuração:
```
[
{
"Classification": "hdfs-site",
"Properties": {
"dfs.namenode.acls.enabled": "true",
"fs.permissions.umask-mode": "077",
"dfs.permissions.superusergroup": "hdfsadmingroup"
}
}
]
```
Além disso, execute esta ação de bootstrap:
```
--bootstrap-actions Name='HDFS UMask Setup',Path=s3://elasticmapreduce/hdfs/umask/umask-main.sh
```
# Plug-ins do Apache Ranger para cenários de integração do Amazon EMR
Os plug-ins Apache Ranger validam o acesso de um usuário em relação às políticas de autorização definidas no servidor de administração de políticas do Apache Ranger.
**Topics**
+ [Plug-in do Apache Hive para integração do Ranger com Amazon EMR](emr-ranger-hive.md)
+ [Plug-in do Apache Spark para integração do Ranger com Amazon EMR](emr-ranger-spark.md)
+ [Plug-in EMRFS do S3 para integração do Ranger com o Amazon EMR](emr-ranger-emrfs.md)
+ [Plug-in Trino para integração do Ranger com o Amazon EMR](emr-ranger-trino.md)
# Plug-in do Apache Hive para integração do Ranger com Amazon EMR
O Apache Hive é um mecanismo de execução bastante usado dentro do ecossistema Hadoop. O Amazon EMR fornece um plug-in Apache Ranger para poder proporcionar controles de acesso refinados para o Hive. O plug-in é compatível com o servidor Apache Ranger Admin de código aberto versão 2.0 e posteriores.
**Topics**
+ [Recursos compatíveis](#emr-ranger-supported-features)
+ [Instalação da configuração de serviço](#emr-ranger-hive-service-config)
+ [Considerações](#emr-ranger-hive-considerations)
+ [Limitações](#emr-ranger-hive-limitations)
## Recursos compatíveis
O plug-in Apache Ranger para Hive no EMR oferece suporte a todas as funcionalidades do plug-in de código aberto, que inclui controles de acesso em nível de banco de dados, tabela e coluna, filtragem de linhas e mascaramento de dados. Para ver uma tabela dos comandos do Hive e das permissões associadas do Ranger, consulte [Hive commands to Ranger permission mapping](https://cwiki.apache.org/confluence/display/RANGER/Hive+Commands+to+Ranger+Permission+Mapping).
## Instalação da configuração de serviço
O plug-in Apache Hive é compatível com a definição de serviço Hive já existente no Apache Hive Hadoop SQL.
![\[Definição de serviço Apache Hive para Hadoop SQL.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger_service_mgr.png)
Caso não tenha uma instância de serviço no Hadoop SQL, como mostrado acima, você pode criar uma. Clique em **\$1** ao lado do Hadoop SQL.
1. **Nome do serviço (se for exibido)**: insira o nome do serviço. O valor sugerido é **amazonemrhive**. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração de segurança do EMR.
1. **Nome de exibição**: insira o nome a ser exibido para o serviço. O valor sugerido é **amazonemrhive**.
![\[Detalhes do serviço Apache Hive para Hadoop SQL.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger_create_service.png)
As propriedades de configuração do Apache Hive são usadas para estabelecer uma conexão com seu servidor Apache Ranger Admin com um 2 HiveServer para implementar o preenchimento automático ao criar políticas. As propriedades abaixo não precisam ser precisas se você não tiver um processo persistente HiveServer 2 e puderem ser preenchidas com qualquer informação.
+ **Nome de usuário**: insira um nome de usuário para a conexão JDBC com uma instância de HiveServer 2 instâncias.
+ **Senha**: insira a senha do nome de usuário acima.
+ **jdbc. driver. ClassName**: insira o nome da classe JDBC para conectividade com o Apache Hive. O valor padrão pode ser usado.
+ **jdbc.url**: insira a string de conexão JDBC a ser usada ao se conectar a 2. HiveServer
+ **Nome comum para certificado**: o campo CN dentro do certificado usado para se conectar ao servidor de administração com base em um plug-in cliente. Esse valor deve corresponder ao campo CN do certificado TLS que foi criado para o plug-in.
![\[Propriedades de configuração do serviço Apache Hive.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger_config_props.png)
O botão **Testar conexão** testa se os valores acima podem ser usados para se conectar com êxito à instância HiveServer 2. Depois que o serviço for criado com êxito, o Service Manager deverá ficará semelhante a isto:
![\[Conectado à instância HiveServer 2\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger_config_connected.png)
## Considerações
**Servidor de metadados Hive**
O servidor de metadados Hive só pode ser acessado por mecanismos confiáveis, especificamente o Hive e `emr_record_server`, para proteção contra acesso não autorizado. O servidor de metadados Hive também é acessado por todos os nós do cluster. A porta 9083 necessária fornece acesso de todos os nós ao nó principal.
**Autenticação**
Por padrão, o Apache Hive está configurado para se autenticar usando Kerberos conforme configurado na configuração do EMR Security. HiveServer2 também pode ser configurado para autenticar usuários usando o LDAP. Consulte [Implementing LDAP authentication for Hive on a multi-tenant Amazon EMR cluster](https://aws.amazon.com/blogs/big-data/implementing-ldap-authentication-for-hive-on-a-multi-tenant-amazon-emr-cluster/) para obter informações.
## Limitações
Estas são as limitações atuais do plug-in Apache Hive no Amazon EMR 5.x:
+ Não há suporte para perfis do Hive atualmente. Não há suporte para instruções Grant e Revoke.
+ A CLI do Hive não é suportada. JDBC/Beeline é a única forma autorizada de conectar o Hive.
+ `hive.server2.builtin.udf.blacklist`a configuração deve ser preenchida com o UDFs que você considera inseguro.
# Plug-in do Apache Spark para integração do Ranger com Amazon EMR
O Amazon EMR integrou o EMR RecordServer para fornecer controle de acesso refinado para o SparkSQL. O EMR RecordServer é um processo privilegiado executado em todos os nós em um cluster habilitado para Apache Ranger. Quando um driver ou executor do Spark executa uma instrução SparkSQL, todos os metadados e solicitações de dados passam pelo. RecordServer Para saber mais sobre o EMR RecordServer, consulte a [Componentes do Amazon EMR para uso com o Apache Ranger](emr-ranger-components.md) página.
**Topics**
+ [Recursos compatíveis](#emr-ranger-spark-supported-features)
+ [Reimplantar a definição de serviço para usar instruções INSERT, ALTER ou DDL](#emr-ranger-spark-redeploy-service-definition)
+ [Instalação da definição de serviço](#emr-ranger-spark-install-servicedef)
+ [Criar políticas SparkSQL](#emr-ranger-spark-create-sparksql)
+ [Considerações](#emr-ranger-spark-considerations)
+ [Limitações](#emr-ranger-spark-limitations)
## Recursos compatíveis
| statement/Ranger Ação SQL | STATUS | Versão do EMR compatível |
| --- | --- | --- |
| SELECT | Compatível | A partir da 5.32 |
| SHOW DATABASES | Compatível | A partir da 5.32 |
| SHOW COLUMNS | Compatível | A partir da 5.32 |
| SHOW TABLES | Compatível | A partir da 5.32 |
| SHOW TABLE PROPERTIES | Compatível | A partir da 5.32 |
| DESCRIBE TABLE | Compatível | A partir da 5.32 |
| INSERT OVERWRITE | Compatível | A partir da 5.34 e 6.4 |
| INSERT INTO | Compatível | A partir da 5.34 e 6.4 |
| ALTER TABLE | Compatível | A partir da 6.4 |
| CRIAR TABELA | Compatível | A partir da 5.35 e 6.7 |
| CREATE DATABASE | Compatível | A partir da 5.35 e 6.7 |
| DESCARTAR TABELA | Compatível | A partir da 5.35 e 6.7 |
| DROP DATABASE | Compatível | A partir da 5.35 e 6.7 |
| DROP VIEW | Compatível | A partir da 5.35 e 6.7 |
| CREATE VIEW | Não suportado | |
Os seguintes atributos são compatíveis com o uso do SparkSQL:
+ Controle de acesso refinado em tabelas dentro do Hive Metastore, e é possível criar políticas em nível de banco de dados, tabela e coluna.
+ As políticas do Apache Ranger podem incluir políticas de concessão e políticas de negação para usuários e grupos.
+ Os eventos de auditoria são enviados para o CloudWatch Logs.
## Reimplantar a definição de serviço para usar instruções INSERT, ALTER ou DDL
**nota**
A partir do Amazon EMR 6.4, é possível usar o Spark SQL com as instruções: INSERT INTO, INSERT OVERWRITE ou ALTER TABLE. A partir do Amazon EMR 6.7, é possível usar o Spark SQL para criar ou eliminar bancos de dados e tabelas. Se você já tiver uma instalação no servidor Apache Ranger com definições de serviço Apache Spark implantadas, use o código a seguir para reimplantar as definições de serviço.
```
# Get existing Spark service definition id calling Ranger REST API and JSON processor
curl --silent -f -u : \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/name/amazon-emr-spark' | jq .id
# Download the latest Service definition
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
# Update the service definition using the Ranger REST API
curl -u : -X PUT -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef/'
```
## Instalação da definição de serviço
A instalação da definição de serviço Apache Spark do EMR exige que o servidor Ranger Admin esteja configurado. Consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md).
Siga estas etapas para instalar a definição de serviço Apache Spark:
**Etapa 1: SSH no servidor Apache Ranger Admin**
Por exemplo:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Etapa 2: baixar a definição de serviço e o plug-in do servidor Apache Ranger Admin**
Em um diretório temporário, baixe a definição de serviço. Essa definição de serviço é compatível com as versões Ranger 2.x.
```
mkdir /tmp/emr-spark-plugin/
cd /tmp/emr-spark-plugin/
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-spark-plugin-2.x.jar
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-spark.json
```
**Etapa 3: instalar o plug-in Apache Spark para Amazon EMR**
```
export RANGER_HOME=.. # Replace this Ranger Admin's home directory eg /usr/lib/ranger/ranger-2.0.0-admin
mkdir $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
mv ranger-spark-plugin-2.x.jar $RANGER_HOME/ews/webapp/WEB-INF/classes/ranger-plugins/amazon-emr-spark
```
**Etapa 4: registrar a definição de serviço Apache Spark para Amazon EMR**
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-spark.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se esse comando for executado com êxito, você verá um novo serviço na interface de usuário do Ranger Admin chamado “AMAZON-EMR-SPARK”, conforme mostrado na imagem a seguir (a versão 2.0 do Ranger é exibida).
![\[“AMAZON-EMR-SPARK” registrado no Ranger Admin.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark.png)
**Etapa 5: criar uma instância do AMAZON-EMR-SPARK aplicativo**
**Nome do serviço (se for exibido):** o nome do serviço que será usado. O valor sugerido é **amazonemrspark**. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração de segurança do EMR.
**Nome de exibição:** o nome a ser exibido para a instância. O valor sugerido é **amazonemrspark**.
**Nome comum para certificado:** o campo CN dentro do certificado usado para se conectar ao servidor de administração com base em um plug-in cliente. Esse valor deve corresponder ao campo CN do certificado TLS que foi criado para o plug-in.
![\[O Ranger Admin cria o serviço.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-service.png)
**nota**
O certificado TLS para o plug-in deveria ter sido registrado no armazenamento confiável do servidor Ranger Admin. Consulte [Certificados TLS para integração do Apache Ranger com o Amazon EMR](emr-ranger-admin-tls.md) para obter mais detalhes.
## Criar políticas SparkSQL
Ao criar uma nova política, os campos a serem preenchidos são:
**Nome da política**: o nome da política.
**Rótulo de política**: um rótulo que você pode colocar na política.
**Banco de dados**: o banco de dados ao qual a política se aplica. O caractere curinga “\$1” representa todos os bancos de dados.
**Tabela**: as tabelas às quais a política se aplica. O caractere curinga “\$1” representa todas as tabelas.
**Coluna do EMR Spark**: as colunas às quais a política se aplica. O caractere curinga “\$1” representa todas as colunas.
**Descrição**: uma descrição da política.
![\[O Ranger Admin cria detalhes da política do SparkSQL.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-details.png)
Para especificar usuários e grupos, insira os usuários e grupos abaixo para conceder permissões. Também é possível especificar exclusões para as condições de **permissão** e **negação**.
![\[Os detalhes da política SparkSQL do Ranger Admin permitem condições.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions.png)
Após especificar as condições de permitir e negar, clique em **Salvar**.
## Considerações
Cada nós do cluster do EMR deve ser capaz de se conectar ao nó principal na porta 9083.
## Limitações
Estas são as limitações atuais do plug-in Apache Spark:
+ O Record Server sempre se conectará ao HMS que está em execução em um cluster do Amazon EMR. Configure o HMS para se conectar ao modo remoto, se necessário. Você não deve colocar valores de configuração no arquivo de configuração Hive-site.xml do Apache Spark.
+ As tabelas criadas usando fontes de dados do Spark em CSV ou Avro não podem ser lidas usando o EMR. RecordServer Utilize o Hive para criar e gravar dados e ler usando Record.
+ Não há suporte para tabelas do Delta Lake, Hudi e Iceberg.
+ Os usuários precisam ter acesso ao banco de dados padrão. Esse é um requisito do Apache Spark.
+ O servidor Ranger Admin não oferece suporte ao preenchimento automático.
+ O plug-in SparkSQL para Amazon EMR não oferece suporte a filtros de linha ou a mascaramento de dados.
+ Ao ser usado ALTER TABLE com Spark SQL, o local da partição deve ser o diretório filho do local de uma tabela. Não há suporte para inserção de dados em uma partição em que a localização da partição seja diferente da localização da tabela.
# Plug-in EMRFS do S3 para integração do Ranger com o Amazon EMR
Para facilitar o fornecimento de controles de acesso contra objetos no S3 em um cluster multilocatário, o plug-in EMRFS S3 fornece controles de acesso aos dados no S3 ao acessá-los pelo EMRFS. Você pode permitir acesso aos recursos do S3 em nível de usuário e grupo.
Para conseguir isso, quando sua aplicação tenta acessar dados no S3, o EMRFS envia uma solicitação de credenciais ao processo do agente secreto, onde a solicitação é autenticada e autorizada em um plug-in Apache Ranger. Se a solicitação for autorizada, o agente secreto assumirá o perfil do IAM para os mecanismos do Apache Ranger com uma política restrita para gerar credenciais que só tenham acesso à política Ranger que permitiu o acesso. As credenciais então são repassadas ao EMRFS para acessar o S3.
**Topics**
+ [Recursos compatíveis](#emr-ranger-emrfs-features)
+ [Instalação da configuração de serviço](#emr-ranger-emrfs-service-config)
+ [Criar políticas do EMRFS S3](#emr-ranger-emrfs-create-policies)
+ [Notas sobre o uso das políticas do EMRFS S3](#emr-ranger-emrfs-considerations)
+ [Limitações](#emr-ranger-emrfs-limitations)
## Recursos compatíveis
O plug-in EMRFS S3 concede autorização de nível de armazenamento. Políticas podem ser criadas para conceder acesso a usuários e grupos a buckets e prefixos do S3. A autorização é feita somente em relação ao EMRFS.
## Instalação da configuração de serviço
Para instalar a definição do serviço EMRFS, você deve configurar o servidor Ranger Admin. Para configurar o servidor, consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md).
Siga estas etapas para instalar a definição de serviço do EMRFS.
**Etapa 1: SSH no servidor Apache Ranger Admin**.
Por exemplo:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Etapa 2: download da definição do serviço EMRFS**.
Em um diretório temporário, baixe a definição de serviço do Amazon EMR. Essa definição de serviço é compatível com as versões Ranger 2.x.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json
```
**Etapa 3: registrar a definição de serviço do S3 para EMRFS**.
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-emrfs.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se esse comando for executado com êxito, você verá um novo serviço na interface de usuário do Ranger Admin chamado “AMAZON-EMR-S3”, conforme mostrado na imagem a seguir (a versão 2.0 do Ranger é exibida).
![\[O Ranger Admin cria o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png)
**Etapa 4: Crie uma instância do AMAZON-EMR-EMRFS aplicativo**.
Crie uma instância da definição de serviço.
+ Clique no **\$1** ao lado de AMAZON-EMR-EMRFS.
Preencha os seguintes campos:
**Nome do serviço (se for exibido)**: o valor sugerido é **amazonemrs3**. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração de segurança do EMR.
**Nome de exibição**: o nome exibido para o serviço. O valor sugerido é **amazonemrs3**.
**Nome comum para certificado:** o campo CN dentro do certificado usado para se conectar ao servidor de administração com base em um plug-in cliente. Esse valor deve corresponder ao campo CN no certificado TLS criado para o plug-in.
![\[Ranger Admin edita o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png)
**nota**
O certificado TLS para o plug-in deveria ter sido registrado no armazenamento confiável do servidor Ranger Admin. Consulte [Certificados TLS para integração do Apache Ranger com o Amazon EMR](emr-ranger-admin-tls.md) para obter mais detalhes.
Quando o serviço é criado, o Service Manager inclui “AMAZON-EMR-EMRFS”, conforme mostra a imagem a seguir.
![\[Ranger Admin mostrando o novo serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png)
## Criar políticas do EMRFS S3
Para criar uma nova política na página **Criar política** do Service Manager, preencha os campos a seguir.
**Nome da política**: o nome da política.
**Rótulo de política**: um rótulo que você pode colocar na política.
**Recurso do S3**: um recurso que começa com o bucket e o prefixo opcional. Consulte [Notas sobre o uso das políticas do EMRFS S3](#emr-ranger-emrfs-considerations) para obter informações sobre práticas recomendadas. Os recursos no servidor Ranger Admin não devem conter **s3://**, **s3a://** ou **s3n://**.
![\[Administrador do Ranger mostrando a política de criação para o serviço EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png)
É possível especificar usuários e grupos para conceder permissões. Também é possível especificar exclusões para condições de **permissão** e **negação**.
![\[Administrador do Ranger mostrando user/group permissões para a política do EMRFS S3.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png)
**nota**
São permitidos no máximo três recursos por política. Adicionar mais de três recursos poderá resultar em um erro quando essa política é usada em um cluster do EMR. Adicionar mais de três políticas exibirá um lembrete sobre o limite da política.
## Notas sobre o uso das políticas do EMRFS S3
Ao criar políticas do S3 no Apache Ranger, atente para algumas considerações sobre o uso.
### Permissões para múltiplos objetos do S3
É possível usar políticas recursivas e expressões curinga para conceder permissões a vários objetos do S3 com prefixos comuns. As políticas recursivas concedem permissões a todos os objetos com um prefixo comum. As expressões curinga selecionam múltiplos prefixos. Juntos, eles concedem permissões a todos os objetos com múltiplos prefixos comuns, conforme mostrado nos exemplos a seguir.
**Example Usar uma política recursiva**
Suponha que você queira permissões para listar todos os arquivos parquet em um bucket do S3 organizado da forma a seguir.
```
s3://sales-reports/americas/
+- year=2000
| +- data-q1.parquet
| +- data-q2.parquet
+- year=2019
| +- data-q1.json
| +- data-q2.json
| +- data-q3.json
| +- data-q4.json
|
+- year=2020
| +- data-q1.parquet
| +- data-q2.parquet
| +- data-q3.parquet
| +- data-q4.parquet
| +- annual-summary.parquet
+- year=2021
```
Primeiro, considere os arquivos parquet que tenham o prefixo `s3://sales-reports/americas/year=2000`. Você pode conceder GetObject permissões a todos eles de duas maneiras:
**Usar políticas não recursivas**: uma opção é usar duas políticas não recursivas separadas, uma para o diretório e outra para os arquivos.
A primeira política concede permissão ao prefixo `s3://sales-reports/americas/year=2020` (não há `/` final).
```
- S3 resource = "sales-reports/americas/year=2000"
- permission = "GetObject"
- user = "analyst"
```
A segunda política usa a expressão curinga para conceder permissões a todos os arquivos com prefixo `sales-reports/americas/year=2020/` (observe o `/` final).
```
- S3 resource = "sales-reports/americas/year=2020/*"
- permission = "GetObject"
- user = "analyst"
```
**Usar uma política recursiva**: uma alternativa mais conveniente é usar uma única política recursiva e conceder permissão recursiva ao prefixo.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
Até agora, apenas os arquivos parquet com o prefixo `s3://sales-reports/americas/year=2000` foram incluídos. Também já é possível incluir os arquivos parquet com outro prefixo, `s3://sales-reports/americas/year=2020`, na mesma política recursiva introduzindo uma expressão curinga da forma a seguir.
```
- S3 resource = "sales-reports/americas/year=20?0"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Políticas PutObject e DeleteObject permissões
Escrever políticas `PutObject` e `DeleteObject` permissões para arquivos no EMRFS precisa de cuidados especiais porque, diferentemente das GetObject permissões, elas precisam de permissões recursivas adicionais concedidas ao prefixo.
**Example Políticas PutObject e DeleteObject permissões**
Por exemplo, excluir o arquivo `annual-summary.parquet` requer não apenas uma DeleteObject permissão para o arquivo real.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "DeleteObject"
- user = "analyst"
```
Também requer uma política que conceda permissões `GetObject` e `PutObject` recursivas para o prefixo.
Da mesma forma, modificar o arquivo `annual-summary.parquet` requer não apenas uma permissão `PutObject` para o arquivo real.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "PutObject"
- user = "analyst"
```
Também requer uma política que conceda a permissão `GetObject` recursiva para o prefixo.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Curingas em políticas
Há duas áreas em que é possível especificar caracteres curingas. Ao especificar um recurso do S3, pode-se usar “\$1” e “?”. O “\$1” faz correspondência com um caminho do S3 e corresponde a tudo que está depois do prefixo. Por exemplo, a política a seguir.
```
S3 resource = "sales-reports/americas/*"
```
Isso corresponde aos caminhos do S3 a seguir.
```
sales-reports/americas/year=2020/
sales-reports/americas/year=2019/
sales-reports/americas/year=2019/month=12/day=1/afile.parquet
sales-reports/americas/year=2018/month=6/day=1/afile.parquet
sales-reports/americas/year=2017/afile.parquet
```
O curinga “?” corresponde a apenas um caractere. Por exemplo, para a política.
```
S3 resource = "sales-reports/americas/year=201?/"
```
Isso corresponde aos caminhos do S3 a seguir.
```
sales-reports/americas/year=2019/
sales-reports/americas/year=2018/
sales-reports/americas/year=2017/
```
### Curingas em usuários
Há dois curingas integrados ao atribuir usuários para fornecer acesso aos usuários. O primeiro é o curinga “\$1USER\$1” que concede acesso a todos os usuários. O segundo caractere curinga é “\$1OWNER\$1”, que concede acesso direto ao proprietário de um objeto específico. No entanto, atualmente não há suporte para o curinga “\$1USER\$1”.
## Limitações
Estas são as limitações atuais do plug-in EMRFS S3:
+ As políticas do Apache Ranger podem conter no máximo três políticas.
+ O acesso ao S3 deve ser feito pelo EMRFS e pode ser usado com aplicações relacionadas ao Hadoop. Não há suporte para:
- Bibliotecas Boto3
- AWS SDK e AWK CLI
- Conector de código aberto S3A
+ Não há suporte para políticas de negação do Apache Ranger.
+ Atualmente, não há suporte para operações no S3 com chaves com criptografia do CSE-KMS.
+ O suporte entre regiões não é compatível.
+ Não há suporte para o atributo de zona de segurança do Apache Ranger. As restrições de controle de acesso definidas usando o atributo Security Zone não são aplicadas aos clusters do Amazon EMR.
+ O usuário do Hadoop não gera nenhum evento de auditoria, pois o Hadoop sempre acessa o perfil de instância do EC2.
+ É recomendável desabilitar a visualização consistente do Amazon EMR. O S3 do tem um alto nível de consistência e, portanto, isso não é mais necessário. Para obter mais informações, consulte [Amazon S3 strong consistency](https://aws.amazon.com/s3/consistency/).
+ O plug-in EMRFS S3 efetua várias chamadas STS. É recomendável fazer testes de carga em uma conta de desenvolvimento e monitorar o volume de chamadas do STS. Também é recomendável que você faça uma solicitação STS para aumentar os limites do AssumeRole serviço.
+ O servidor Ranger Admin não oferece suporte ao preenchimento automático.
# Plug-in Trino para integração do Ranger com o Amazon EMR
O Trino (antes chamado PrestoSQL) é um mecanismo de consulta SQL que pode ser usado para executar consultas em fontes de dados como HDFS, armazenamento de objetos, bancos de dados relacionais e bancos de dados NoSQL. Ele elimina a necessidade de migrar dados para um local central e permite a consulta de dados de qualquer lugar. O Amazon EMR fornece um plug-in Apache Ranger para proporcionar controles de acesso refinados para o Trino. O plug-in é compatível com o servidor Apache Ranger Admin de código aberto versão 2.0 e posteriores.
**Topics**
+ [Recursos compatíveis](#emr-ranger-trino-features)
+ [Instalação da configuração de serviço](#emr-ranger-trino-service-config)
+ [Criar políticas do Trino](#emr-ranger-trino-create-policies)
+ [Considerações](#emr-ranger-trino-considerations)
+ [Limitações](#emr-ranger-trino-limitations)
## Recursos compatíveis
O plug-in Apache Ranger para Trino no Amazon EMR oferece suporte a todos os recursos do mecanismo de consulta Trino, que é protegido por um controle de acesso refinado. Isso inclui controles de acesso em nível de banco de dados, de tabela e de coluna, filtragem de linhas e mascaramento de dados. As políticas do Apache Ranger podem incluir políticas de concessão e políticas de negação para usuários e grupos. Os eventos de auditoria também são enviados aos CloudWatch registros.
## Instalação da configuração de serviço
A instalação da definição de serviço Trino requer que o servidor Ranger Admin esteja configurado. Para configurar o servidor Ranger Admin, consulte [Configure um servidor Ranger Admin para integração com o Amazon EMR](emr-ranger-admin.md).
Siga estas etapas para instalar a definição de serviço do Trino.
1. SSH no servidor Apache Ranger Admin.
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
1. Desinstale o plug-in do servidor Presto, se houver. Execute o comando a seguir. Se isso ocorrer com o erro “Serviço não encontrado”, significa que o plug-in do servidor Presto não foi instalado no servidor. Prossiga para a próxima etapa.
```
curl -f -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X DELETE -k 'https://**:6182/service/public/v2/api/servicedef/name/presto'
```
1. Baixe a definição de serviço e o plug-in do servidor Apache Ranger Admin. Em um diretório temporário, baixe a definição de serviço. Essa definição de serviço é compatível com as versões Ranger 2.x.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-trino.json
```
1. Registre a definição de serviço do Apache Trino para o Amazon EMR.
```
curl -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X POST -d @ranger-servicedef-amazon-emr-trino.json \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-k 'https://**:6182/service/public/v2/api/servicedef'
```
Se esse comando for executado com êxito, você verá um novo serviço na IU do Ranger Admin chamado `TRINO`, conforme mostrado na imagem.
![\[O Ranger Admin cria o serviço.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-service-trino.png)
1. Crie uma instância da aplicação `TRINO`, inserindo as informações a seguir.
**Nome do serviço**: o nome do serviço que você usará. O valor sugerido é `amazonemrtrino`. Anote esse nome de serviço, pois ele será necessário ao criar uma configuração de segurança do Amazon EMR.
**Nome de exibição**: o nome a ser exibido para a instância. O valor sugerido é `amazonemrtrino`.
![\[Nome de exibição do Ranger Admin.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-display-name-trino.png)
**jdbc. driver. ClassName**: O nome da classe JDBC para conectividade Trino. Você pode usar o valor padrão.
**jdbc.url**: a string de conexão JDBC a ser usada ao se conectar ao coordenador Trino.
**Nome comum para certificado:** o campo CN dentro do certificado usado para se conectar ao servidor de administração com base em um plug-in cliente. Esse valor deve corresponder ao campo CN do certificado TLS que foi criado para o plug-in.
![\[Nome comum do Ranger Admin.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-common-name-trino.png)
Observe que o certificado TLS para o plug-in deveria ter sido registrado no armazenamento confiável do servidor Ranger Admin. Para obter mais informações, consulte [TLS certificates](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-admin-tls.html).
## Criar políticas do Trino
Ao criar uma nova política, preencha os campos a seguir.
**Nome da política**: o nome da política.
**Rótulo de política**: um rótulo que você pode colocar na política.
**Catálogo**: o catálogo ao qual a política se aplica. O curinga “\$1” representa todos os catálogos.
**Esquema**: os esquemas aos quais a política se aplica. O curinga “\$1” representa todos os esquemas.
**Tabela**: as tabelas às quais a política se aplica. O caractere curinga “\$1” representa todas as tabelas.
**Coluna**: as colunas às quais a política se aplica. O caractere curinga “\$1” representa todas as colunas.
**Descrição**: uma descrição da política.
Há outros tipos de políticas para o **usuário Trino** (para acesso à representação do usuário), a **propriedade do sistema/sessão Trino** (para alterar o sistema do mecanismo ou as propriedades da sessão), **funções/procedimentos** (para permitir chamadas de função ou procedimento) e o **URL** (para conceder acesso de leitura/gravação ao mecanismo em locais de dados).
![\[O Ranger Admin cria detalhes da política.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-details-trino.png)
Para conceder permissões a usuários e grupos específicos, insira os usuários e grupos. Também é possível especificar exclusões para condições de **permissão** e **negação**.
![\[Os detalhes da política do Ranger Admin permitem condições de negação.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions-trino.png)
Após especificar as condições de permitir e negar, escolha **Salvar**.
## Considerações
Ao criar políticas do Trino no Apache Ranger, atente para algumas considerações sobre o uso.
**Servidor de metadados Hive**
O servidor de metadados Hive só pode ser acessado por mecanismos confiáveis, especificamente o mecanismo Trino, para proteção contra acesso não autorizado. O servidor de metadados Hive também é acessado por todos os nós do cluster. A porta 9083 necessária fornece acesso de todos os nós ao nó principal.
**Autenticação**
Por padrão, o Trino é configurado para se autenticar usando Kerberos conforme definido na configuração de segurança do Amazon EMR.
**A criptografia em trânsito é obrigatória**
O plug-in Trino exige que a criptografia em trânsito esteja habilitada na configuração de segurança do Amazon EMR. Para ativar a criptografia, consulte [Criptografia em trânsito](emr-data-encryption-options.md#emr-encryption-intransit).
## Limitações
Estas são as limitações atuais do plug-in Trino:
+ O servidor Ranger Admin não oferece suporte ao preenchimento automático.
# Solução de problemas do Apache Ranger
Aqui estão alguns problemas diagnosticados com frequência relacionados ao uso do Apache Ranger.
## Recomendações
+ **Teste usando um único cluster de nó principal:** clusters principais de nó único são provisionados mais rapidamente do que um cluster de múltiplos nós, o que pode diminuir o tempo de cada iteração de teste.
+ **Defina o modo de desenvolvimento no cluster.** Ao iniciar o cluster do EMR, defina o parâmetro `--additional-info"` como:
`'{"clusterType":"development"}'`
Esse parâmetro só pode ser definido por meio da AWS CLI ou do AWS SDK e não está disponível no console do Amazon EMR. Quando esse sinalizador é definido e o principal falha no provisionamento, o serviço Amazon EMR mantém o cluster ativo por algum tempo antes de desativá-lo. Esse momento é muito útil para testar vários arquivos de log antes que o cluster seja terminado.
# Falha no provisionamento do cluster do EMR
Há vários motivos para um cluster do Amazon EMR poder falhar ao iniciar. Veja aqui algumas maneiras de diagnosticar o problema.
**Verificar os logs de provisionamento do EMR**
O Amazon EMR usa o Puppet para instalar e configurar aplicações em um cluster. A análise dos logs fornecerá detalhes sobre a ocorrência de erros durante a fase de provisionamento de um cluster. Os logs podem ser acessados no cluster ou no S3 se os logs estiverem configurados para serem enviados ao S3.
Os logs são armazenados em `/var/log/provision-node/apps-phase/0/{UUID}/puppet.log` no disco e em `s3:////node//provision-node/apps-phase/0/{UUID}/puppet.log.gz.`
**Mensagens de erro comuns**
| Mensagem de erro | Causa |
| --- | --- |
| Puppet (err): Falha na inicialização do Systemd\$1 emr-record-server registro journalctl para: emr-record-server | Falha ao iniciar o EMR Record Server. Veja abaixo os logs do EMR Record Server. |
| Puppet (err): Falha na inicialização do Systemd\$1 emr-record-server registro journalctl para emrsecretagent: | O agente secreto do EMR falhou ao iniciar. Veja abaixo os logs do agente secreto. |
| /Stage [main] /Ranger\$1Plugins: :Ranger\$1hive\$1 (aviso): 140408606197664:Error:0906d06c:PEM Rotines:PEM\$1read\$1bio:No start-line: PEM\$1lib.c:707:ESPERANDO: plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Hive plugin]/Exec[create keystore and truststore for Ranger Hive plugin]/returns QUALQUER CHAVE PRIVADA | O certificado TLS privado do Secret Manager para o certificado do plug-in Apache Ranger não está no formato correto ou não é um certificado privado. Consulte [Certificados TLS para integração do Apache Ranger com o Amazon EMR](emr-ranger-admin-tls.md) para ver os formatos de certificado. |
| /Stage [main] /Ranger\$1Plugins: :Ranger\$1S3\$1 plugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Ranger s3 plugin]/Exec[create keystore and truststore for Ranger amazon-emr-s3 plugin]/returns (notice): An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::XXXXXXXXXXX:assumed-role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXXX não está autorizado a executar: secretsmanager: no recurso: arn:aws:secretsmanager:us-east-1:xxxxxxxxxx:secret: -XXXXX GetSecretValue AdminServer | O perfil do perfil de instância do EC2 não tem as permissões corretas para recuperar os certificados TLS do Secrets Agent. |
**Verifique SecretAgent os registros**
Os logs do Secret Agent estão localizados em `/emr/secretagent/log/` em um nó do EMR ou no diretório `s3:////node//daemons/secretagent/` do S3.
**Mensagens de erro comuns**
| Mensagem de erro | Causa |
| --- | --- |
| Exceção no tópico “main” com.amazonaws.services.securitytoken.model. AWSSecurityTokenServiceException: Usuário: arn:aws:sts: :xxxxxxxxxxxx:assumido- role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXXXXXXXX não está autorizado a executar: sts: AssumeRole no recurso: arn:aws:iam: :XXXXXXXXXXXX:role/\$1 (Serviço:; Código de status: 403; Código de erro:; ID da solicitação: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX; Proxy: null RangerPluginDataAccessRole) AWSSecurity TokenService AccessDenied | A exceção acima significa que a função de perfil da instância EC2 do EMR não tem permissões para assumir a função. **RangerPluginDataAccessRole** Consulte [Perfis do IAM para integração nativa com o Apache Ranger](emr-ranger-iam.md). |
| ERROR qtp54617902-149: Web App Exception Occurred javax.ws.rs. NotAllowedException: Método HTTP 405 não permitido | Esses erros podem ser ignorados com segurança. |
**Verificar logs do Record Server (para SparkSQL)**
Os registros do EMR Record Server estão disponíveis em/var/log/emr-record-server/ em um nó do EMR ou podem ser encontrados no diretório s3:////node/ /daemons//no S3. emr-record-server
**Mensagens de erro comuns**
| Mensagem de erro | Causa |
| --- | --- |
| InstanceMetadataServiceResourceFetcher:105 - [] Falha ao recuperar o token com.amazonaws. SdkClientException: Falha na conexão com o endpoint de serviço | O EMR SecretAgent não apareceu ou está com problemas. Inspecione os SecretAgent registros em busca de erros e o script de marionete para determinar se houve algum erro de provisionamento. |
# As consultas falham inesperadamente na integração do Ranger com o Amazon EMR
**Verifique os registros do plug-in Apache Ranger (registros do Apache Hive, RecordServer EMR, EMR, SecretAgent etc.)**
Essa seção é comum em todos os aplicativos que se integram ao plug-in Ranger, como Apache Hive, EMR Record Server e EMR. SecretAgent
**Mensagens de erro comuns**
| Mensagem de erro | Causa |
| --- | --- |
| ERROR:272 PolicyRefresher - [] (PolicyRefresherserviceName=policy-repository): falha ao encontrar o serviço. Limpará o cache local de políticas (-1) | Essas mensagens de erro significam que o nome do serviço que você forneceu na configuração de segurança do EMR não corresponde a um repositório de políticas de serviço no servidor Ranger Admin. |
Se, no servidor Ranger Admin, seu AMAZON-EMR-SPARK serviço se parecer com o seguinte, você deverá inserir **amazonemrspark** o nome do serviço.
![\[Servidor Ranger Admin mostrando AMAZON-EMR-SPARK solução de problemas.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark-troubleshooting.png)
# Controle do tráfego de rede com grupos de segurança para o cluster do Amazon EMR
Grupos de segurança atuam como firewalls virtuais para suas instâncias do EC2 em seu cluster para controlar o tráfego de entrada e saída. Cada grupo de segurança tem um conjunto de regras que controla o tráfego de entrada para as instâncias e um conjunto de regras separado para controlar o tráfego de saída. Para obter mais informações, consulte [Grupos de segurança do Amazon EC2 para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) no *Guia do usuário do Amazon EC2*.
Você usa duas classes de grupos de segurança com o Amazon EMR: *grupos de segurança gerenciados pelo Amazon EMR* e *grupos de segurança adicionais*.
Cada cluster tem grupos de segurança gerenciados associados a ele. Você pode usar grupos de segurança gerenciados padrão que o Amazon EMR cria ou especificar grupos de segurança gerenciados personalizados. De qualquer forma, o Amazon EMR adiciona automaticamente regras aos grupos de segurança gerenciados que um cluster precisa para se comunicar entre instâncias e AWS serviços do cluster.
Grupos de segurança adicionais são opcionais. Você pode especificá-los além dos grupos de segurança gerenciados para personalizar o acesso às instâncias do cluster. Os grupos de segurança adicionais contêm apenas regras definidas por você. O Amazon EMR não os modifica.
As regras que o Amazon EMR cria em grupos de segurança gerenciados permitem que o cluster se comunique entre componentes internos. Para permitir que usuários e aplicativos acessem um cluster de fora do cluster, você pode editar regras em grupos de segurança gerenciados, criar grupos de segurança adicionais com regras adicionais ou ambos.
**Importante**
A edição de regras em grupos de segurança gerenciados pode ter consequências inesperadas. Você pode bloquear acidentalmente o tráfego necessário para os clusters funcionarem corretamente e causar erros porque os nós estão inacessíveis. Tenha cuidado ao planejar e testar configurações de grupo de segurança antes da implementação.
Você pode especificar grupos de segurança somente ao criar um cluster. Eles não podem ser adicionados a um cluster ou instâncias do cluster enquanto um cluster está em execução, mas é possível editar, adicionar e remover regras de grupos de segurança existentes. As regras entram em vigor assim que você as salva.
Grupos de segurança são restritivos por padrão. A menos que seja adicionada uma regra que permita o tráfego, ele é rejeitado. Se houver mais de uma regra que se aplique ao mesmo tráfego e à mesma origem, a regra mais permissiva será aplicada. Por exemplo, se você tiver uma regra que permita SSH do endereço IP 192.0.2.12/32 e outra regra que permita acesso a todo o tráfego TCP do mesmo intervalo 192.0.2.0/24, a regra que permitir todo o tráfego TCP do intervalo que inclua 192.0.2.12 terá precedência. Nesse caso, o cliente em 192.0.2.12 pode ter mais acesso do que o desejado.
**Importante**
Tome cuidado ao editar as regras de grupo de segurança para portas abertas. Adicione regras que só permitam tráfego de clientes confiáveis e autenticados para os protocolos e portas que sejam necessários para executar suas workloads.
Você poderá configurar o *bloqueio de acesso público* do Amazon EMR em cada região usada para impedir a criação de cluster se uma regra permitir acesso público em qualquer porta que você não adicionar a uma lista de exceções. Para AWS contas criadas após julho de 2019, o bloqueio de acesso público do Amazon EMR está ativado por padrão. Para AWS contas que criaram um cluster antes de julho de 2019, o bloqueio de acesso público do Amazon EMR está desativado por padrão. Para obter mais informações, consulte [Usar o bloqueio de acesso público do Amazon EMR](emr-block-public-access.md).
**Topics**
+ [Trabalhar com grupos de segurança gerenciados pelo Amazon EMR](emr-man-sec-groups.md)
+ [Trabalho com grupos de segurança adicionais em um cluster do Amazon EMR](emr-additional-sec-groups.md)
+ [Especificar grupos de segurança gerenciados pelo Amazon EMR e adicionais](emr-sg-specify.md)
+ [Especificar grupos de segurança do EC2 para Cadernos do EMR](emr-managed-notebooks-security-groups.md)
+ [Usar o bloqueio de acesso público do Amazon EMR](emr-block-public-access.md)
**nota**
O Amazon EMR procura usar alternativas inclusivas para termos setoriais potencialmente ofensivos ou não inclusivos, como “mestre” e “escravo”. Fizemos a transição para uma nova terminologia para promover uma experiência mais inclusiva e facilitar a compreensão dos componentes do serviço.
Agora descrevemos “nós” como **instâncias** e descrevemos os tipos de instância do Amazon EMR como instâncias **primárias**, **centrais** e de **tarefas**. Durante a transição, ainda é possível encontrar referências antigas a termos desatualizados, como aqueles que dizem respeito aos grupos de segurança do Amazon EMR.
# Trabalhar com grupos de segurança gerenciados pelo Amazon EMR
**nota**
O Amazon EMR procura usar alternativas inclusivas para termos setoriais potencialmente ofensivos ou não inclusivos, como “mestre” e “escravo”. Fizemos a transição para uma nova terminologia para promover uma experiência mais inclusiva e facilitar a compreensão dos componentes do serviço.
Agora descrevemos “nós” como **instâncias** e descrevemos os tipos de instância do Amazon EMR como instâncias **primárias**, **centrais** e de **tarefas**. Durante a transição, ainda é possível encontrar referências antigas a termos desatualizados, como aqueles que dizem respeito aos grupos de segurança do Amazon EMR.
Diferentes grupos de segurança gerenciados estão associados à instância primária e às instâncias centrais e de tarefa em um cluster. Um grupo de segurança gerenciado adicional para acesso de serviço é necessário quando você cria um cluster em uma sub-rede privada. Para obter mais informações sobre a função de grupos de segurança gerenciados com respeito à configuração de sua rede, consulte [Opções da Amazon VPC ao iniciar um cluster](emr-clusters-in-a-vpc.md).
Ao especificar grupos de segurança gerenciados para um cluster, você deve usar o mesmo tipo de grupo de segurança, padrão ou personalizado, para todos os grupos de segurança gerenciados. Por exemplo, você não pode especificar um grupo de segurança personalizado para a instância primária e, em seguida, não especificar um grupo de segurança personalizado para instâncias centrais e de tarefa.
Se você usar grupos de segurança gerenciados padrão, não será necessário especificá-los ao criar um cluster. O Amazon EMR usa os padrões automaticamente. Além disso, se os padrões ainda não existirem na VPC do cluster, o Amazon EMR os criará. O Amazon EMR também os criará se você os especificar explicitamente e eles ainda não existirem.
É possível editar regras em grupos de segurança gerenciados depois que os clusters forem criados. Quando você criar um novo cluster, o Amazon EMR verificará as regras nos grupos de segurança gerenciados que você especificar e criará as regras *de entrada* ausentes necessárias para o novo cluster, além de regras que podem ter sido adicionadas anteriormente. A menos que esteja definido de forma diferente, cada regra para grupos de segurança padrão gerenciados pelo Amazon EMR também é aplicada aos grupos de segurança personalizados gerenciados pelo Amazon EMR que você especificar.
Os grupos de segurança gerenciados padrão são os seguintes:
+ **ElasticMapReduce-primário**
Para regras nesse grupo de segurança, consulte [Grupo de segurança gerenciado pelo Amazon EMR para a instância primária (sub-redes públicas)](#emr-sg-elasticmapreduce-master).
+ **ElasticMapReduce-núcleo**
Para regras nesse grupo de segurança, consulte [Grupo de segurança gerenciado pelo Amazon EMR para instâncias centrais e de tarefa (sub-redes públicas)](#emr-sg-elasticmapreduce-slave).
+ **ElasticMapReduce- Primário - Privado**
Para regras nesse grupo de segurança, consulte [Grupo de segurança gerenciado pelo Amazon EMR para a instância primária (sub-redes privadas)](#emr-sg-elasticmapreduce-master-private).
+ **ElasticMapReduce-Núcleo-Privado**
Para regras nesse grupo de segurança, consulte [Grupo de segurança gerenciado pelo Amazon EMR para instâncias centrais e de tarefa (sub-redes privadas)](#emr-sg-elasticmapreduce-slave-private).
+ **ElasticMapReduce-ServiceAccess**
Para regras nesse grupo de segurança, consulte [Grupo de segurança gerenciado pelo Amazon EMR para acesso de serviço (sub-redes privadas)](#emr-sg-elasticmapreduce-sa-private).
## Grupo de segurança gerenciado pelo Amazon EMR para a instância primária (sub-redes públicas)
**O grupo de segurança gerenciado padrão para a instância primária em sub-redes públicas tem o **nome do grupo** de ElasticMapReduce -primary.** Tem as regras a seguir. Se você especificar um grupo de segurança gerenciado personalizado, o Amazon EMR adicionará todas as mesmas regras ao grupo de segurança personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-man-sec-groups.html)
**Para conceder o acesso SSH a fontes confiáveis ao grupo de segurança primário com o console**
Para editar seus grupos de segurança, você deve ter permissão para gerenciar os grupos de segurança para a VPC na qual o cluster está localizado. Para obter mais informações, consulte [Alteração de permissões de um usuário](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html) e o [exemplo de política](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) que permite o gerenciamento de grupos de segurança do EC2 no *Guia do usuário do IAM*.
1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Escolha **Clusters**. Escolha o **ID** do cluster que deseja modificar.
1. No painel **Rede e segurança**, expanda o menu suspenso **Grupos de segurança (firewall) do EC2**.
1. Em **Nó primário**, escolha seu grupo de segurança.
1. Escolha **Editar regras de entrada**.
1. Verifique se há uma regra de entrada que permita acesso público com as configurações a seguir. Se existir, escolha **Excluir** para removê-la.
+ **Tipo**
SSH
+ **Porta**
22
+ **Origem**
Personalizado 0.0.0.0/0
**Atenção**
Antes de dezembro de 2020, havia uma regra configurada previamente para permitir o tráfego de entrada na porta 22 de todas as origens. Esta regra foi criada para simplificar as conexões SSH iniciais com o nó primário. Recomendamos fortemente remover esta regra de entrada e restringir o tráfego para origens confiáveis.
1. Role até o final da lista de regras e escolha **Adicionar regra**.
1. Em **Type (Tipo)**, selecione **SSH**.
Selecionar SSH insere automaticamente **TCP** para **Protocolo** e **22** para **Intervalo de portas**.
1. Para a origem, selecione **Meu IP** para adicionar automaticamente seu endereço IP como o endereço de origem. Você também pode adicionar um intervalo **personalizado** de endereços IP de clientes confiáveis ou criar regras adicionais para outros clientes. Diversos ambientes de rede alocam endereços IP dinamicamente, portanto, pode ser necessário atualizar os endereços IP para clientes confiáveis no futuro.
1. Escolha **Salvar**.
1. Opcionalmente, escolha o outro grupo de segurança em **Nós centrais e de tarefa** no painel **Rede e segurança** e repita as etapas acima para permitir o acesso do cliente SSH aos nós centrais e de tarefa.
## Grupo de segurança gerenciado pelo Amazon EMR para instâncias centrais e de tarefa (sub-redes públicas)
**O grupo de segurança gerenciado padrão para instâncias principais e de tarefas em sub-redes públicas tem o **nome do ElasticMapReduce grupo** -core.** O grupo de segurança gerenciado padrão tem as regras a seguir, e o Amazon EMR adicionará as mesmas regras se você especificar um grupo de segurança gerenciado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Grupo de segurança gerenciado pelo Amazon EMR para a instância primária (sub-redes privadas)
**O grupo de segurança gerenciado padrão para a instância primária em sub-redes privadas tem o **nome do grupo** de ElasticMapReduce -Primary-Private.** O grupo de segurança gerenciado padrão tem as regras a seguir, e o Amazon EMR adicionará as mesmas regras se você especificar um grupo de segurança gerenciado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Grupo de segurança gerenciado pelo Amazon EMR para instâncias centrais e de tarefa (sub-redes privadas)
**O grupo de segurança gerenciado padrão para instâncias principais e de tarefas em sub-redes privadas tem o **nome do grupo** de ElasticMapReduce -Core-Private.** O grupo de segurança gerenciado padrão tem as regras a seguir, e o Amazon EMR adicionará as mesmas regras se você especificar um grupo de segurança gerenciado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-man-sec-groups.html)
### Editar regras de saída
Por padrão, o Amazon EMR cria o grupo de segurança com regras de saída que permitem todo o tráfego de saída em todos os protocolos e portas. A opção de permitir todo o tráfego de saída é selecionada porque várias aplicações do Amazon EMR e do cliente que podem ser executadas em clusters do Amazon EMR podem exigir regras de saída diferentes. O Amazon EMR não consegue prever essas configurações específicas ao criar grupos de segurança padrão. Você pode reduzir o escopo da saída em seus grupos de segurança para incluir somente as regras adequadas a seus casos de uso e políticas de segurança. No mínimo, esse grupo de segurança exige as regras de saída a seguir, mas algumas aplicações podem precisar de saída adicional.
| Tipo | Protocolo | Intervalo de portas | Destino | Detalhes |
| --- | --- | --- | --- | --- |
| Todos os TCP | TCP | Todos | pl- xxxxxxxx | Lista gerenciada de prefixos do Amazon S3 com.amazonaws.MyRegion.s3. |
| Todo o tráfego | Tudo | Todos | sg- xxxxxxxxxxxxxxxxx | O ID do grupo de segurança ElasticMapReduce-Core-Private. |
| Todo o tráfego | Tudo | Todos | sg- xxxxxxxxxxxxxxxxx | O ID do grupo de segurança ElasticMapReduce-Primary-Private. |
| TCP personalizado | TCP | 9443 | sg- xxxxxxxxxxxxxxxxx | O ID do grupo de segurança ElasticMapReduce-ServiceAccess. |
## Grupo de segurança gerenciado pelo Amazon EMR para acesso de serviço (sub-redes privadas)
**O grupo de segurança gerenciado padrão para acesso ao serviço em sub-redes privadas tem o **nome do grupo** de ElasticMapReduce -. ServiceAccess** Ele tem regras de entrada e regras de saída que permitem o tráfego por HTTPS (porta 8443, porta 9443) para os outros grupos de segurança gerenciados em sub-redes privadas. Essas regras permitem que o gerenciador de clusters se comunique com o nó primário e com os nós centrais e de tarefa. As mesmas regras serão necessárias se você estiver usando grupos de segurança personalizados.
| Tipo | Protocolo | Intervalo de portas | Fonte | Detalhes |
| --- | --- | --- | --- | --- |
| Regras de entrada: necessárias para clusters do Amazon EMR com o Amazon EMR versão 5.30.0 e posteriores. |
| TCP personalizado | TCP | 9443 | O ID do grupo de segurança gerenciado para a instância primária. | Essa regra permite a comunicação entre o grupo de segurança da instância principal e o grupo de segurança de acesso ao serviço. |
| Regras de saída necessárias para todos os clusters do Amazon EMR |
| TCP personalizado | TCP | 8443 | O ID do grupo de segurança gerenciado para a instância primária. | Essas regras permitem que o gerenciador de clusters se comunique com o nó primário e com os nós centrais e de tarefa. |
| TCP personalizado | TCP | 8443 | O ID do grupo de segurança gerenciado para instâncias core e de tarefa. | Essas regras permitem que o gerenciador de clusters se comunique com o nó primário e com os nós centrais e de tarefa. |
# Trabalho com grupos de segurança adicionais em um cluster do Amazon EMR
Independentemente de você usar os grupos de segurança gerenciados padrão ou especificar grupos de segurança gerenciados personalizados, é possível usar grupos de segurança adicionais. Os grupos de segurança adicionais oferecem a você a flexibilidade para adaptar o acesso entre diferentes clusters e de clientes externos, recursos e aplicativos.
Considere os seguintes cenários como um exemplo. Você tem vários clusters que devem se comunicar uns com os outros, mas deseja permitir acesso SSH de entrada à instância primária apenas para um subconjunto específico de clusters. Para fazer isso, você pode usar o mesmo conjunto de grupos de segurança gerenciados para os clusters. Em seguida, você cria grupos de segurança adicionais que permitem acesso SSH de entrada de clientes confiáveis e especifica grupos de segurança adicionais para a instância primária a cada cluster no subconjunto.
Você pode aplicar até 15 grupos de segurança adicionais para a instância primária, 15 para instâncias centrais e de tarefa e 15 para acesso de serviço (em sub-redes privadas). Se necessário, você pode especificar o mesmo grupo de segurança adicional para instâncias primárias, instâncias centrais e de tarefa e acesso de serviço. O número máximo de grupos de segurança e regras em sua conta está sujeito a limites da conta. Para obter mais informações, consulte os [limites de grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups) no *Manual do usuário da Amazon VPC*.
# Especificar grupos de segurança gerenciados pelo Amazon EMR e adicionais
Você pode especificar grupos de segurança usando a Console de gerenciamento da AWS AWS CLI, a ou a API do Amazon EMR. Se você não especificar grupos de segurança, o Amazon EMR criará grupos de segurança padrão. A especificação de grupos de segurança adicionais é opcional. Você pode atribuir grupos de segurança adicionais para instâncias primárias, instâncias centrais e de tarefa e acesso de serviço (somente sub-redes privadas).
------
#### [ Console ]
**Para especificar grupos de segurança usando o console**
1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**.
1. Em **Redes**, selecione a seta ao lado dos **Grupos de segurança do EC2 (firewall)** para expandir a seção. Em **Nó primário** e **Nós centrais e de tarefa**, os grupos de segurança gerenciados padrão do Amazon EMR são selecionados por padrão. Se você usa uma sub-rede privada, também tem a opção de selecionar um grupo de segurança em **Acesso ao serviço**.
1. Para alterar o grupo de segurança gerenciado do Amazon EMR, use o menu suspenso **Escolher grupos de segurança** para selecionar outra opção da lista de opções **Grupo de segurança gerenciado pelo Amazon EMR**. Você tem um grupo de segurança gerenciado do Amazon EMR para o **nó primário** e os **nós centrais e de tarefa**.
1. Para adicionar grupos de segurança personalizados, use o mesmo menu suspenso **Escolher grupos de segurança** para selecionar até quatro grupos de segurança personalizados na lista de opções **Grupo de segurança personalizado**. Você pode ter até quatro grupos de segurança personalizados para o **nó primário** e os **nós centrais e de tarefa**.
1. Escolha qualquer outra opção que se aplique ao cluster.
1. Para iniciar o cluster, escolha **Criar cluster**.
------
## Especificando grupos de segurança com o AWS CLI
Para especificar grupos de segurança usando o, AWS CLI você usa o `create-cluster` comando com os seguintes parâmetros da `--ec2-attributes` opção:
| Parâmetro | Description |
| --- | --- |
| `EmrManagedPrimarySecurityGroup` | Use esse parâmetro para especificar um grupo de segurança gerenciado personalizado para a instância primária. Se esse parâmetro for especificado, `EmrManagedCoreSecurityGroup` também deve ser especificado. Para clusters em sub-redes privadas, `ServiceAccessSecurityGroup` também deverá ser especificado. |
| `EmrManagedCoreSecurityGroup` | Use esse parâmetro para especificar um grupo de segurança gerenciado personalizado para instâncias core e de tarefa. Se esse parâmetro for especificado, `EmrManagedPrimarySecurityGroup` também deve ser especificado. Para clusters em sub-redes privadas, `ServiceAccessSecurityGroup` também deverá ser especificado. |
| `ServiceAccessSecurityGroup` | Use esse parâmetro para especificar um grupo de segurança gerenciado personalizado para acesso de serviço, o que se aplica apenas a clusters em sub-redes privadas. O grupo de segurança que você especificar como `ServiceAccessSecurityGroup` não deve ser usado para nenhuma outra finalidade e também deve ser reservado ao Amazon EMR. Se esse parâmetro for especificado, `EmrManagedPrimarySecurityGroup` também deve ser especificado. |
| `AdditionalPrimarySecurityGroups` | Use esse parâmetro para especificar até quatro grupos de segurança adicionais para a instância primária. |
| `AdditionalCoreSecurityGroups` | Use esse parâmetro para especificar até quatro grupos de segurança adicionais para instâncias core e de tarefa. |
**Example : especifique grupos de segurança gerenciados pelo Amazon EMR e grupos de segurança adicionais**
O exemplo a seguir especifica grupos de segurança gerenciados pelo Amazon EMR para um cluster em uma sub-rede privada, vários grupos de segurança adicionais para a instância primária e um único grupo de segurança adicional de instâncias centrais e de tarefa.
Os caracteres de continuação de linha do Linux (\$1) são incluídos para facilitar a leitura. Eles podem ser removidos ou usados em comandos do Linux. No Windows, remova-os ou substitua-os por um sinal de interpolação (^).
```
1. aws emr create-cluster --name "ClusterCustomManagedAndAdditionalSGs" \
2. --release-label emr-emr-7.12.0 --applications Name=Hue Name=Hive \
3. Name=Pig --use-default-roles --ec2-attributes \
4. SubnetIds=subnet-xxxxxxxxxxxx,KeyName=myKey,\
5. ServiceAccessSecurityGroup=sg-xxxxxxxxxxxx,\
6. EmrManagedPrimarySecurityGroup=sg-xxxxxxxxxxxx,\
7. EmrManagedCoreSecurityGroup=sg-xxxxxxxxxxx,\
8. AdditionalPrimarySecurityGroups=['sg-xxxxxxxxxxx',\
9. 'sg-xxxxxxxxxxx','sg-xxxxxxxxxx'],\
10. AdditionalCoreSecurityGroups=sg-xxxxxxxxxxx \
11. --instance-type m5.xlarge
```
Para obter mais informações, consulte [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html) na *AWS CLI Command Reference*.
# Especificar grupos de segurança do EC2 para Cadernos do EMR
Quando você cria um Caderno do EMR, dois grupos de segurança são usados para controlar o tráfego de rede entre o Caderno do EMR e o cluster do Amazon EMR quando o editor de caderno é usado. Os grupos de segurança padrão têm o mínimo de regras que permitem somente o tráfego de rede entre o serviço de Cadernos do EMR e os clusters aos quais os cadernos estão anexados.
Um Caderno do EMR usa o [Apache Livy](https://livy.incubator.apache.org/) para se comunicar com o cluster por meio de um proxy pela porta TCP 18888. Ao criar grupos de segurança personalizados com regras personalizadas para seu ambiente, você pode limitar o tráfego de rede para que apenas um subconjunto de cadernos possa executar código no editor de cadernos em determinados clusters. O cluster usa segurança personalizada, além dos grupos de segurança padrão do cluster. Para obter mais informações, consulte [Control network traffic with security groups](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html) no *Guia de gerenciamento do Amazon EMR* e no [Especificar grupos de segurança do EC2 para Cadernos do EMR](#emr-managed-notebooks-security-groups).
## Grupo de segurança padrão do EC2 para a instância primária
O grupo de segurança padrão do EC2 para a instância primária está associado à instância primária do cluster, além dos grupos de segurança para a instância primária.
Nome do grupo: **ElasticMapReduceEditors-Livy**
**Regras**
+ Entrada
Permitir a porta TCP 18888 de todos os recursos no grupo de segurança padrão do EC2 para Cadernos do EMR
+ Saída
Nenhum
## Grupo de segurança padrão do EC2 para Cadernos do EMR
O grupo de segurança padrão do EC2 para o Caderno do EMR está associado ao editor de cadernos para qualquer Caderno do EMR ao qual ele esteja atribuído.
Nome do grupo: **ElasticMapReduceEditors-Editor**
**Regras**
+ Entrada
Nenhum
+ Saída
Permitir a porta TCP 18888 a todos os recursos no grupo de segurança padrão do EC2 para Cadernos do EMR.
## Grupo de segurança personalizado do EC2 para o Cadernos do EMR ao associar cadernos a repositórios do Git
Para vincular um repositório do Git ao caderno, o grupo de segurança do Caderno do EMR deve incluir uma regra de saída para permitir que o caderno encaminhe o tráfego para a Internet. É recomendável criar um grupo de segurança para essa finalidade. A atualização do grupo de segurança padrão **ElasticMapReduceEditors-Editor** pode fornecer as mesmas regras de saída para outros notebooks anexados a esse grupo de segurança.
**Regras**
+ Entrada
Nenhum
+ Saída
Permita que o caderno encaminhe o tráfego para a Internet por meio do cluster, como demonstra o exemplo a seguir. Utiliza-se o valor 0.0.0.0/0 para fins de exemplo. É possível modificar essa regra para especificar os endereços IP dos repositórios baseados em Git.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-managed-notebooks-security-groups.html)
# Usar o bloqueio de acesso público do Amazon EMR
O *bloqueio de acesso público (BPA)* do Amazon EMR impede que você inicie um cluster em uma sub-rede pública se o cluster tiver uma configuração de segurança que permita tráfego de entrada de endereços IP públicos em uma porta.
**Importante**
O *bloqueio de acesso público* é habilitado por padrão. Para aumentar a proteção da conta, é recomendável mantê-la habilitada.
## Noções básicas do bloqueio ao acesso público
É possível usar a configuração em nível de conta de *bloqueio de acesso público* para gerenciar o acesso à rede pública aos clusters do Amazon EMR de maneira centralizada.
Quando um usuário do seu Conta da AWS executa um cluster, o Amazon EMR verifica as regras de porta no grupo de segurança do cluster e as compara com suas regras de tráfego de entrada. Se o grupo de segurança tiver uma regra de entrada que abre portas para os endereços IP públicos IPv4 0.0.0.0/0 ou IPv6 : :/0, e essas portas não forem especificadas como exceções para sua conta, o Amazon EMR não permitirá que o usuário crie o cluster.
Se um usuário modificar as regras do grupo de segurança de um cluster em execução em uma sub-rede pública para ter uma regra de acesso público que viole a configuração do BPA da conta, o Amazon EMR revogará a nova regra se tiver permissão para isso. Se o Amazon EMR não tiver permissão para revogar a regra, ele criará um evento no painel AWS Health que descreva a violação. Para conceder a permissão de revogação da regra ao Amazon EMR, consulte [Configurar o Amazon EMR para revogar regras do grupo de segurança](#revoke-block-public-access).
O bloqueio de acesso público é habilitado por padrão para todos os clusters em cada Região da AWS de sua Conta da AWS. O BPA se aplica a todo o ciclo de vida de um cluster, mas não se aplica aos clusters criados em sub-redes privadas. É possível configurar exceções à regra do BPA; a porta 22 é uma exceção por padrão. Para obter mais informações sobre como configurar exceções, consulte [Configurar o bloqueio de acesso público](#configure-block-public-access).
## Configurar o bloqueio de acesso público
Você pode atualizar os grupos de segurança e a configuração de bloqueio de acesso público de suas contas a qualquer momento.
Você pode ativar e desativar as configurações de bloqueio de acesso público (BPA) com a API Console de gerenciamento da AWS, a AWS Command Line Interface (AWS CLI) e a API do Amazon EMR. As configurações se aplicam em toda a sua conta em uma Region-by-Region base. Para manter a segurança do cluster, é recomendável usar o BPA.
------
#### [ Console ]
**Para configurar o bloqueio de acesso público usando o console**
1. [Faça login no e, em seguida Console de gerenciamento da AWS, abra o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Na barra de navegação superior, selecione a **região** que você deseja configurar, se ainda não estiver selecionada.
1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Bloqueio de acesso público**.
1. Em **Block public access settings (Configurações de bloqueio de acesso público)**, conclua as etapas a seguir.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-block-public-access.html)
------
#### [ AWS CLI ]
**Para configurar, bloquear o acesso público usando o AWS CLI**
+ Use o comando `aws emr put-block-public-access-configuration` para configurar o bloqueio de acesso público, conforme mostrado nos exemplos a seguir.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-block-public-access.html)
------
## Configurar o Amazon EMR para revogar regras do grupo de segurança
O Amazon EMR precisa de permissão para revogar regras do grupo de segurança e cumprir sua configuração de bloqueio de acesso público. Você pode usar uma destas abordagens para dar a permissão necessária ao Amazon EMR:
+ **(Recomendado)** Anexe a política gerenciada `AmazonEMRServicePolicy_v2` ao perfil de serviço. Para obter mais informações, consulte [Perfil de serviço para Amazon EMR (perfil do EMR)](emr-iam-role.md).
+ Crie uma nova política em linha que permita a ação `ec2:RevokeSecurityGroupIngress` em grupos de segurança. Para obter mais informações sobre como modificar uma política de permissões de perfil, consulte **Modificar uma política de permissões de perfil** com o [console do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy), a [API da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-api.html#roles-modify_permissions-policy-api) e a [AWS CLI](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-cli.html#roles-modify_permissions-policy-cli) no *Guia do usuário do IAM*.
## Resolver violações ao bloqueio de acesso público
Se ocorrer uma violação ao bloqueio de acesso público, você poderá mitigá-la com uma destas ações:
+ Se quiser acessar uma interface da Web no cluster, use uma das opções descritas em [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md) para acessar a interface por meio de SSH (porta 22).
+ Para permitir o tráfego no cluster com base em endereços IP específicos em vez do endereço IP público, adicione uma regra de grupo de segurança. Para obter mais informações, consulte [Adicionar regras a um grupo de segurança](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule), no *Guia de conceitos básicos do Amazon EC2*.
+ **(Não recomendado)** É possível configurar as exceções de BPA do Amazon EMR para incluir a porta ou o intervalo de portas desejado. Ao especificar uma exceção de BPA, você introduz riscos com uma porta desprotegida. Se você pretende especificar uma exceção, remova a exceção assim que ela não for mais necessária. Para obter mais informações, consulte [Configurar o bloqueio de acesso público](#configure-block-public-access).
## Identificar clusters associados às regras do grupo de segurança
Talvez seja necessário identificar todos os clusters associados a determinada regra de grupo de segurança ou encontrar a regra de grupo de segurança de determinado cluster.
+ Se você conhece o grupo de segurança, poderá identificar os clusters associados se encontrar as interfaces de rede do grupo de segurança. Para obter mais informações, consulte [How can I find the resources associated with an Amazon EC2 security group?](https://forums.aws.amazon.com/knowledge-center/ec2-find-security-group-resources) no AWS re:Post. As instâncias do Amazon EC2 que estão conectadas a essas interfaces de rede serão marcadas com o ID do cluster ao qual pertencem.
+ Se você quiser encontrar os grupos de segurança de um cluster conhecido, siga as etapas descritas em [Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md). Você pode encontrar os grupos de segurança do cluster no painel **Rede e segurança** no console ou no campo `Ec2InstanceAttributes` da AWS CLI.
# Validação de conformidade para o Amazon EMR
Auditores terceirizados avaliam a segurança e a conformidade do Amazon EMR como parte de AWS vários programas de conformidade. Isso inclui SOC, PCI, FedRAMP, HIPAA e outros.
Para obter uma lista de AWS serviços no escopo de programas de conformidade específicos, consulte [AWS serviços no escopo por programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/). Para obter informações gerais, consulte [Programas de conformidade da AWS](https://aws.amazon.com/compliance/programs/).
Você pode baixar relatórios de auditoria de terceiros usando AWS Artifact. Para obter mais informações, consulte [Baixar relatórios em AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Sua responsabilidade de conformidade ao usar o Amazon EMR é determinada pela confidencialidade dos dados, pelos objetivos de conformidade da empresa e pelos regulamentos e leis aplicáveis. Se seu uso do Amazon EMR estiver sujeito à conformidade com padrões como HIPAA, PCI ou FedRAMP, fornece recursos para ajudar a: AWS
+ [Guias de início rápido sobre segurança e conformidade](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) — Esses guias de implantação discutem considerações arquitetônicas e fornecem etapas para a implantação de ambientes básicos focados em segurança e conformidade em. AWS
+ Documento técnico [sobre arquitetura para segurança e conformidade com a HIPAA — Este whitepaper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) descreve como as empresas podem usar para criar aplicativos compatíveis com a HIPAA. AWS
+ [AWS recursos de conformidade](https://aws.amazon.com/compliance/resources/) — essa coleção de pastas de trabalho e guias pode ser aplicada ao seu setor e local.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Esse AWS serviço avalia se suas configurações de recursos estão em conformidade com as práticas internas, as diretrizes e os regulamentos do setor.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Esse AWS serviço fornece uma visão abrangente do seu estado de segurança interno, AWS que ajuda você a verificar sua conformidade com os padrões e as melhores práticas do setor de segurança.
# Resiliência no Amazon EMR
A infraestrutura AWS global é construída em torno de AWS regiões e zonas de disponibilidade. AWS As regiões fornecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta taxa de transferência e alta redundância. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre AWS regiões e zonas de disponibilidade, consulte [infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
Além da infraestrutura AWS global, o Amazon EMR oferece vários recursos para ajudar a suportar suas necessidades de resiliência e backup de dados.
+ **Integração com o Amazon S3 por meio do EMRFS**
+ **Suporte a vários nós principais**
# Segurança da infraestrutura no Amazon EMR
Como um serviço gerenciado, o Amazon EMR é protegido pela segurança de rede AWS global. Para obter informações sobre serviços AWS de segurança e como AWS proteger a infraestrutura, consulte [AWS Cloud Security](https://aws.amazon.com/security/). Para projetar seu AWS ambiente usando as melhores práticas de segurança de infraestrutura, consulte [Proteção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de infraestrutura no *Security Pillar AWS Well‐Architected* Framework.
Você usa chamadas de API AWS publicadas para acessar o Amazon EMR pela rede. Os clientes devem oferecer compatibilidade com:
+ Transport Layer Security (TLS). Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Conjuntos de criptografia com perfect forward secrecy (PFS) como DHE (Ephemeral Diffie-Hellman) ou ECDHE (Ephemeral Elliptic Curve Diffie-Hellman). A maioria dos sistemas modernos, como Java 7 e versões posteriores, comporta esses modos.
**Topics**
+ [Conectar-se ao Amazon EMR usando um endpoint da VPC de interface](interface-vpc-endpoint.md)
# Conectar-se ao Amazon EMR usando um endpoint da VPC de interface
Você pode se conectar diretamente ao Amazon EMR usando uma interface [VPC endpoint (AWS PrivateLink) na sua Virtual Private Cloud (](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html)VPC) em vez de se conectar pela Internet. Quando você usa uma interface VPC endpoint, a comunicação entre sua VPC e o Amazon EMR é conduzida inteiramente dentro da rede. AWS Cada VPC endpoint é representado por uma ou mais [interfaces de rede elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) com endereços IP privados em suas sub-redes VPC.
A interface VPC endpoint conecta sua VPC diretamente ao Amazon EMR sem um gateway de internet, dispositivo NAT, conexão VPN ou conexão. Direct Connect As instâncias em sua VPC não precisam de endereços IP públicos para se comunicarem com a API do Amazon EMR.
Para usar o Amazon EMR por meio da VPC, você deve se conectar de uma instância que esteja dentro da VPC ou conectar sua rede privada à VPC usando a rede privada virtual (VPN) da Amazon ou o Direct Connect. Para obter informações sobre o Amazon VPN, consulte [Conexões VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) no *Guia do usuário do Amazon Virtual Private Cloud*. Para obter informações sobre AWS Direct Connect, consulte [Criação de uma conexão](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-connection.html) no *Guia Direct Connect do usuário*.
Você pode criar uma interface VPC endpoint para se conectar ao Amazon EMR usando o AWS console ou os comandos (). AWS Command Line Interface AWS CLI Para obter mais informações, consulte [Creating an interface endpoint](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#create-interface-endpoint) (Criação de um endpoint de interface).
Após criar um endpoint da VPC de interface, se você habilitar nomes de host DNS privados para o endpoint, o endpoint padrão do Amazon EMR será resolvido para seu endpoint da VPC. O endpoint de nome de serviço padrão para o Amazon EMR estará no formato a seguir.
```
elasticmapreduce.Region.amazonaws.com
```
Se você não habilitar nomes de host DNS privados, a Amazon VPC fornecerá um nome de endpoint DNS que poderá ser usado no formato a seguir.
```
VPC_Endpoint_ID.elasticmapreduce.Region.vpce.amazonaws.com
```
Para obter mais informações, consulte [Endpoints da VPC da interface (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) no *Manual do Usuário do Amazon VPC*.
O Amazon EMR oferece suporte a chamadas para todas as [ações de API](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) dentro da VPC.
Você pode anexar políticas de endpoint da VPC a um endpoint da VPC para controlar o acesso de entidades principais do IAM. Também é possível associar grupos de segurança a um VPC endpoint para controlar o acesso de entrada e saída com base na origem e no destino do tráfego de rede, como um intervalo de endereços IP. Para obter mais informações, consulte [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html).
## Criar uma política de endpoint da VPC para o Amazon EMR
É possível criar uma política para endpoints da Amazon VPC para o Amazon EMR para especificar o seguinte:
+ O principal que pode ou não executar ações
+ As ações que podem ser executadas
+ Os recursos nos quais as ações podem ser executadas
Para mais informações, consulte [Controlar o acesso a serviços com VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
**Example — Política de VPC endpoint para negar todo o acesso de uma conta especificada AWS**
A política de VPC endpoint a seguir nega à AWS conta *123456789012* todo o acesso aos recursos que usam o endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example – Política de endpoint da VPC para permitir o acesso à VPC somente a uma entidade principal do IAM (usuário) especificada**
A política de VPC endpoint a seguir permite acesso total somente ao usuário *lijuan* na conta. AWS *123456789012* Todos os outros principais IAM têm acesso negado usando o endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/lijuan"
]
}
}]
}
```
**Example – Política de endpoint da VPC para permitir operações somente leitura do EMR**
A política de VPC endpoint a seguir permite que somente a AWS conta *123456789012* execute as ações especificadas do Amazon EMR.
As ações especificadas fornecem o equivalente ao acesso somente leitura para o Amazon EMR. Todas as outras ações na VPC serão negadas para a conta especificada. Todas as outras contas terão acesso negado. Para obter uma lista de ações do Amazon EMR, consulte [Ações, recursos e chaves de condição do Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": [
"elasticmapreduce:DescribeSecurityConfiguration",
"elasticmapreduce:GetBlockPublicAccessConfiguration",
"elasticmapreduce:ListBootstrapActions",
"elasticmapreduce:ViewEventsFromAllClustersInConsole",
"elasticmapreduce:ListSteps",
"elasticmapreduce:ListInstanceFleets",
"elasticmapreduce:DescribeCluster",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:DescribeStep",
"elasticmapreduce:ListInstances",
"elasticmapreduce:ListSecurityConfigurations",
"elasticmapreduce:DescribeEditor",
"elasticmapreduce:ListClusters",
"elasticmapreduce:ListEditors"
],
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example – Política de endpoint da VPC negando acesso a um cluster especificado**
A política de VPC endpoint a seguir permite acesso total a todas as contas e diretores, mas nega qualquer acesso da AWS conta *123456789012* às ações realizadas no cluster do Amazon EMR com ID do cluster. *j-A1B2CD34EF5G* Outras ações do Amazon EMR que não oferecem suporte a permissões de nível de recurso para clusters ainda são permitidas. Para obter uma lista de ações do Amazon EMR e seus tipos de recurso correspondentes, consulte [Ações, recursos e chaves de condição do Amazon EMR](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonelasticmapreduce.html).
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "arn:aws:elasticmapreduce:us-west-2:123456789012:cluster/j-A1B2CD34EF5G",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```