```
Además, debe escapar los argumentos de los comandos de Bash cuando ejecuta comandos con el ejecutor de scripts. El siguiente ejemplo muestra cómo definir propiedades de Spark e incluye los caracteres de escape necesarios:
```
"\"--conf spark.sql.autoBroadcastJoinThreshold=-1\n--conf spark.cradle.RSv2Mode.enabled=true\""
```
+ Los roles en tiempo de ejecución no permiten controlar el acceso a los recursos del clúster, como HDFS y HMS.
+ Los roles de tiempo de ejecución no incluyen compatibilidad con docker o contenedores.
# Configure las funciones de servicio de IAM para los permisos de Amazon EMR AWS a los servicios y recursos
Amazon EMR y las aplicaciones como Hadoop necesitan permisos para obtener acceso a otros recursos de AWS y realizar acciones cuando se ejecutan. Cada clúster de Amazon EMR debe tener un *rol de servicio* y un rol para el *perfil de instancia* de Amazon EC2. Para obtener más información, consulte [Roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) y [Uso de perfiles de instancia](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) en la *Guía del usuario de IAM*. Las políticas de IAM asociadas a estos roles proporcionan permisos que permiten al clúster interoperar con otros servicios de AWS en nombre de un usuario.
Es necesario otro rol adicional, el rol de escalado automático, si el clúster utiliza el escalado automático en Amazon EMR. El rol AWS de servicio de EMR Notebooks es obligatorio si utiliza EMR Notebooks.
Amazon EMR proporciona roles predeterminados y políticas administradas predeterminadas que determinan permisos los permisos de cada rol. Las políticas administradas las crea y mantiene AWS, por lo que se actualizan automáticamente si cambian los requisitos del servicio. Para obtener más información, consulte [Políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies.html) en la *Guía del usuario de IAM*.
Si está creando un clúster o un cuaderno por primera vez en una cuenta, los roles de Cuadernos de Amazon EMR aún no existen. Tras crearlas, puede ver las funciones, las políticas asociadas a ellas y los permisos permitidos o denegados por las políticas en la consola de IAM ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)). Puede especificar los roles predeterminados para Amazon EMR para crear y utilizar, puede crear sus propios roles y especificarlos de manera individual al crear un clúster para personalizar los permisos, y puede especificar roles predeterminados que se utilizarán al crear un clúster mediante la AWS CLI. Para obtener más información, consulte [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md).
## Modificación de políticas basadas en identidades para obtener permisos y así transferir roles de servicio para Amazon EMR
Las políticas administradas de forma predeterminada con todos los permisos de Amazon EMR incorporan configuraciones de seguridad `iam:PassRole`, entre las que se incluyen las siguientes:
+ Permisos `iam:PassRole` solo para roles específicos de Amazon EMR predeterminados.
+ `iam:PassedToService`condiciones que le permiten usar la política solo con AWS servicios específicos, como `elasticmapreduce.amazonaws.com` y`ec2.amazonaws.com`.
Puede ver la versión JSON de las políticas [Amazon EMRFull AccessPolicy \$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) y [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) en la consola de IAM. Le recomendamos crear nuevos clústeres con las políticas administradas de la versión 2.
## Resumen de rol de servicio
En la siguiente tabla se muestran los roles de servicio de IAM asociados con Amazon EMR para una consulta rápida.
| Función | Rol predeterminado | Description (Descripción) | Política administrada predeterminada |
| --- | --- | --- | --- |
| [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md) | `EMR_DefaultRole_V2` | Permite a Amazon EMR llamar a otros AWS servicios en su nombre al aprovisionar recursos y realizar acciones a nivel de servicio. Este rol es necesario para todos los clústeres. | `AmazonEMRServicePolicy_v2` La solicitud de instancias de spot requiere un rol vinculado a un servicio. Si este rol no existe, el rol de servicio de Amazon EMR debe tener permisos para crearlo; en caso contrario, se producirá un error de permisos. Si planea solicitar instancias de spot, debe actualizar esta política para incluir una instrucción que permita la creación de este rol vinculado a un servicio. Para obtener más información, consulte [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md) y [Rol vinculado al servicio para solicitudes de instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests) en la *Guía del usuario de Amazon EC2*. |
| [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md) | `EMR_EC2_DefaultRole` | Los procesos de aplicación que se ejecutan sobre el ecosistema de Hadoop en instancias de clúster utilizan esta función cuando llaman a otros servicios. AWS Para obtener acceso a los datos en Amazon S3 usando EMRFS, puede especificar diferentes roles que se asumirán en función de la ubicación de los datos en Amazon S3. Por ejemplo, varios equipos pueden acceder a una única “cuenta de almacenamiento” de datos de Amazon S3. Para obtener más información, consulte [Configuración de roles de IAM para solicitudes de EMRFS a Amazon S3](emr-emrfs-iam-roles.md). Este rol es necesario para todos los clústeres. | `AmazonElasticMapReduceforEC2Role`. Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md). |
| [Rol de servicio para el escalado automático en Amazon EMR (rol de Auto Scaling)](emr-iam-role-automatic-scaling.md) | `EMR_AutoScaling_DefaultRole` | Permite acciones adicionales para entornos de escalado dinámico. Solo es obligatorio para los clústeres que utilizan el escalado automático en Amazon EMR. Para obtener más información, consulte [Uso del escalado automático con una política personalizada para grupos de instancias en Amazon EMR](emr-automatic-scaling.md). | `AmazonElasticMapReduceforAutoScalingRole`. Para obtener más información, consulte [Rol de servicio para el escalado automático en Amazon EMR (rol de Auto Scaling)](emr-iam-role-automatic-scaling.md). |
| [Rol de servicio para Cuadernos de Amazon EMR](emr-managed-notebooks-service-role.md) | `EMR_Notebooks_DefaultRole` | Proporciona los permisos que un bloc de notas EMR necesita para acceder a otros AWS recursos y realizar acciones. Necesario solo si se utiliza Cuadernos de Amazon EMR. | `AmazonElasticMapReduceEditorsRole`. Para obtener más información, consulte [Rol de servicio para Cuadernos de Amazon EMR](emr-managed-notebooks-service-role.md). También se asocia `S3FullAccessPolicy` de forma predeterminada. El contenido de esta política se muestra a continuación. JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
``` |
| [Rol vinculado a servicio](using-service-linked-roles.md) | `AWSServiceRoleForEMRCleanup` | Amazon EMR crea automáticamente un rol vinculado a un servicio. Si el servicio de Amazon EMR ha perdido la capacidad de limpiar los recursos de Amazon EC2, Amazon EMR puede utilizar este rol para limpiar. Si un clúster utiliza instancias de spot, la política de permisos vinculada al [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md) debe permitir la creación de un rol vinculado al servicio. Para obtener más información, consulte [Uso de roles vinculados a servicios para Amazon EMR](using-service-linked-roles.md). | `AmazonEMRCleanupPolicy` |
**Topics**
+ [Modificación de políticas basadas en identidades para obtener permisos y así transferir roles de servicio para Amazon EMR](#emr-iam-roles-passrole)
+ [Resumen de rol de servicio](#emr-iam-roles-summary)
+ [Roles de servicio de IAM utilizados por Amazon EMR](emr-iam-service-roles.md)
+ [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md)
+ [Configuración de roles de IAM para solicitudes de EMRFS a Amazon S3](emr-emrfs-iam-roles.md)
+ [Utilice políticas basadas en recursos para el acceso de Amazon EMR al catálogo de datos de Glue AWS](emr-iam-roles-glue.md)
+ [Utilice las funciones de IAM con aplicaciones que llamen directamente a AWS los servicios](emr-iam-roles-calling.md)
+ [Cómo permitir a los usuarios y grupos crear y modificar roles](emr-iam-roles-create-permissions.md)
# Roles de servicio de IAM utilizados por Amazon EMR
Amazon EMR utiliza roles de servicio de IAM para llevar a cabo acciones en su nombre al aprovisionar los recursos del clúster, ejecutar aplicaciones, escalar recursos de forma dinámica y crear y ejecutar Cuadernos de Amazon EMR. Amazon EMR utiliza los siguientes roles cuando interactúa con otros servicios de AWS . Cada rol tiene una función exclusiva en Amazon EMR. Los temas de esta sección describen la función del rol y facilitan los roles y la política de permisos predeterminados para cada rol.
Si tiene un código de aplicación en el clúster que llama directamente a AWS los servicios, es posible que necesite usar el SDK para especificar las funciones. Para obtener más información, consulte [Utilice las funciones de IAM con aplicaciones que llamen directamente a AWS los servicios](emr-iam-roles-calling.md).
**Topics**
+ [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md)
+ [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md)
+ [Rol de servicio para el escalado automático en Amazon EMR (rol de Auto Scaling)](emr-iam-role-automatic-scaling.md)
+ [Rol de servicio para Cuadernos de Amazon EMR](emr-managed-notebooks-service-role.md)
+ [Uso de roles vinculados a servicios para Amazon EMR](using-service-linked-roles.md)
# Rol de servicio para Amazon EMR (rol de EMR)
El rol de Amazon EMR define las acciones permitidas para Amazon EMR al aprovisionar recursos y realizar tareas de nivel de servicio que no se llevan a cabo en el contexto de una instancia de Amazon EC2 que se ejecuta dentro de un clúster. Por ejemplo, el rol de servicio se utiliza para aprovisionar instancias de EC2 cuando se lanza un clúster.
+ El nombre del rol predeterminado es `EMR_DefaultRole_V2`.
+ La política administrada predeterminada con ámbito de aplicación de Amazon EMR y asociada a `EMR_DefaultRole_V2` es `AmazonEMRServicePolicy_v2`. Esta política, versión 2, sustituye a la política administrada predeterminada, `AmazonElasticMapReduceRole`, ya obsoleta.
`AmazonEMRServicePolicy_v2` depende del acceso limitado a los recursos que Amazon EMR aprovisiona o utiliza. Cuando utilice esta política, tendrá que pasar la etiqueta de usuario `for-use-with-amazon-emr-managed-policies = true` al aprovisionar el clúster. Amazon EMR propagará automáticamente esas etiquetas. Además, es posible que tenga que agregar manualmente una etiqueta de usuario a tipos específicos de recursos, como grupos de seguridad de EC2 que no fueron creados por Amazon EMR. Consulte [Etiquetado de recursos para usar políticas administradas](emr-managed-iam-policies.md#manually-tagged-resources).
**importante**
Amazon EMR utiliza este rol de servicio de Amazon EMR y el rol `AWSServiceRoleForEMRCleanup` para limpiar los recursos del clúster de su cuenta que ya no utiliza, como las instancias de Amazon EC2. Debe incluir acciones para que las políticas de rol eliminen o terminen los recursos. De lo contrario, Amazon EMR no podrá realizar estas acciones de limpieza y podría incurrir en costos por los recursos no utilizados que permanecen en el clúster.
A continuación se muestra el contenido de la política `AmazonEMRServicePolicy_v2`. También puede ver el contenido actual de la política [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)administrada en la consola de 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"
}
}
}
]
}
```
------
Su rol de servicio debe usar la siguiente política de confianza.
**importante**
La siguiente política de confianza incluye las claves de condición globales [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) y [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) para limitar los permisos que concede a Amazon EMR a determinados recursos de su cuenta. Con estas, podrá protegerse contra el [problema del suplente confuso](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:*"
}
}
}
]
}
```
------
# Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)
El rol de servicio para instancias de EC2 de clúster (también conocido como el perfil de instancia de EC2 para Amazon EMR) es un tipo especial de rol de servicio que está asignado a cada instancia de EC2 de un clúster de Amazon EMR cuando se lanza la instancia. Los procesos de aplicación que se ejecutan sobre el ecosistema de Hadoop asumen este rol para los permisos, para interactuar así con otros productos de AWS .
Para obtener más información sobre los roles de servicio para instancias de EC2, consulte [Uso de un rol de IAM para conceder permisos a aplicaciones que se ejecutan en instancias de Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) en la *Guía del usuario de IAM*.
**importante**
El rol de servicio predeterminado para las instancias de EC2 en clústeres y su política administrada AWS predeterminada asociada `AmazonElasticMapReduceforEC2Role` están en vías de caducar y no se proporcionan políticas AWS administradas sustitutivas. Tendrá que crear y especificar un perfil de instancia para reemplazar la política predeterminada y el rol obsoletos.
## Política administrada y rol predeterminados
+ El nombre del rol predeterminado es `EMR_EC2_DefaultRole`.
+ La política administrada `EMR_EC2_DefaultRole` predeterminada, `AmazonElasticMapReduceforEC2Role`, está a punto de finalizar su soporte. En lugar de utilizar una política administrada predeterminada para el perfil de instancia de EC2, aplique políticas basadas en recursos a los buckets de S3 y otros recursos que Amazon EMR necesite, o utilice su propia política administrada por el cliente con un rol de IAM como perfil de instancia. Para obtener más información, consulte [Creación de un rol de servicio para las instancias de EC2 del clúster con permisos de privilegios mínimos](#emr-ec2-role-least-privilege).
Lo siguiente muestra el contenido de la versión 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"
}
]
}
```
------
Su rol de servicio debe usar la siguiente política de confianza.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole"
}
]
}
```
------
## Creación de un rol de servicio para las instancias de EC2 del clúster con permisos de privilegios mínimos
Como práctica recomendada, le recomendamos encarecidamente que cree un rol de servicio para las instancias EC2 del clúster y una política de permisos que tenga los permisos mínimos para otros AWS servicios que requiera su aplicación.
La política administrada predeterminada, `AmazonElasticMapReduceforEC2Role`, proporciona los permisos que facilitan el lanzar un clúster inicial. Sin embargo, `AmazonElasticMapReduceforEC2Role` está en vías de quedar obsoleto y Amazon EMR no proporcionará una política predeterminada gestionada que AWS sustituya a la función obsoleta. Para lanzar un clúster inicial, debe proporcionar una política basada en los recursos o en la identificación administrada por el cliente.
Las siguientes instrucciones de política facilitan ejemplos de permisos necesarios para las distintas características de Amazon EMR. Le recomendamos que utilice estos permisos para crear una política de permisos que restrinja el acceso tan solo a aquellas funciones y recursos que necesite el clúster. Todos los ejemplos de declaraciones de política utilizan la *us-west-2* región y el identificador de cuenta ficticio AWS . *123456789012* Sustituya estos según corresponda para el clúster.
Para obtener más información sobre la creación y la especificación de roles personalizados, consulte [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md).
**nota**
Si crea un rol de EMR personalizado para EC2, siga el flujo de trabajo básico, que crea automáticamente un perfil de instancia con el mismo nombre. Amazon EC2 le permite crear roles y perfiles de instancia con nombres diferentes, pero Amazon EMR no admite esta configuración y se produce un error “Perfil de instancia no válido” al crear el clúster.
### Lectura y escritura de datos en Amazon S3 con EMRFS
Cuando una aplicación que se ejecuta en un clúster de Amazon EMR hace referencia a los datos con el formato `s3://mydata`, Amazon EMR utiliza el perfil de instancia de EC2 para realizar la solicitud. Por lo general, los clústeres leen y escriben datos en Amazon S3 de esta forma, y Amazon EMR utiliza los permisos asociados al rol de servicio para instancias de EC2 del clúster de forma predeterminada. Para obtener más información, consulte [Configuración de roles de IAM para solicitudes de EMRFS a Amazon S3](emr-emrfs-iam-roles.md).
Dado que los roles de IAM para EMRFS seguirán usando los permisos asociados al rol de servicio para las instancias de EC2 del clúster, como práctica recomendada, le recomendamos que utilice los roles de IAM para EMRFS y limite los permisos de Amazon S3 y EMRFS asociados al rol de servicio para las instancias de EC2 del clúster.
La siguiente instrucción de ejemplo señala los permisos que EMRFS necesita para hacer solicitudes a Amazon S3.
+ *my-data-bucket-in-s3-for-emrfs-reads-and-writes* especifica el bucket de Amazon S3 en el que el clúster lee y escribe los datos y todas las subcarpetas con */\$1*. Añada solo los buckets y carpetas que necesita su aplicación.
+ La instrucción de política que permite realizar acciones de `dynamodb` solo es necesaria si la vista coherente de EMRFS está habilitada. *EmrFSMetadata* especifica la carpeta predeterminada para la vista coherente de 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"
}
]
}
```
------
### Almacenamiento de archivos de registro en Amazon S3
La siguiente instrucción de política permite al clúster de Amazon EMR almacenar los archivos de registro en la ubicación de Amazon S3 indicada. En el ejemplo siguiente, cuando se creó el clúster, *s3://MyLoggingBucket/MyEMRClusterLogs* se especificó mediante la **ubicación S3 de la carpeta de registro** en la consola, mediante la `--log-uri` AWS CLI opción del comando o mediante el `LogUri` parámetro del `RunJobFlow` comando. Para obtener más información, consulte [Archivar archivos de registro en 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"
}
]
}
```
------
### Uso del catálogo de datos de AWS Glue
La siguiente declaración de política permite las acciones que son necesarias si se utiliza el catálogo de datos de AWS Glue como almacén de aplicaciones. Para obtener más información, consulte [Uso del catálogo de datos de AWS Glue como metaalmacén para Spark SQL](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-glue.html), [Uso del catálogo de datos de AWS Glue como metaalmacén para Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html) y [Uso de Presto con el catálogo de datos de AWS Glue en la](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-presto-glue.html) Guía de versiones de 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"
}
]
}
```
------
# Rol de servicio para el escalado automático en Amazon EMR (rol de Auto Scaling)
El rol de Auto Scaling de Amazon EMR sirve básicamente para lo mismo que el rol de servicio, pero permite acciones adicionales para entornos de escalado dinámico.
+ El nombre del rol predeterminado es `EMR_AutoScaling_DefaultRole`.
+ La política administrada predeterminada y asociada a `EMR_AutoScaling_DefaultRole` es `AmazonElasticMapReduceforAutoScalingRole`.
El contenido de la versión 1 de `AmazonElasticMapReduceforAutoScalingRole` se muestra a continuación.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:DescribeAlarms",
"elasticmapreduce:ListInstanceGroups",
"elasticmapreduce:ModifyInstanceGroups"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowCLOUDWATCHDescribealarms"
}
]
}
```
------
Su rol de servicio debe usar la siguiente política de confianza.
**importante**
La siguiente política de confianza incluye las claves de condición globales [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) y [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) para limitar los permisos que concede a Amazon EMR a determinados recursos de su cuenta. Con estas, podrá protegerse contra el [problema del suplente confuso](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"
}
]
}
```
------
# Rol de servicio para Cuadernos de Amazon EMR
Cada cuaderno EMR necesita permisos para acceder a otros AWS recursos y realizar acciones. Las políticas de IAM asociadas a esta función de servicio proporcionan permisos para que el portátil interactúe con otros servicios. AWS Al crear un bloc de notas utilizando el Consola de administración de AWS, se especifica un rol de *AWS servicio*. Puede utilizar el rol predeterminado, `EMR_Notebooks_DefaultRole` o especificar un rol que haya creado. Si no se ha creado un bloc de notas anteriormente, puede elegir crear el rol predeterminado.
+ El nombre del rol predeterminado es `EMR_Notebooks_DefaultRole`.
+ Las políticas administradas predeterminadas asociadas a `EMR_Notebooks_DefaultRole` son `AmazonElasticMapReduceEditorsRole` y `S3FullAccessPolicy`.
Su rol de servicio debe usar la siguiente política de confianza.
**importante**
La siguiente política de confianza incluye las claves de condición globales [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) y [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) para limitar los permisos que concede a Amazon EMR a determinados recursos de su cuenta. Con estas, podrá protegerse contra el [problema del suplente confuso](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"
}
]
}
```
------
El contenido de la versión 1 de `AmazonElasticMapReduceEditorsRole` es el siguiente.
------
#### [ 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"
}
]
}
```
------
A continuación, se muestra el contenido de `S3FullAccessPolicy`. La `S3FullAccessPolicy` permite que su rol de servicio para Cuadernos de Amazon EMR realice todas las acciones de Amazon S3 en los objetos de su Cuenta de AWS. Al crear un rol de servicio personalizado para Cuadernos de Amazon EMR, debe otorgarle permisos a Amazon S3 para ese rol de servicio.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
}
]
}
```
------
Puede limitar el acceso de lectura y escritura para su rol de servicio a la ubicación de Amazon S3 en la que desee guardar los archivos de su cuaderno. Utilice el siguiente conjunto mínimo de permisos de Amazon S3.
```
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
```
Si su bucket de Amazon S3 está cifrado, debe incluir los siguientes permisos para AWS Key Management Service.
```
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
```
Cuando vincula repositorios de Git a su cuaderno y necesita crear un secreto para el repositorio, debe agregar el permiso `secretsmanager:GetSecretValue` a la política de IAM asociada al rol de servicio de Cuadernos de Amazon EMR. A continuación se muestra una política de ejemplo:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"*"
]
}
]
}
```
------
## Permisos del rol de servicio de Cuadernos de Amazon EMR
En esta tabla se enumeran las acciones que Cuadernos de Amazon EMR lleva a cabo con el rol de servicio, junto con los permisos necesarios para cada acción.
****
| Action | Permisos |
| --- | --- |
| Establezca un canal de red seguro entre un cuaderno y un clúster de Amazon EMR y lleve a cabo las acciones de limpieza necesarias. | "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"
|
| Usa las credenciales de Git almacenadas en AWS Secrets Manager para vincular los repositorios de Git a un cuaderno. | "secretsmanager:GetSecretValue"
|
| Aplique AWS etiquetas a la interfaz de red y a los grupos de seguridad predeterminados que EMR Notebooks crea al configurar el canal de red seguro. Para obtener más información, consulte [Tagging AWS resources](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) (Etiquetado de los recursos de ). | "ec2:CreateTags"
|
| Acceda a los archivos y metadatos de los cuadernos en Amazon S3 o cárguelos. | "s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:ListBucket",
"s3:DeleteObject"
Los siguientes permisos solo son necesarios si utiliza un bucket de Amazon S3 cifrado. "kms:Decrypt",
"kms:GenerateDataKey",
"kms:ReEncryptFrom",
"kms:ReEncryptTo",
"kms:DescribeKey"
|
## Actualizaciones de EMR Notebooks a las políticas gestionadas AWS
Consulta los detalles sobre las actualizaciones de las políticas AWS gestionadas para los Notebooks EMR desde el 1 de marzo de 2021.
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| AmazonElasticMapReduceEditorsRole - Added permissions | Cuadernos de Amazon EMR agregó los permisos `ec2:describeVPCs` y `elastmicmapreduce:ListSteps` a `AmazonElasticMapReduceEditorsRole`. | 8 de febrero de 2023 |
| Cuadernos de Amazon EMR comenzó a registrar cambios | EMR Notebooks comenzó a realizar un seguimiento de los cambios en sus políticas gestionadas AWS . | 8 de febrero de 2023 |
# Uso de roles vinculados a servicios para Amazon EMR
[Amazon EMR utiliza funciones vinculadas a AWS Identity and Access Management servicios (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rol vinculado a un servicio es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EMR. Amazon EMR predefine las funciones vinculadas al servicio e incluyen todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre.
**Topics**
+ [Uso de roles vinculados a servicios para Amazon EMR para limpieza](using-service-linked-roles-cleanup.md)
+ [Uso de roles vinculados a servicios con Amazon EMR para el registro de escritura anticipada](using-service-linked-roles-wal.md)
**Para obtener información sobre otros servicios que admiten funciones vinculadas a servicios, consulte los [AWS servicios que funcionan con IAM y busque los servicios con](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) la palabra **Sí** en la columna Funciones vinculadas a servicios.** Elija una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
# Uso de roles vinculados a servicios para Amazon EMR para limpieza
[Amazon EMR utiliza funciones vinculadas a AWS Identity and Access Management servicios (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rol vinculado a un servicio es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EMR. Amazon EMR predefine las funciones vinculadas al servicio e incluyen todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre.
Los roles vinculados a servicios funcionan juntamente con el rol de servicio de Amazon EMR y el perfil de instancia de Amazon EC2 para Amazon EMR. Para obtener más información acerca del rol de servicio y del perfil de instancia, consulte [Configure las funciones de servicio de IAM para los permisos de Amazon EMR AWS a los servicios y recursos](emr-iam-roles.md).
Un rol vinculado al servicio simplifica la configuración de Amazon EMR porque ya no tendrá que agregar manualmente los permisos requeridos. Amazon EMR define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EMR puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda asociar a ninguna otra entidad de IAM.
Puede eliminar este rol vinculado a servicios para Amazon EMR solo después de eliminar cualquier recurso relacionado y finalizar todos los clústeres de EMR de la cuenta. Esto protege sus recursos de Amazon EMR, puesto que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
## Uso de roles vinculados a servicios para limpieza
Amazon EMR utiliza la **AWSServiceRoleForEMRCleanup**función basada en servicios para conceder a Amazon EMR permiso para cancelar y eliminar los recursos de Amazon EC2 en su nombre si la función vinculada al servicio de Amazon EMR pierde esa capacidad. Si aún no existe, Amazon EMR crea el rol vinculado a servicios automáticamente durante la creación del clúster.
El rol AWSService RoleFor EMRCleanup vinculado al servicio confía en que los siguientes servicios asuman el rol:
+ `elasticmapreduce.amazonaws.com`
La política de permisos de roles AWSService RoleFor EMRCleanup vinculados al servicio permite a Amazon EMR realizar las siguientes acciones en los recursos especificados:
+ Acción: `DescribeInstances` en `ec2`
+ Acción: `DescribeLaunchTemplates` en `ec2`
+ Acción: `DeleteLaunchTemplate` en `ec2`
+ Acción: `DescribeSpotInstanceRequests` en `ec2`
+ Acción: `ModifyInstanceAttribute` en `ec2`
+ Acción: `TerminateInstances` en `ec2`
+ Acción: `CancelSpotInstanceRequests` en `ec2`
+ Acción: `DeleteNetworkInterface` en `ec2`
+ Acción: `DescribeInstanceAttribute` en `ec2`
+ Acción: `DescribeVolumeStatus` en `ec2`
+ Acción: `DescribeVolumes` en `ec2`
+ Acción: `DetachVolume` en `ec2`
+ Acción: `DeleteVolume` en `ec2`
+ Acción: `DescribePlacementGroups` en `ec2`
+ Acción: `DeletePlacementGroup` en `ec2`
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios.
## Creación de un rol vinculado a un servicio para Amazon EMR
No necesita crear el rol manualmente. AWSService RoleFor EMRCleanup Cuando lanza un clúster, ya sea por primera vez o cuando el rol AWSService RoleFor EMRCleanup vinculado al servicio no está presente, Amazon EMR crea el rol vinculado al AWSService RoleFor EMRCleanup servicio automáticamente. Debe tener permisos para crear un rol vinculado a servicios. Para obtener una instrucción de ejemplo que agregue esta capacidad a la política de permisos de una entidad de IAM (como un usuario, grupo o rol):
Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que tiene que crear el rol vinculado al servicio:
```
{
"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**
Si utilizaste Amazon EMR antes del 24 de octubre de 2017, cuando no se admitían las funciones vinculadas a servicios, Amazon EMR creó la AWSService RoleFor EMRCleanup función vinculada a servicios en tu cuenta. Para obtener más información, consulte [Un nuevo rol ha aparecido en la cuenta de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
## Edición de un rol vinculado a un servicio para Amazon EMR
Amazon EMR no le permite editar el rol vinculado al AWSService RoleFor EMRCleanup servicio. Después de crear un rol vinculado a servicios, no puede cambiarle el nombre a este rol vinculado a servicios, ya que varias entidades pueden hacer referencia al rol vinculado a servicios. No obstante, puede editar la descripción del rol vinculado a servicios mediante IAM.
### Edición de la descripción de un rol vinculado a un servicio (consola de IAM)
Puede utilizar la consola de IAM para editar la descripción de un rol vinculado a un servicio.
**Para editar la descripción de un rol vinculado a un servicio (consola)**
1. En el panel de navegación de la consola de IAM, elija **Roles**.
1. Seleccione el nombre del rol que desea modificar.
1. En el extremo derecho de **Descripción del rol**, seleccione **Editar**.
1. Ingrese una descripción nueva en el cuadro y elija **Save changes** (Guardar cambios).
### Edición de la descripción de un rol vinculado a un servicio (CLI de IAM)
Puede utilizar los comandos de IAM del AWS Command Line Interface para editar la descripción de un rol vinculado a un servicio.
**Para cambiar la descripción de un rol vinculado a un servicio (CLI)**
1. (Opcional) Para ver la descripción actual de un rol, ejecute uno de los siguientes comandos:
```
$ aws iam get-role --role-name role-name
```
Utilice el nombre del rol, no el ARN, para hacer referencia a los roles con los comandos de CLI. Por ejemplo, si un rol tiene el ARN `arn:aws:iam::123456789012:role/myrole`, debe referirse a él como **myrole**.
1. Para actualizar la descripción de un rol vinculado a un servicio, ejecute uno de los siguientes comandos:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Edición de la descripción de un rol vinculado a un servicio (API de IAM)
Puede utilizar la API de IAM para editar la descripción de un rol vinculado a un servicio.
**Para cambiar la descripción de un rol vinculado a un servicio (API)**
1. (Opcional) Para ver la descripción actual de una función, ejecute el siguiente comando:
API de IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Para actualizar la descripción de una función, use el siguiente comando:
API de IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Eliminación de un rol vinculado a un servicio para Amazon EMR
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a servicios, le recomendamos que elimine dicho rol vinculado a servicios. De esta forma, no tendrá una entidad no utilizada cuya supervisión o mantenimiento no se realizan de forma activa. Sin embargo, debe limpiar el rol vinculado al servicio antes de eliminarlo.
### Saneamiento de un rol vinculado a servicios
Antes de poder utilizar IAM para eliminar un rol vinculado a servicios, primero debe confirmar que dicho rol vinculado a servicios no tiene sesiones activas y eliminar los recursos que utiliza el rol vinculado a servicios.
**Para comprobar si el rol vinculado a un servicio tiene una sesión activa en la consola de IAM**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación. Seleccione el nombre (no la casilla de verificación) del rol vinculado al AWSService RoleFor EMRCleanup servicio.
1. En la página **Resumen** del rol vinculado a servicios seleccionado, elija **Asesor de acceso**.
1. En la pestaña **Access Advisor**, revise la actividad reciente del rol vinculado al servicio.
**nota**
Si no está seguro de si Amazon EMR utiliza el rol AWSService RoleFor EMRCleanup vinculado al servicio, puede intentar eliminar el rol vinculado al servicio. Si el servicio está utilizando el rol vinculado a servicios, este no podrá eliminarse y podrá ver las regiones en las que se está utilizando el rol vinculado a servicios. Si el rol vinculado a servicios se está utilizando, debe esperar a que la sesión finalice para poder eliminar el rol vinculado a servicios. No se puede revocar la sesión de un rol vinculado a servicios.
**Para eliminar los recursos de Amazon EMR utilizados por AWSService RoleFor EMRCleanup**
+ Termine todos los clústeres de su cuenta. Para obtener más información, consulte [Finalización de un clúster de Amazon EMR en estado de inicio, ejecución o espera.](UsingEMR_TerminateJobFlow.md).
### Eliminación de un rol vinculado a un servicio (consola de IAM)
Puede utilizar la consola de IAM para eliminar un rol vinculado a un servicio.
**Para eliminar un rol vinculado a un servicio (consola)**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación. Seleccione la casilla de verificación situada junto a ella AWSService RoleForEMRCleanup, no el nombre o la fila en sí.
1. En **Role actions (Acciones de rol)** en la parte superior de la página, elija **Delete role (Eliminar rol)**.
1. En el cuadro de diálogo de confirmación, revise los datos del servicio al que se accedió por última vez, que muestran cuándo accedió por última vez a un AWS servicio cada uno de los roles seleccionados. Esto lo ayuda a confirmar si el rol está actualmente activo. Para continuar, elija **Yes, Delete**.
1. Consulte las notificaciones de la consola de IAM para supervisar el progreso de la eliminación del rol vinculado al servicio. Como el proceso de eliminación del rol vinculado a servicios de IAM es asíncrono, dicha tarea puede realizarse correctamente o fallar después de que envía la solicitud de eliminación del rol vinculado a servicios. Si la tarea no se realiza correctamente, puede seleccionar **View details (Ver detalles)** o **View Resources (Ver recursos)** desde las notificaciones para obtener información sobre el motivo por el que no se pudo eliminar el rol. Si la eliminación no pudo producirse porque hay recursos en el servicio que está utilizando el rol, entonces el motivo del error incluye una lista de recursos.
### Eliminación de un rol vinculado a un servicio (CLI de IAM)
Puede utilizar los comandos de IAM desde el AWS Command Line Interface para eliminar un rol vinculado a un servicio. Como los roles vinculados a servicios no se puede eliminar si están en uso o tienen recursos asociados, debe enviar una solicitud de eliminación. Si estas condiciones no se cumplen, dicha solicitud se puede denegar.
**Para eliminar un rol vinculado a un servicio (CLI)**
1. Para comprobar el estado de la tarea de eliminación, debe apuntar el valor de `deletion-task-id` de la respuesta. Escriba el siguiente comando para enviar una solicitud de eliminación de un rol vinculado a un servicio:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRCleanup
```
1. Escriba el siguiente comando para comprobar el estado de la tarea de eliminación:
```
$ 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
```
El estado de la tarea de eliminación puede ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` o `FAILED`. Si ocurre un error durante la eliminación, la llamada devuelve el motivo del error para que pueda resolver el problema.
### Eliminación de un rol vinculado a un servicio (API de IAM)
Puede utilizar la API de IAM para eliminar un rol vinculado a un servicio. Como los roles vinculados a servicios no se puede eliminar si están en uso o tienen recursos asociados, debe enviar una solicitud de eliminación. Si estas condiciones no se cumplen, dicha solicitud se puede denegar.
**Para eliminar un rol vinculado a un servicio (API)**
1. Para enviar una solicitud de eliminación de un rol vinculado a un servicio, llama. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) En la solicitud, especifique el nombre del AWSService RoleFor EMRCleanup rol.
Para comprobar el estado de la tarea de eliminación, debe apuntar el valor de `DeletionTaskId` de la respuesta.
1. Para comprobar el estado de la tarea de eliminación, realice una llamada a [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). En la solicitud, especifique el valor de `DeletionTaskId`.
El estado de la tarea de eliminación puede ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` o `FAILED`. Si ocurre un error durante la eliminación, la llamada devuelve el motivo del error para que pueda resolver el problema.
## Regiones compatibles para AWSService RoleFor EMRCleanup
Amazon EMR admite el uso de la función AWSService RoleFor EMRCleanup vinculada al servicio en las siguientes regiones.
****
| Nombre de la región | Identidad de la región | Compatibilidad en Amazon EMR |
| --- | --- | --- |
| Este de EE. UU. (Norte de Virginia) | us-east-1 | Sí |
| Este de EE. UU. (Ohio) | us-east-2 | Sí |
| Oeste de EE. UU. (Norte de California) | us-west-1 | Sí |
| Oeste de EE. UU. (Oregón) | us-west-2 | Sí |
| Asia-Pacífico (Mumbai) | ap-south-1 | Sí |
| Asia-Pacífico (Osaka) | ap-northeast-3 | Sí |
| Asia-Pacífico (Seúl) | ap-northeast-2 | Sí |
| Asia-Pacífico (Singapur) | ap-southeast-1 | Sí |
| Asia-Pacífico (Sídney) | ap-southeast-2 | Sí |
| Asia-Pacífico (Tokio) | ap-northeast-1 | Sí |
| Canadá (centro) | ca-central-1 | Sí |
| Europa (Fráncfort) | eu-central-1 | Sí |
| Europa (Irlanda) | eu-west-1 | Sí |
| Europa (Londres) | eu-west-2 | Sí |
| Europa (París) | eu-west-3 | Sí |
| América del Sur (São Paulo) | sa-east-1 | Sí |
# Uso de roles vinculados a servicios con Amazon EMR para el registro de escritura anticipada
[Amazon EMR utiliza funciones vinculadas a AWS Identity and Access Management servicios (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rol vinculado a un servicio es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EMR. Amazon EMR predefine las funciones vinculadas al servicio e incluyen todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre.
Los roles vinculados a servicios funcionan juntamente con el rol de servicio de Amazon EMR y el perfil de instancia de Amazon EC2 para Amazon EMR. Para obtener más información acerca del rol de servicio y del perfil de instancia, consulte [Configure las funciones de servicio de IAM para los permisos de Amazon EMR AWS a los servicios y recursos](emr-iam-roles.md).
Un rol vinculado al servicio simplifica la configuración de Amazon EMR porque ya no tendrá que agregar manualmente los permisos requeridos. Amazon EMR define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EMR puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda asociar a ninguna otra entidad de IAM.
Puede eliminar este rol vinculado a servicios para Amazon EMR solo después de eliminar los recursos relacionados y finalizar todos los clústeres de EMR de la cuenta. Esto protege sus recursos de Amazon EMR, puesto que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
## Permisos de roles vinculados a servicios para registro de escritura anticipada (WAL)
Amazon EMR utiliza la función **AWSServiceRoleForEMRWAL vinculada al** servicio para recuperar el estado de un clúster.
La función vinculada al servicio de AWSService RoleFor EMRWAL confía en los siguientes servicios para que la asuman:
+ `emrwal.amazonaws.com`
La política de permisos de [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md) para el rol vinculado a servicios permite a Amazon EMR que complete las siguientes acciones en los recursos especificados:
+ Acción: `DescribeCluster` en `*`
Debe configurar los permisos para permitir que una entidad de IAM (en este caso, Amazon EMR WAL) cree, edite o elimine un rol vinculado a servicios. Añada las siguientes instrucciones, según sea necesario, a la política de permisos de su perfil de instancia:
## CreateServiceLinkedRole
**Para permitir que una entidad de IAM cree la función vinculada al servicio de EMRWAL AWSService RoleFor**
Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que tiene que crear el rol vinculado al servicio:
```
{
"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 una entidad de IAM edite la descripción de la función vinculada al servicio de EMRWAL AWSService RoleFor**
Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que tiene que editar la descripción del rol vinculado al servicio:
```
{
"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 una entidad de IAM elimine la función vinculada al servicio de EMRWAL AWSService RoleFor**
Agregue la siguiente instrucción a la política de permisos de la entidad de IAM que tiene que eliminar un rol vinculado al servicio:
```
{
"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"
]
}
}
}
```
## Creación de un rol vinculado a un servicio para Amazon EMR
No es necesario crear manualmente el rol EMRWAL. AWSService RoleFor Amazon EMR crea este rol vinculado al servicio automáticamente cuando crea un espacio de trabajo de WAL con la CLI de EMRWAL o desde AWS CloudFormation, o HBase creará el rol vinculado al servicio cuando configure un espacio de trabajo para Amazon EMR WAL y el rol vinculado al servicio aún no existe. Debe tener permisos para crear un rol vinculado a servicios. Para instrucciones de ejemplo que agreguen esta capacidad a la política de permisos de una entidad de IAM (como un usuario, grupo o rol), consulte la sección anterior, [Permisos de roles vinculados a servicios para registro de escritura anticipada (WAL)](#using-service-linked-roles-permissions-wal).
## Edición de un rol vinculado a un servicio para Amazon EMR
Amazon EMR no le permite editar el rol vinculado al servicio AWSService RoleFor EMRWAL. Después de crear un rol vinculado a servicios, no puede cambiarle el nombre a este rol vinculado a servicios, ya que varias entidades pueden hacer referencia al rol vinculado a servicios. No obstante, puede editar la descripción del rol vinculado a servicios mediante IAM.
### Edición de la descripción de un rol vinculado a un servicio (consola de IAM)
Puede utilizar la consola de IAM para editar la descripción de un rol vinculado a un servicio.
**Para editar la descripción de un rol vinculado a un servicio (consola)**
1. En el panel de navegación de la consola de IAM, elija **Roles**.
1. Seleccione el nombre del rol que desea modificar.
1. En el extremo derecho de **Descripción del rol**, seleccione **Editar**.
1. Ingrese una descripción nueva en el cuadro y elija **Save changes** (Guardar cambios).
### Edición de la descripción de un rol vinculado a un servicio (CLI de IAM)
Puede utilizar los comandos de IAM del AWS Command Line Interface para editar la descripción de un rol vinculado a un servicio.
**Para cambiar la descripción de un rol vinculado a un servicio (CLI)**
1. (Opcional) Para ver la descripción actual de un rol, ejecute uno de los siguientes comandos:
```
$ aws iam get-role --role-name role-name
```
Utilice el nombre del rol, no el ARN, para hacer referencia a los roles con los comandos de CLI. Por ejemplo, si un rol tiene el ARN `arn:aws:iam::123456789012:role/myrole`, debe referirse a él como **myrole**.
1. Para actualizar la descripción de un rol vinculado a un servicio, ejecute uno de los siguientes comandos:
```
$ aws iam update-role-description --role-name role-name --description description
```
### Edición de la descripción de un rol vinculado a un servicio (API de IAM)
Puede utilizar la API de IAM para editar la descripción de un rol vinculado a un servicio.
**Para cambiar la descripción de un rol vinculado a un servicio (API)**
1. (Opcional) Para ver la descripción actual de una función, ejecute el siguiente comando:
API de IAM: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
1. Para actualizar la descripción de una función, use el siguiente comando:
API de IAM: [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
## Eliminación de un rol vinculado a un servicio para Amazon EMR
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a servicios, le recomendamos que elimine dicho rol vinculado a servicios. De esta forma, no tendrá una entidad no utilizada cuya supervisión o mantenimiento no se realizan de forma activa. Sin embargo, debe limpiar el rol vinculado al servicio antes de eliminarlo.
**nota**
La operación de registro de escritura anticipada no se ve afectada si eliminas la función AWSService RoleFor EMRWAL, pero Amazon EMR no eliminará automáticamente los registros que creó una vez que el clúster de EMR finalice. Por lo tanto, tendrá que eliminar manualmente los registros de Amazon EMR WAL si elimina el rol vinculado a servicios.
### Limpiar un rol vinculado a servicios
Antes de poder utilizar IAM para eliminar un rol vinculado a un servicio, primero debe confirmar que dicho rol no tiene sesiones activas y eliminar los recursos que utiliza.
**Para comprobar si el rol vinculado a un servicio tiene una sesión activa en la consola de IAM**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación. Seleccione el nombre (no la casilla de verificación) del rol de EMRWAL. AWSService RoleFor
1. En la página **Summary (Resumen)** del rol seleccionado, seleccione **Access Advisor**.
1. En la pestaña **Access Advisor**, revise la actividad reciente del rol vinculado al servicio.
**nota**
Si no está seguro de si Amazon EMR utiliza la función AWSService RoleFor EMRWAL, puede intentar eliminar la función vinculada al servicio. Si el servicio está utilizando el rol, este no podrá eliminarse y podrá ver las regiones en las que se está utilizando el rol vinculado a servicios. Si el rol vinculado a servicios se está utilizando, debe esperar a que la sesión finalice para poder eliminar el rol vinculado a servicios. No se puede revocar la sesión de un rol vinculado a servicios.
**Para eliminar los recursos de Amazon EMR utilizados por el EMRWAL AWSService RoleFor**
+ Termine todos los clústeres de su cuenta. Para obtener más información, consulte [Finalización de un clúster de Amazon EMR en estado de inicio, ejecución o espera.](UsingEMR_TerminateJobFlow.md).
### Eliminación de un rol vinculado a un servicio (consola de IAM)
Puede utilizar la consola de IAM para eliminar un rol vinculado a un servicio.
**Para eliminar un rol vinculado a un servicio (consola)**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación. Seleccione la casilla de verificación situada junto a AWSService RoleFor EMRWAL, no el nombre o la fila en sí.
1. En **Role actions (Acciones de rol)** en la parte superior de la página, elija **Delete role (Eliminar rol)**.
1. En el cuadro de diálogo de confirmación, revise los datos del servicio al que se accedió por última vez, que muestran cuándo accedió por última vez a un AWS servicio cada uno de los roles seleccionados. Esto lo ayuda a confirmar si el rol está actualmente activo. Para continuar, elija **Yes, Delete**.
1. Consulte las notificaciones de la consola de IAM para supervisar el progreso de la eliminación del rol vinculado al servicio. Como el proceso de eliminación del rol vinculado al servicio de IAM es asíncrono, dicha tarea puede realizarse correctamente o fallar después de que envía la solicitud de eliminación. Si la tarea no se realiza correctamente, puede seleccionar **View details (Ver detalles)** o **View Resources (Ver recursos)** desde las notificaciones para obtener información sobre el motivo por el que no se pudo eliminar el rol. Si la eliminación no pudo producirse porque hay recursos en el servicio que está utilizando el rol, entonces el motivo del error incluye una lista de recursos.
### Eliminación de un rol vinculado a un servicio (CLI de IAM)
Puede utilizar los comandos de IAM desde el AWS Command Line Interface para eliminar un rol vinculado a un servicio. Como los roles vinculados a servicios no se puede eliminar si están en uso o tienen recursos asociados, debe enviar una solicitud de eliminación. Si estas condiciones no se cumplen, dicha solicitud se puede denegar.
**Para eliminar un rol vinculado a un servicio (CLI)**
1. Para comprobar el estado de la tarea de eliminación, debe apuntar el valor de `deletion-task-id` de la respuesta. Escriba el siguiente comando para enviar una solicitud de eliminación de un rol vinculado a un servicio:
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-linked-role.html) --role-name AWSServiceRoleForEMRWAL
```
1. Escriba el siguiente comando para comprobar el estado de la tarea de eliminación:
```
$ 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
```
El estado de la tarea de eliminación puede ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` o `FAILED`. Si ocurre un error durante la eliminación, la llamada devuelve el motivo del error para que pueda resolver el problema.
### Eliminación de un rol vinculado a un servicio (API de IAM)
Puede utilizar la API de IAM para eliminar un rol vinculado a un servicio. Como los roles vinculados a servicios no se puede eliminar si están en uso o tienen recursos asociados, debe enviar una solicitud de eliminación. Si estas condiciones no se cumplen, dicha solicitud se puede denegar.
**Para eliminar un rol vinculado a un servicio (API)**
1. Para enviar una solicitud de eliminación de un rol vinculado a un servicio, llama. [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) En la solicitud, especifique el nombre del rol de AWSService RoleFor EMRWAL.
Para comprobar el estado de la tarea de eliminación, debe apuntar el valor de `DeletionTaskId` de la respuesta.
1. Para comprobar el estado de la tarea de eliminación, realice una llamada a [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). En la solicitud, especifique el valor de `DeletionTaskId`.
El estado de la tarea de eliminación puede ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` o `FAILED`. Si ocurre un error durante la eliminación, la llamada devuelve el motivo del error para que pueda resolver el problema.
## Regiones compatibles con EMRWAL AWSService RoleFor
Amazon EMR admite el uso de la función vinculada AWSService RoleFor al servicio EMRWAL en las siguientes regiones.
****
| Nombre de la región | Identidad de la región | Compatibilidad en Amazon EMR |
| --- | --- | --- |
| Este de EE. UU. (Norte de Virginia) | us-east-1 | Sí |
| Este de EE. UU. (Ohio) | us-east-2 | Sí |
| Oeste de EE. UU. (Norte de California) | us-west-1 | Sí |
| Oeste de EE. UU. (Oregón) | us-west-2 | Sí |
| Asia-Pacífico (Mumbai) | ap-south-1 | Sí |
| Asia-Pacífico (Singapur) | ap-southeast-1 | Sí |
| Asia-Pacífico (Sídney) | ap-southeast-2 | Sí |
| Asia-Pacífico (Tokio) | ap-northeast-1 | Sí |
| Europa (Fráncfort) | eu-central-1 | Sí |
| Europa (Irlanda) | eu-west-1 | Sí |
# Personalización de roles de IAM con Amazon EMR
Es posible que quiera personalizar los permisos y los roles de servicio de IAM para limitar los privilegios de acuerdo con los requisitos de seguridad. Para personalizar los permisos, le recomendamos que cree nuevos roles y políticas. Comience con los permisos de las políticas administradas para los roles predeterminados (por ejemplo, `AmazonElasticMapReduceforEC2Role` y `AmazonElasticMapReduceRole`). A continuación, copie y pegue el contenido de las nuevas instrucciones de política, modifique los permisos según corresponda y asocie las políticas de permisos modificadas a los roles que cree. Debe disponer de los permisos de IAM adecuados para trabajar con los roles y las políticas. Para obtener más información, consulte [Cómo permitir a los usuarios y grupos crear y modificar roles](emr-iam-roles-create-permissions.md).
Si crea un rol de EMR personalizado para EC2, siga el flujo de trabajo básico, que crea automáticamente un perfil de instancia con el mismo nombre. Amazon EC2 le permite crear roles y perfiles de instancia con nombres diferentes, pero Amazon EMR no admite esta configuración y se produce un error “Perfil de instancia no válido” al crear el clúster.
**importante**
Las políticas insertadas no se actualizan automáticamente cuando cambian los requisitos de servicio. Si crea y adjunta políticas insertadas, tenga en cuenta que se pueden producir actualizaciones de servicio que provoquen errores de permisos de forma repentina. Para obtener más información, consulte [Políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_managed-vs-inline.html) en la *Guía del usuario de IAM* y [Cómo especificar roles de IAM personalizados al crear un clúster](#emr-iam-roles-launch-jobflow).
Para obtener más información sobre cómo trabajar con los roles de IAM, consulte los siguientes temas en la *Guía del usuario de IAM*:
+ [Crear un rol para delegar permisos a un servicio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)
+ [Modificación de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/modifying-role.html)
+ [Eliminación de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/deleting-roles.html)
## Cómo especificar roles de IAM personalizados al crear un clúster
El rol de servicio para Amazon EMR y el rol para el perfil de instancia de Amazon EC2 se especifican al crear un clúster. El usuario que crea los clústeres necesita permisos para recuperar y asignar roles a Amazon EMR y a las instancias de EC2. De lo contrario, se produce el error **La cuenta no tiene autorización para llamar a EC2**. Para obtener más información, consulte [Cómo permitir a los usuarios y grupos crear y modificar roles](emr-iam-roles-create-permissions.md).
### Uso de la consola para especificar roles personalizados
Cuando cree un clúster, puede especificar un rol de servicio personalizado para Amazon EMR, un rol personalizado para el perfil de instancia de EC2 y un rol de Auto Scaling personalizado mediante **Opciones avanzadas**. Si utiliza las **Quick options (Opciones rápidas)**, se especifican el rol de servicio y el rol para el perfil de instancia de EC2 predeterminados. Para obtener más información, consulte [Roles de servicio de IAM utilizados por Amazon EMR](emr-iam-service-roles.md).
------
#### [ Console ]
**Especificar roles de IAM personalizados mediante la consola**
Al crear un clúster con la consola, debe especificar un rol de servicio personalizado para Amazon EMR y un rol personalizado para el perfil de instancia de EC2. Para obtener más información, consulte [Roles de servicio de IAM utilizados por Amazon EMR](emr-iam-service-roles.md).
1. [Inicie sesión en y abra la Consola de administración de AWS consola de Amazon EMR en https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. En **EMR en EC2** situado en el panel de navegación izquierdo, elija **Clústeres** y, a continuación, elija **Crear clúster**.
1. En **Configuración y permisos de seguridad**, busque los campos **Rol de IAM para el perfil de instancia** y **Rol de servicio para Amazon EMR**. Seleccione un rol en la lista para cada tipo de rol. Solo aparecerán los roles de la cuenta que tengan la política de confianza adecuada para ese tipo de rol.
1. Elija cualquier otra opción que se aplique a su clúster.
1. Para lanzar el clúster, elija **Crear clúster**.
------
### Utilícela AWS CLI para especificar funciones personalizadas
Puede especificar un rol de servicio para Amazon EMR y un rol de servicio para las instancias de EC2 del clúster de forma explícita mediante las opciones con el comando `create-cluster` desde la AWS CLI. Utilice la opción `--service-role` para especificar el rol de servicio. Utilice el argumento `InstanceProfile` de la opción `--ec2-attributes` para especificar el rol para el perfil de instancia de EC2.
El rol de Auto Scaling se especifica mediante la opción `--auto-scaling-role`. Para obtener más información, consulte [Uso del escalado automático con una política personalizada para grupos de instancias en Amazon EMR](emr-automatic-scaling.md).
**Para especificar funciones de IAM personalizadas mediante el AWS CLI**
+ El siguiente comando especifica el rol de servicio personalizado *MyCustomServiceRoleForEMR* y el rol personalizado para el perfil de instancia de EC2 *MyCustomServiceRoleForClusterEC2Instances* al lanzar un clúster. Este ejemplo utiliza el rol de Amazon EMR predeterminado.
**nota**
Se incluyen caracteres de continuación de línea de Linux (\$1) para facilitar la lectura. Se pueden eliminar o utilizar en los comandos de Linux. En Windows, elimínelos o sustitúyalos por un signo de intercalación (^).
```
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
```
Puede utilizar estas opciones para especificar roles predeterminados de forma explícita en lugar de usar la opción `--use-default-roles`. La opción `--use-default-roles` especifica el rol de servicio y el rol para el perfil de la instancia de EC2 que se ha definido en el archivo `config` de la AWS CLI.
El siguiente ejemplo muestra el contenido de un `config` archivo para AWS CLI las funciones personalizadas especificadas para Amazon EMR. Con este archivo de configuración, cuando se especifica la opción `--use-default-roles`, el clúster se crea con *MyCustomServiceRoleForEMR* y *MyCustomServiceRoleForClusterEC2Instances*. De forma predeterminada, el archivo `config` especifica el valor predeterminado `service_role` como `AmazonElasticMapReduceRole` y el valor predeterminado `instance_profile` 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
```
# Configuración de roles de IAM para solicitudes de EMRFS a Amazon S3
**nota**
La capacidad de asignación de roles de EMRFS que se describe en esta página se mejoró con la introducción de Amazon S3 Access Grants en Amazon EMR 6.15.0. Para obtener una solución de control de acceso escalable para los datos en Amazon S3, recomendamos utilizar [S3 Access Grants con Amazon EMR](emr-access-grants.md).
Cuando una aplicación que se ejecuta en un clúster hace referencia a los datos con el formato `s3://mydata`, Amazon EMR utiliza EMRFS para realizar la solicitud. Para interactuar con Amazon S3, EMRFS asume las políticas de permisos que se adjuntan a su [perfil de instancia de Amazon EC2](emr-iam-role-for-ec2.md). El mismo perfil de instancia de Amazon EC2 se utiliza independientemente del usuario o grupo mediante la aplicación o la ubicación de los datos en Amazon S3.
Si tiene clústeres con varios usuarios que necesitan diferentes niveles de acceso a los datos en Amazon S3 a través de EMRFS, puede establecer una configuración de seguridad con los roles de IAM para EMRFS. EMRFS puede asumir un rol de servicio diferente para las instancias de EC2 del clúster en función del usuario o grupo que realiza la solicitud o en función de la ubicación de los datos en Amazon S3. Cada rol de IAM para EMRFS puede tener diferentes permisos para obtener acceso a los datos en Amazon S3. Para obtener más información acerca del rol de servicio para las instancias de EC2 del clúster, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md).
Las versiones 5.10.0 y posteriores de Amazon EMR admiten el uso de roles de IAM personalizados para EMRFS. Si utiliza una versión anterior o tiene requisitos de autorización que los roles de IAM para EMRFS no son capaces de proporcionar, puede crear un proveedor de credenciales personalizado en su lugar. Para obtener más información, consulte [Autorización de acceso a los datos de EMRFS en Amazon S3](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-plan-credentialsprovider).
Cuando se usa una configuración de seguridad para especificar roles de IAM para EMRFS, debe definir asignaciones de roles. Cada asignación de roles especifica un rol de IAM que corresponde a los identificadores. Dichos identificadores determinan la base para el acceso a Amazon S3 a través de EMRFS. Los identificadores pueden ser usuarios, grupos o prefijos de Amazon S3 que indican una ubicación de datos. Cuando EMRFS realiza una solicitud a Amazon S3, y la solicitud coincide con la base para el acceso, EMRFS tiene las instancias de EC2 del clúster que asumen el rol de IAM correspondiente para la solicitud. Los permisos de IAM asociados a ese rol se aplican en lugar de los permisos de IAM adjuntos al rol de servicio para las instancias de EC2 del clúster.
Los usuarios y grupos de un mapeo de roles son usuarios y grupos de Hadoop que se definen en el clúster. Los usuarios y grupos se transfieren a EMRFS en el contexto de la aplicación que lo utiliza (por ejemplo, una suplantación de usuario de YARN). El prefijo de Amazon S3 puede ser un especificador de bucket de cualquier profundidad (por ejemplo, `s3://amzn-s3-demo-bucket` o `s3://amzn-s3-demo-bucket/myproject/mydata`). Puede especificar varios identificadores dentro de un único mapeo de roles, pero todos deben ser del mismo tipo.
**importante**
Los roles de IAM para EMRFS proporcionan aislamiento de la aplicación entre los usuarios de la aplicación. No proporcionan aislamiento de nivel del host entre los usuarios del host. Cualquier usuario con acceso a el clúster puede omitir el aislamiento para asumir cualquiera de los roles.
Cuando una aplicación del clúster realiza una solicitud a Amazon S3 a través de EMRFS, EMRFS evalúa las asignaciones de roles en el orden descendente en el que aparecen en la configuración de seguridad. Si una solicitud realizada a través de EMRFS no coincide con ningún identificador, EMRFS vuelve a usar el rol de servicio de las instancias de EC2 del clúster. Por este motivo, le recomendamos que las políticas asociadas a este rol limiten los permisos a Amazon S3. Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md).
## Configurar roles de
Antes de definir una configuración de seguridad con roles de IAM para EMRFS, planifique y cree los roles y las políticas de permisos que va a adjuntar a los roles. Para obtener más información, consulte [¿Cómo funcionan los roles de instancias de Amazon EC2?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) en la *Guía del usuario de IAM*. Al crear políticas de permisos, le recomendamos que empiece con la política administrada asociada al rol de Amazon EMR predeterminado para EC2 y que luego edite esta política de acuerdo con sus necesidades. El nombre del rol predeterminado es `EMR_EC2_DefaultRole` y la política administrada predeterminada para editar es `AmazonElasticMapReduceforEC2Role`. Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md).
### Actualización de políticas de confianza para asumir los permisos del rol
Cada rol que utiliza EMRFS debe tener una política de confianza que permita que el rol de Amazon EMR del clúster de EC2 lo asuma. Igualmente, el rol de Amazon EMR del clúster para EC2 debe tener una política de confianza que permita que los roles de EMRFS lo asuman.
En el ejemplo siguiente, la política de confianza se asocia a los roles para EMRFS. La instrucción permite que el rol de Amazon EMR predeterminado de EC2 asuma el rol. Por ejemplo, si tiene dos roles de EMRFS ficticios, `EMRFSRole_First` y `EMRFSRole_Second`, esta instrucción de la política se añade a las políticas de confianza para cada uno de ellos.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/EMR_EC2_DefaultRole",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Además, en el ejemplo siguiente, se añade la instrucción de la política de confianza a `EMR_EC2_DefaultRole` para permitir que los dos roles de EMRFS ficticios la asuman.
------
#### [ 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"
}
]
}
```
------
**Para actualizar la política de confianza de un rol de IAM**
Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Elija **Roles**, escriba el nombre del rol en **Search (Buscar)** y, a continuación, seleccione su **Role name (Nombre de rol)**.
1. Seleccione **Trust relationships (Relaciones de confianza)**, **Edit trust relationship (Editar relaciones de confianza)**.
1. Agregue una instrucción de confianza de acuerdo con **Documento de política** siguiendo las directrices anteriores y, a continuación, seleccione **Actualizar la política de confianza**.
### Especificación de un rol como un usuario de claves
Si un rol permite el acceso a una ubicación en Amazon S3 que está cifrada mediante una AWS KMS key, asegúrese de que el rol se especifica como un usuario de claves. Esto proporciona al rol permiso para utilizar la clave de KMS. Para obtener más información, consulte [Políticas de claves en AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) en la *Guía para desarrolladores de AWS Key Management Service *.
## Definición de una configuración de seguridad con roles de IAM para EMRFS
**importante**
Si no se aplica ninguno de los roles de IAM para EMRFS especificados, EMRFS vuelve a usar el rol de Amazon EMR para EC2. Considere la posibilidad de personalizar este rol para restringir los permisos en Amazon S3 según sea necesario para su aplicación y de especificar después este rol personalizado en lugar de `EMR_EC2_DefaultRole` cuando cree un clúster. Para obtener más información, consulte [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md) y [Cómo especificar roles de IAM personalizados al crear un clúster](emr-iam-roles-custom.md#emr-iam-roles-launch-jobflow).
**Para especificar roles de IAM para solicitudes de EMRFS a Amazon S3 con la consola**
1. Cree una configuración de seguridad que especifique los mapeos de roles:
1. En la consola de Amazon EMR, seleccione **Configuraciones de seguridad**, **Crear**.
1. Escriba un nombre para la configuración de seguridad en el campo **Name (Nombre)**. Este nombre se utiliza para especificar la configuración de seguridad cuando crea un clúster.
1. Elija **Usar roles de IAM para solicitudes de EMRFS a Amazon S3**.
1. Seleccione el **rol de IAM** que desea aplicar, elija en la lista **Base para el acceso** un identificador de tipo (**Usuarios**, **Grupos** o **Prefijos de S3**) y especifique los identificadores correspondientes. Si utiliza varios identificadores, sepárelos con una coma y sin espacios. Para obtener más información acerca de cada tipo de identificador, consulte [JSON configuration reference](#emrfs-seccfg-json) a continuación.
1. Elija **Add role** (Añadir rol) para configurar mapeos de roles adicionales, tal y como se describe en el paso anterior.
1. Defina otras opciones de configuración de seguridad según corresponda y elija **Create (Crear)**. Para obtener más información, consulte [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
1. Especifique la configuración de seguridad que creó anteriormente cuando cree un clúster. Para obtener más información, consulte [Especificar una configuración de seguridad para un clúster de Amazon EMR](emr-specify-security-configuration.md).
**Para especificar las funciones de IAM para las solicitudes de EMRFS a Amazon S3 mediante el AWS CLI**
1. Utilice el comando `aws emr create-security-configuration`, especificando un nombre para la configuración de seguridad y los detalles de configuración de seguridad en formato JSON.
El comando de ejemplo que se muestra a continuación crea una configuración de seguridad con el nombre `EMRFS_Roles_Security_Configuration`. Se basa en una estructura JSON del archivo `MyEmrfsSecConfig.json`, que se guarda en el mismo directorio en el que se ejecuta el comando.
```
aws emr create-security-configuration --name EMRFS_Roles_Security_Configuration --security-configuration file://MyEmrFsSecConfig.json.
```
Utilice las siguientes directrices para la estructura del archivo `MyEmrFsSecConfig.json`. Puede especificar esta estructura junto con estructuras de otras opciones de configuración de seguridad. Para obtener más información, consulte [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
A continuación, se muestra un ejemplo de fragmento de JSON para especificar roles de IAM personalizados para EMRFS dentro de una configuración de seguridad. Muestra las asignaciones de roles para los tres tipos de identificadores diferentes, seguidas de una referencia de parámetros.
```
{
"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/es_es/emr/latest/ManagementGuide/emr-emrfs-iam-roles.html)
1. Utilice el comando `aws emr create-cluster` para crear un clúster y especificar la configuración de seguridad que creó en el paso anterior.
En el siguiente ejemplo, se crea un clúster con las aplicaciones de Hadoop básicas predeterminadas instaladas. El clúster utiliza la configuración de seguridad creada anteriormente como `EMRFS_Roles_Security_Configuration` y también utiliza un rol de Amazon EMR personalizado para EC2, `EC2_Role_EMR_Restrict_S3`, que se especifica mediante el argumento `InstanceProfile` del parámetro `--ec2-attributes`.
**nota**
Se incluyen caracteres de continuación de línea de Linux (\$1) para facilitar la lectura. Se pueden eliminar o utilizar en los comandos de Linux. En Windows, elimínelos o sustitúyalos por un signo de intercalación (^).
```
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
```
# Utilice políticas basadas en recursos para el acceso de Amazon EMR al catálogo de datos de Glue AWS
Si usa AWS Glue junto con Hive, Spark o Presto en Amazon EMR, AWS Glue admite políticas basadas en recursos para controlar el acceso a los recursos del catálogo de datos. Estos recursos incluyen bases de datos, tablas, conexiones y funciones definidas por el usuario. Para obtener más información, consulte [Políticas de recursos de AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/glue-resource-policies.html) en la *Guía para desarrolladores de AWS Glue*.
Al utilizar políticas basadas en recursos para limitar el acceso a AWS Glue desde Amazon EMR, el principal que especifique en la política de permisos debe ser el ARN del rol asociado al perfil de instancia EC2 que se especifica al crear un clúster. Por ejemplo, para una política basada en recursos adjunta a un catálogo, puede especificar el ARN del rol para el rol de servicio predeterminado para las instancias EC2 del clúster, *EMR\$1EC2\$1DefaultRole* como`Principal`, utilizando el formato que se muestra en el siguiente ejemplo:
```
arn:aws:iam::acct-id:role/EMR_EC2_DefaultRole
```
*acct-id*Puede ser diferente del ID de la cuenta de AWS Glue. Esto permite el acceso desde clústeres de EMR en diferentes cuentas. Puede especificar varias entidades principales, cada una de ellas desde una cuenta diferente.
# Utilice las funciones de IAM con aplicaciones que llamen directamente a AWS los servicios
Las aplicaciones que se ejecutan en las instancias EC2 de un clúster pueden usar el perfil de instancia EC2 para obtener credenciales de seguridad temporales al llamar a los servicios. AWS
Las versiones de Hadoop disponibles con la versión 2.3.0 y posteriores de Amazon EMR ya se han actualizado para utilizar roles de IAM. Si su aplicación se ejecuta estrictamente sobre la arquitectura Hadoop y no llama directamente a ningún servicio AWS, debería funcionar con las funciones de IAM sin modificaciones.
Si su aplicación llama AWS directamente a los servicios, debe actualizarla para aprovechar las funciones de IAM. Esto significa que, en lugar de obtener credenciales de cuenta de `/etc/hadoop/conf/core-site.xml` en las instancias de EC2 del clúster, la aplicación utiliza un SDK para acceder a los recursos que utilizan roles de IAM o llama a los metadatos de la instancia de EC2 para obtener las credenciales temporales.
**Para acceder a AWS los recursos con funciones de IAM mediante un SDK**
+ En los siguientes temas se muestra cómo usar varios de ellos para acceder AWS SDKs a las credenciales temporales mediante los roles de IAM. Cada tema comienza con una versión de una aplicación que no utiliza roles de IAM y, a continuación, realiza un recorrido por el proceso de conversión de dicha aplicación para utilizar roles de IAM.
+ [Uso de roles de IAM para instancias de Amazon EC2 con el SDK para Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) en la *Guía para desarrolladores de AWS SDK para Java *
+ [Uso de roles de IAM para instancias de Amazon EC2 con el SDK para .NET](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-hosm.html) en la *Guía para desarrolladores de AWS SDK para .NET *
+ [Uso de roles de IAM para instancias de Amazon EC2 con el SDK para PHP](https://docs.aws.amazon.com/sdk-for-php/latest/developer-guide/php-dg-roles.html) en la *Guía para desarrolladores de AWS SDK para PHP ;*
+ [Uso de roles de IAM para instancias de Amazon EC2 con el SDK para Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ruby-dg-roles.html) en la *Guía para desarrolladores de AWS SDK para Ruby *
**Para obtener credenciales temporales de metadatos de instancias de EC2**
+ Llame a la siguiente URL desde una instancia de EC2 que se ejecute con la función de IAM especificada, que devolverá las credenciales de seguridad temporales asociadas (AccessKeyId, SecretAccessKey SessionToken, y caducidad). En el ejemplo que aparece a continuación se utiliza el perfil de instancia predeterminado para Amazon EMR, `EMR_EC2_DefaultRole`.
```
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/EMR_EC2_DefaultRole
```
Para obtener más información sobre cómo escribir aplicaciones que utilizan funciones de IAM, consulte [Conceder acceso AWS a los recursos a las aplicaciones que se ejecutan en instancias de Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html).
Para obtener más información acerca de las credenciales de seguridad temporales, consulte [Uso de credenciales de seguridad temporales](https://docs.aws.amazon.com/STS/latest/UsingSTS/using-temp-creds.html) en la guía *Uso de credenciales de seguridad temporales*.
# Cómo permitir a los usuarios y grupos crear y modificar roles
Las entidades principales de IAM (usuarios y grupos) que crean, modifican y especifican roles para un clúster, incluidos los roles predeterminados, deben tener permisos para realizar las acciones siguientes. Para obtener información sobre cada una de las acciones, consulte [Acciones](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) en la *Referencia de la API de IAM*.
+ `iam:CreateRole`
+ `iam:PutRolePolicy`
+ `iam:CreateInstanceProfile`
+ `iam:AddRoleToInstanceProfile`
+ `iam:ListRoles`
+ `iam:GetPolicy`
+ `iam:GetInstanceProfile`
+ `iam:GetPolicyVersion`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
El permiso `iam:PassRole` permite la creación del clúster. Los permisos restantes permiten la creación de las funciones predeterminadas.
Para obtener más información acerca de la actualización de permisos en IAM, consulte [Cambio de los permisos de un usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html) en la *Guía del usuario de IAM*.
# Ejemplos de políticas de Amazon EMR basadas en identidades
De forma predeterminada, los usuarios y roles no tienen permiso para crear ni modificar los recursos de Amazon EMR. Tampoco pueden realizar tareas mediante la API Consola de administración de AWS AWS CLI, o AWS . Un administrador de IAM debe crear políticas de IAM que concedan permisos a los usuarios y a los roles para realizar operaciones de la API concretas en los recursos especificados que necesiten. El administrador debe adjuntar esas políticas a los usuarios o grupos que necesiten esos permisos.
Para obtener más información acerca de cómo crear una política basada en identidad de IAM con estos documentos de políticas de JSON de ejemplo, consulte [Creación de políticas en la pestaña JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) en la *Guía del usuario de IAM*.
**Topics**
+ [Prácticas recomendadas en materia de políticas para Amazon EMR](security_iam_service-with-iam-policy-best-practices.md)
+ [Cómo permitir a los usuarios consultar sus propios permisos](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Políticas administradas por Amazon EMR](emr-managed-iam-policies.md)
+ [Políticas de IAM para el acceso basado en etiquetas para clústeres y cuadernos de EMR](emr-fine-grained-cluster-access.md)
+ [Denegar la ModifyInstanceGroup acción en Amazon EMR](emr-cluster-deny-modifyinstancegroup.md)
+ [Solución de problemas de identidad y acceso de Amazon EMR](security_iam_troubleshoot.md)
# Prácticas recomendadas en materia de políticas para Amazon EMR
Las políticas basadas en identidades son muy eficaces. Determinan si alguien puede crear o eliminar los recursos de Amazon EMR de su cuenta o acceder a ellos. Estas acciones pueden suponer costes para tu AWS cuenta. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience a utilizar las políticas AWS gestionadas**: para empezar a utilizar Amazon EMR rápidamente, utilice las políticas AWS gestionadas para conceder a sus empleados los permisos que necesitan. Estas políticas ya están disponibles en su cuenta, y las mantiene y actualiza AWS. Para obtener más información, consulte Cómo [empezar a usar permisos con políticas AWS administradas](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) en la *Guía del usuario de IAM* y. [Políticas administradas por Amazon EMR](emr-managed-iam-policies.md)
+ **Conceder privilegios mínimos**: al crear políticas personalizadas, conceda solo los permisos necesarios para llevar a cabo una tarea. Comience con un conjunto mínimo de permisos y conceda permisos adicionales según sea necesario. Por lo general, es más seguro que comenzar con permisos demasiado tolerantes e intentar hacerlos más estrictos más adelante. Para obtener más información, consulte [Conceder privilegios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) en la *Guía del usuario de IAM*.
+ **Habilitar MFA para operaciones confidenciales**: para mayor seguridad, obligue a los usuarios de que utilicen la autenticación multifactor (MFA) para acceder a recursos u operaciones de API confidenciales. Para obtener más información, consulte [Uso de la autenticación multifactor (MFA) en AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) en la *Guía del usuario de IAM*.
+ **Utilizar condiciones de política para mayor seguridad**: en la medida en que sea práctico, defina las condiciones en las que sus políticas basadas en identidad permitan el acceso a un recurso. Por ejemplo, puede escribir condiciones para especificar un rango de direcciones IP permitidas desde el que debe proceder una solicitud. También puede escribir condiciones para permitir solicitudes solo en un intervalo de hora o fecha especificado o para solicitar el uso de SSL o MFA. Para obtener más información, consulte [Elementos de la política JSON de IAM: condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
# Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se adjuntan a la identidad de sus usuarios. Esta política incluye permisos para completar esta acción en la consola o mediante programación mediante la AWS CLI API o. 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 administradas por Amazon EMR
La forma más sencilla de conceder acceso completo o acceso de solo lectura a las acciones de Amazon EMR requeridas consiste en utilizar las políticas administradas de IAM para Amazon EMR. Las políticas administradas ofrecen el beneficio de que se actualizan automáticamente si cambian los requisitos de permisos. Si utiliza políticas insertadas, pueden producirse cambios en los servicios que provoquen la aparición de errores de permisos.
Amazon EMR dejará de utilizar las políticas administradas existentes (políticas de la versión 1) en favor de las nuevas políticas administradas (políticas de la versión 2). Se ha reducido el alcance de las nuevas políticas gestionadas para alinearlas con las mejores prácticas. AWS Una vez que las políticas administradas de la versión 1 estén obsoletas, no podrá adjuntarlas a ningún rol o usuario de IAM nuevo. Los roles y usuarios existentes que usan políticas obsoletas pueden seguir usándolas. Las políticas administradas de la versión 2 restringen el acceso mediante etiquetas. Solo permiten acciones específicas de Amazon EMR y requieren recursos de clúster etiquetados con una clave específica de EMR. Le recomendamos que revise detenidamente la documentación antes de utilizar las nuevas políticas de la versión 2.
Las políticas de la versión 1 se marcarán como obsoletas con un icono de advertencia a su lado en la lista **Políticas** de la consola de IAM. Las políticas obsoletas tienen las siguientes características:
+ Siguen funcionando para todos los usuarios, grupos y roles asociados en ese momento. Ningún elemento deja de funcionar.
+ No pueden asociarse a ningún usuario, grupo o rol nuevo. Si separa una política de una entidad actual, no puede volver a asociarla.
+ Después de separar una política de la versión 1 de todas las entidades actuales, la política dejará de estar visible y ya no podrá utilizarse.
La siguiente tabla resume los cambios entre las políticas actuales (versión 1) y las políticas de la versión 2.
**Cambios en las políticas administradas por Amazon EMR**
| Tipo de política | Nombres de las políticas | Propósito de la política | Cambios en la política de la versión 2 |
| --- | --- | --- | --- |
| Rol de servicio de EMR predeterminado y política administrada adjunta | **Nombre del rol: EMR\$1 DefaultRole** Política V1 (quedará obsoleta): **AmazonElasticMapReduceRole**(Rol de servicio EMR) Nombre de la política de la versión 2 (con ámbito de aplicación reducido): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Permite a Amazon EMR llamar a otros AWS servicios en su nombre al aprovisionar recursos y realizar acciones a nivel de servicio. Este rol es necesario para todos los clústeres. | La política añade el nuevo permiso `"ec2:DescribeInstanceTypeOfferings"`. Esta operación de API devuelve una lista de tipos de instancias compatibles con una lista de zonas de disponibilidad determinadas. |
| Política administrada por IAM para un acceso integral a Amazon EMR por parte del usuario, rol o grupo asociado | Nombre de la política de la versión 2 (con ámbito de aplicación): [`AmazonEMRServicePolicy_v2`](emr-managed-policy-fullaccess-v2.md) | Concede a los usuarios permisos completos para realizar acciones de EMR. Incluye iam: permisos para recursos. PassRole | La política agrega un requisito previo según el cual los usuarios deben agregar etiquetas de usuario a los recursos antes de poder usar esta política. Consulte [Etiquetado de recursos para usar políticas administradas](#manually-tagged-resources). iam: la PassRole acción requiere la PassedToService condición iam: establecida en el servicio especificado. El acceso a Amazon EC2, Amazon S3 y otros servicios no está permitido de forma predeterminada. Consulte [Política administrada por IAM para un acceso total (política predeterminada administrada de la versión 2)](emr-managed-policy-fullaccess-v2.md). |
| Política administrada por IAM para el acceso de solo lectura por parte del usuario, rol o grupo asociado | Política de la versión 1 (quedará obsoleta): [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md) Nombre de la política de la versión 2 (con ámbito de aplicación): [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md) | Concede a los usuarios permisos de solo lectura para realizar acciones de Amazon EMR. | Los permisos permiten únicamente acciones específicas de solo lectura de elasticmapreduce. El acceso a Amazon S3 no está permitido de forma predeterminada. Consulte [Política administrada por IAM para un acceso de solo lectura (política predeterminada administrada de la versión 2)](emr-managed-policy-readonly-v2.md). |
| Rol de servicio de EMR predeterminado y política administrada adjunta | **Nombre del rol: EMR\$1 DefaultRole** Política V1 (quedará obsoleta): **AmazonElasticMapReduceRole**(Rol de servicio EMR) Nombre de la política de la versión 2 (con ámbito de aplicación reducido): [`AmazonEMRServicePolicy_v2`](emr-iam-role.md) | Permite a Amazon EMR llamar a otros AWS servicios en su nombre al aprovisionar recursos y realizar acciones a nivel de servicio. Este rol es necesario para todos los clústeres. | El rol de servicio de la versión 2 y la política predeterminada de la versión 2 sustituyen a la política y al rol obsoletos. La política agrega un requisito previo según el cual los usuarios deben agregar etiquetas de usuario a los recursos antes de poder usar esta política. Consulte [Etiquetado de recursos para usar políticas administradas](#manually-tagged-resources). Consulte [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md). |
| Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2) | **Nombre del rol: EMR\$1 \$1 EC2 DefaultRole** **Nombre de la política obsoleta: Role AmazonElasticMapReducefor EC2** | Permite que las aplicaciones que se ejecutan en un clúster de EMR accedan a otros recursos de AWS , como Amazon S3. Por ejemplo, si ejecuta trabajos de Apache Spark que procesan datos de Amazon S3, la política debe permitir el acceso a dichos recursos. | Tanto el rol predeterminado como la política predeterminada están en vías de quedar obsoletos. No hay ninguna política o función gestionada AWS predeterminada que la sustituya. Debe proporcionar una política basada en los recursos o en la identidad. Esto significa que, de forma predeterminada, las aplicaciones que se ejecuten en un clúster de EMR no tienen acceso a Amazon S3 ni a ningún otro recurso, a menos que las agregue manualmente a la política. Consulte [Política administrada y rol predeterminados](emr-iam-role-for-ec2.md#emr-ec2-role-default). |
| Otras políticas de rol de servicio de EC2 | Nombres de políticas actuales: **AmazonElasticMapReduceforAutoScalingRole, AmazonElasticMapReduceEditorsRole, Amazon EMRCleanup Policy** | Proporciona los permisos que Amazon EMR necesita para acceder a otros recursos de AWS y realizar acciones si utiliza el escalado automático, y los cuadernos, o bien para limpiar los recursos de EC2. | No hay cambios para la versión 2. |
## Objetivo de aseguramiento: PassRole
Las políticas administradas de forma predeterminada con todos los permisos de Amazon EMR incorporan configuraciones de seguridad `iam:PassRole`, entre las que se incluyen las siguientes:
+ Permisos `iam:PassRole` solo para roles específicos de Amazon EMR predeterminados.
+ `iam:PassedToService`condiciones que le permiten usar la política solo con AWS servicios específicos, como `elasticmapreduce.amazonaws.com` y`ec2.amazonaws.com`.
Puede ver la versión JSON de las políticas [Amazon EMRFull AccessPolicy \$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) y [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) en la consola de IAM. Le recomendamos crear nuevos clústeres con las políticas administradas de la versión 2.
Para crear políticas personalizadas, le recomendamos que comience a partir de las políticas administradas y las edite de acuerdo con sus requisitos.
Para obtener información sobre cómo asociar políticas a los usuarios (entidades principales), consulte [Uso de políticas administradas con la Consola de administración de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#policies_using-managed-console) en la *Guía del usuario de IAM*.
## Etiquetado de recursos para usar políticas administradas
**Amazon EMRService Policy\$1v2** y **Amazon EMRFull AccessPolicy \$1v2** dependen del acceso limitado a los recursos que Amazon EMR aprovisiona o utiliza. La reducción del alcance se logra restringiendo el acceso únicamente a los recursos que tienen una etiqueta de usuario predefinida asociada a ellos. Si utiliza cualquiera de estas dos políticas, debe pasar la etiqueta de usuario predefinida `for-use-with-amazon-emr-managed-policies = true` al aprovisionar el clúster. A continuación, Amazon EMR propagará automáticamente esa etiqueta. Además, debe agregar una etiqueta de usuario a los recursos que se enumeran en la siguiente sección. Si utiliza la consola de Amazon EMR para lanzar el clúster, consulte [Consideraciones sobre el uso de la consola de Amazon EMR para lanzar clústeres con políticas administradas de la versión 2](#emr-cluster-v2policy-awsconsole-launch).
Para usar políticas administradas, pase la etiqueta de usuario `for-use-with-amazon-emr-managed-policies = true` al aprovisionar un clúster con la CLI, el SDK u otro método.
Al pasar la etiqueta, Amazon EMR la propaga a los volúmenes de EBS, las instancias de EC2 y las ENI de subred privada que cree. Amazon EMR también etiqueta automáticamente los grupos de seguridad que cree. Sin embargo, si desea que Amazon EMR se lance con un grupo de seguridad determinado, debe etiquetarlo. En el caso de los recursos que no haya creado Amazon EMR, debe agregar etiquetas a esos recursos. Por ejemplo, debe etiquetar las subredes de Amazon EC2, los grupos de seguridad de EC2 (si no los creó Amazon EMR) y (si VPCs desea que Amazon EMR cree grupos de seguridad). Para lanzar clústeres con políticas administradas en la versión 2 VPCs, debe etiquetarlos VPCs con la etiqueta de usuario predefinida. Consulte, [Consideraciones sobre el uso de la consola de Amazon EMR para lanzar clústeres con políticas administradas de la versión 2](#emr-cluster-v2policy-awsconsole-launch).
**Etiquetado propagado especificado por el usuario**
Amazon EMR etiqueta los recursos que crea mediante las etiquetas de Amazon EMR que especifique al crear un clúster. Amazon EMR aplica etiquetas a los recursos que cree durante la vida útil del clúster.
Amazon EMR propaga las etiquetas de usuario de los siguientes recursos:
+ ENI de Subred privada (interfaces de red elásticas de acceso a servicios)
+ Instancias de EC2
+ Volúmenes de EBS
+ Plantillas de lanzamiento de EC2
**Grupos de seguridad etiquetados automáticamente**
Amazon EMR etiqueta los grupos de seguridad de EC2 que cree con la etiqueta necesaria para las políticas administradas de la versión 2 de Amazon EMR, `for-use-with-amazon-emr-managed-policies`, independientemente de las etiquetas que especifique en el comando create cluster. En el caso de un grupo de seguridad que se creó antes de la introducción de las políticas administradas de la versión 2, Amazon EMR no etiqueta automáticamente el grupo de seguridad. Si desea utilizar políticas administradas de la versión 2 con los grupos de seguridad predeterminados que ya existen en la cuenta, debe etiquetar los grupos de seguridad manualmente con `for-use-with-amazon-emr-managed-policies = true`.
**Recursos de clúster etiquetados manualmente**
Debe etiquetar manualmente algunos recursos del clúster para que los roles predeterminados de Amazon EMR puedan acceder a ellos.
+ Debe etiquetar manualmente los grupos de seguridad de EC2 y las subredes de EC2 con la etiqueta de política administrada de Amazon EMR `for-use-with-amazon-emr-managed-policies`.
+ Debe etiquetar manualmente una VPC si quiere que Amazon EMR cree grupos de seguridad predeterminados. EMR intentará crear un grupo de seguridad con la etiqueta específica si el grupo de seguridad predeterminado aún no existe.
Amazon EMR etiqueta automáticamente los siguientes recursos:
+ Grupos de seguridad de EC2 creados por EMR
Debe etiquetar de forma manual los siguientes recursos:
+ Subred de EC2
+ Grupos de seguridad de la EC2
De forma opcional, puede etiquetar de forma manual los siguientes recursos:
+ VPC: solo cuando desee que Amazon EMR cree grupos de seguridad
## Consideraciones sobre el uso de la consola de Amazon EMR para lanzar clústeres con políticas administradas de la versión 2
Puede aprovisionar clústeres con políticas administradas de la versión 2 mediante la consola de Amazon EMR. Estas son algunas consideraciones que debe tener en cuenta al utilizar la consola para lanzar clústeres de Amazon EMR.
+ No es necesario pasar la etiqueta predefinida. Amazon EMR agrega automáticamente la etiqueta y la propaga a los componentes correspondientes.
+ En el caso de los componentes que deben etiquetarse manualmente, la antigua consola de Amazon EMR intenta etiquetarlos automáticamente si tiene los permisos necesarios para etiquetar los recursos. Si no tiene los permisos para etiquetar los recursos o si desea utilizar la consola, pida al administrador que etiquete esos recursos.
+ No puede lanzar clústeres con políticas administradas de la versión 2, a menos que se cumplan todos los requisitos previos.
+ La consola antigua de Amazon EMR le muestra qué recursos (VPC/subredes) deben etiquetarse.
# Política administrada por IAM para un acceso total (política predeterminada administrada de la versión 2) para Amazon EMR
Las políticas administradas por defecto de EMR con el ámbito de aplicación de la versión 2 otorgan privilegios de acceso específicos a los usuarios. Requieren una etiqueta de recurso de Amazon EMR predefinida y claves de condición de `iam:PassRole` para los recursos que utiliza Amazon EMR, como la `Subnet` y el `SecurityGroup` que utiliza para lanzar el clúster.
Para conceder todas las acciones necesarias dentro del ámbito de aplicación de Amazon EMR, adjunte la política administrada `AmazonEMRFullAccessPolicy_v2`. Esta política administrada predeterminada actualizada sustituye a la política administrada [`AmazonElasticMapReduceFullAccess`](emr-managed-policy-fullaccess.md).
`AmazonEMRFullAccessPolicy_v2` depende del acceso limitado a los recursos que Amazon EMR aprovisiona o utiliza. Cuando utilice esta política, tendrá que pasar la etiqueta de usuario `for-use-with-amazon-emr-managed-policies = true` al aprovisionar el clúster. Amazon EMR propagará automáticamente la etiqueta. Además, es posible que tenga que agregar manualmente una etiqueta de usuario a tipos específicos de recursos, como grupos de seguridad de EC2 que no fueron creados por Amazon EMR. Para obtener más información, consulte [Etiquetado de recursos para usar políticas administradas](emr-managed-iam-policies.md#manually-tagged-resources).
La 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 los recursos de la siguiente manera:
+ Requiere que los recursos se etiqueten con la etiqueta de políticas administradas de Amazon EMR predefinida `for-use-with-amazon-emr-managed-policies` para la creación de clústeres y el acceso a Amazon EMR.
+ Restringe la acción `iam:PassRole` a roles predeterminados específicos y el acceso `iam:PassedToService` a servicios específicos.
+ Ya no proporciona acceso a Amazon EC2, Amazon S3 ni otros servicios de forma predeterminada.
El contenido de esta política se muestra a continuación.
**nota**
También puede utilizar el enlace de la consola [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 ver esta 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 administrada por IAM para obtener acceso completo (en vías de quedar obsoleta)
Las políticas gestionadas `AmazonElasticMapReduceFullAccess` y `AmazonEMRFullAccessPolicy_v2` AWS Identity and Access Management (IAM) otorgan todas las acciones necesarias para Amazon EMR y otros servicios.
**importante**
La política administrada `AmazonElasticMapReduceFullAccess` está en vías de quedar obsoleta y ya no se recomienda su uso con Amazon EMR. En su lugar, utilice [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md). Cuando el servicio de IAM haga que la política de la versión 1 quede obsoleta, ya no podrá asociarla a ningún rol. Sin embargo, puede adjuntar un rol existente a un clúster incluso si ese rol usa la política obsoleta.
Las políticas administradas de forma predeterminada con todos los permisos de Amazon EMR incorporan configuraciones de seguridad `iam:PassRole`, entre las que se incluyen las siguientes:
+ Permisos `iam:PassRole` solo para roles específicos de Amazon EMR predeterminados.
+ `iam:PassedToService`condiciones que le permiten usar la política solo con AWS servicios específicos, como `elasticmapreduce.amazonaws.com` y. `ec2.amazonaws.com`
Puede ver la versión JSON de las políticas [Amazon EMRFull AccessPolicy \$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRFullAccessPolicy_v2) y [Amazon EMRService Policy\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) en la consola de IAM. Le recomendamos crear nuevos clústeres con las políticas administradas de la versión 2.
Puede ver el contenido de la política de la versión 1, que está obsoleta, en at. Consola de administración de 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) La acción `ec2:TerminateInstances` de la política otorga permiso a un usuario o rol para cancelar cualquiera de las instancias de Amazon EC2 asociadas a la cuenta de IAM. Esto incluye instancias que no forman parte de un clúster de EMR.
# Política administrada por IAM para el acceso de solo lectura (política predeterminada administrada de la versión 2) para Amazon EMR
Para conceder privilegios de solo lectura a Amazon EMR, adjunte la política gestionada **Amazon EMRRead OnlyAccessPolicy** \$1v2. Esta política administrada predeterminada reemplaza a la política administrada [`AmazonElasticMapReduceReadOnlyAccess`](emr-managed-policy-readonly.md). El contenido de esta instrucción de la política se muestra en el siguiente fragmento: En comparación con la política `AmazonElasticMapReduceReadOnlyAccess`, la política `AmazonEMRReadOnlyAccessPolicy_v2` no utiliza caracteres comodín para el elemento `elasticmapreduce`. En su lugar, la política de la versión 2 predeterminada determina el ámbito de aplicación de las acciones `elasticmapreduce` permitidas.
**nota**
También puede utilizar el Consola de administración de AWS enlace para ver la política [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).
------
#### [ 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 administrada por IAM para obtener acceso de solo lecturas (en vías de quedar obsoleta)
La política administrada `AmazonElasticMapReduceReadOnlyAccess` está en vías de quedar obsoleta. No puede adjuntar esta política al lanzar nuevos clústeres. `AmazonElasticMapReduceReadOnlyAccess` se ha sustituido por [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md), que ahora es la política administrada predeterminada de Amazon EMR. El contenido de esta instrucción de la política se muestra en el siguiente fragmento: Los caracteres comodín para el elemento `elasticmapreduce` especifican que solo se permiten las acciones que empiezan por las cadenas especificadas. Tenga en cuenta que, dado que esta política no deniega acciones explícitamente, se puede seguir utilizando una instrucción de política distinta para otorgar acceso a acciones especificadas.
**nota**
También puede utilizar el Consola de administración de AWS para ver la 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 gestionada: EMRDescribe ClusterPolicyFor EMRAL
No puede asociar `EMRDescribeClusterPolicyForEMRWAL` a sus entidades IAM. Esta política está adjunta a un rol vinculado a servicios que permite a Amazon EMR realizar acciones en su nombre. Para obtener más información sobre este rol vinculado a servicios, consulte [Uso de roles vinculados a servicios con Amazon EMR para el registro de escritura anticipada](using-service-linked-roles-wal.md).
Esta política concede permisos de solo lectura que permiten al servicio WAL de Amazon EMR encontrar y devolver el estado de un clúster. Para obtener más información sobre Amazon EMR WAL, consulte [Registros de escritura anticipada (WAL) para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hbase-wal.html).
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `emr` – Permite a las entidades principales describir el estado de clúster de Amazon EMR. Esto es necesario para que Amazon EMR pueda confirmar la finalización de un clúster y, después de treinta días, limpiar todos los registros de WAL que haya dejado el clúster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:DescribeCluster"
],
"Resource": [
"*"
],
"Sid": "AllowELASTICMAPREDUCEDescribecluster"
}
]
}
```
------
## AWS políticas gestionadas para Amazon EMR
Una política AWS administrada es una política independiente creada y administrada por. AWS AWS Las políticas administradas están diseñadas para proporcionar permisos para muchos casos de uso comunes, de modo que pueda empezar a asignar permisos a usuarios, grupos y funciones.
Ten en cuenta que es posible que las políticas AWS administradas no otorguen permisos con privilegios mínimos para tus casos de uso específicos, ya que están disponibles para que los usen todos los AWS clientes. Se recomienda definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) específicas para sus casos de uso a fin de reducir aún más los permisos.
No puedes cambiar los permisos definidos en AWS las políticas administradas. Si AWS actualiza los permisos definidos en una política AWS administrada, la actualización afecta a todas las identidades principales (usuarios, grupos y roles) a las que está asociada la política. AWS es más probable que actualice una política AWS administrada cuando Servicio de AWS se lance una nueva o cuando estén disponibles nuevas operaciones de API para los servicios existentes.
Para obtener más información, consulte [Políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
# Amazon EMR actualiza las políticas gestionadas AWS
Consulte los detalles sobre las actualizaciones de las políticas AWS gestionadas para Amazon EMR desde que este servicio comenzó a realizar el seguimiento de estos cambios.
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): actualización de una política actual | Se agregaron ec2:CreateVpcEndpoint, ec2:ModifyVpcEndpoint y ec2:CreateTags, necesarios para obtener un funcionamiento óptimo a partir de Amazon EMR 7.5.0. | 4 de marzo de 2025 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): actualización de una política actual | También se agregaron elasticmapreduce:CreatePersistentAppUI, elasticmapreduce:DescribePersistentAppUI y elasticmapreduce:GetPersistentAppUIPresignedURL. | 28 de febrero de 2025 |
| [`EMRDescribeClusterPolicyForEMRWAL`](EMRDescribeClusterPolicyForEMRWAL.md): política nueva | Se agregó una nueva política para que Amazon EMR pueda determinar el estado del clúster para la limpieza de WAL treinta días después de la finalización del clúster. | 10 de agosto de 2023 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md) y [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md): actualización de una política existente | Se añadieron elasticmapreduce:DescribeReleaseLabel y elasticmapreduce:GetAutoTerminationPolicy. | 21 de abril de 2022 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): actualización de una política actual | Se agregó ec2:DescribeImages para [Uso de una AMI personalizada para ofrecer más flexibilidad a la configuración del clúster de Amazon EMR](emr-custom-ami.md). | 15 de febrero de 2022 |
| [**Políticas administradas por Amazon EMR**](emr-managed-iam-policies.md) | Se actualizó para aclarar el uso de etiquetas de usuario predefinidas. Se agregó una sección sobre el uso de la AWS consola para lanzar clústeres con políticas administradas en la versión 2. | 29 de septiembre de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): actualización de una política actual | Se modificaron las acciones PassRoleForEC2 y PassRoleForAutoScaling para que usen el operador de condición StringLike y que así coincidan con "iam:PassedToService":"application-autoscaling.amazonaws.com\$1" y "iam:PassedToService":"ec2.amazonaws.com\$1", respectivamente. | 20 de mayo de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): actualización de una política actual | Se ha eliminado la acción no válida `s3:ListBuckets` y se ha sustituido por la acción `s3:ListAllMyBuckets`. Se actualizó la creación de roles vinculados a un servicio (SLR) para que se limite explícitamente al único rol que tiene Amazon EMR con principios de servicio explícitos. Los SLRs que se pueden crear son exactamente los mismos que antes de este cambio. | 23 de marzo de 2021 |
| [`AmazonEMRFullAccessPolicy_v2`](emr-managed-policy-fullaccess-v2.md): política nueva | Amazon EMR ha agregado nuevos permisos para limitar el acceso a los recursos y para agregar un requisito previo según el cual los usuarios deben agregar una etiqueta de usuario predefinida a los recursos antes de poder utilizar las políticas administradas de Amazon EMR. La acción `iam:PassRole` requiere que se establezca una condición `iam:PassedToService` en un servicio específico. El acceso a Amazon EC2, Amazon S3 y otros servicios no está permitido de forma predeterminada. | 11 de marzo de 2021 |
| [`AmazonEMRServicePolicy_v2`](emr-iam-role.md): política nueva | Agrega un requisito previo según el cual los usuarios deben agregar etiquetas de usuario a los recursos antes de poder utilizar esta política. | 11 de marzo de 2021 |
| [`AmazonEMRReadOnlyAccessPolicy_v2`](emr-managed-policy-readonly-v2.md): política nueva | Los permisos permiten únicamente acciones específicas de solo lectura de elasticmapreduce. El acceso a Amazon S3 no está permitido de forma predeterminada. | 11 de marzo de 2021 |
| Amazon EMR ha comenzado a hacer un seguimiento de los cambios | Amazon EMR comenzó a realizar un seguimiento de los cambios de sus políticas AWS gestionadas. | 11 de marzo de 2021 |
# Políticas de IAM para el acceso basado en etiquetas para clústeres y cuadernos de EMR
Puede utilizar condiciones en su política basada en identidades para controlar el acceso a clústeres y blocs de notas de EMR basándose en etiquetas.
Para obtener más información sobre la adición de etiquetas a los clústeres de EMR, consulte [Etiquetado de clústeres de Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-tags.html).
Los siguientes ejemplos muestran distintos supuestos y formas de utilizar los operadores de condición con las claves de condición de Amazon EMR. Estas instrucciones de política de IAM tienen fines demostrativos y no deben utilizarse en entornos de producción. Existen varias maneras de combinar las instrucciones de políticas para conceder y denegar permisos de acuerdo con sus requisitos. Para obtener más información sobre la planificación y las pruebas de políticas de IAM, consulte la [Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**importante**
La denegación de permisos explícita para acciones de etiquetado de acciones es un factor importante. Esto impide que los usuarios etiqueten un recurso y, de esta forma, se concedan a sí mismos permisos que usted no tenía previsto conceder. Si no deniega las acciones de etiquetado de un recurso, el usuario puede modificar las etiquetas y eludir la intención de las políticas basadas en etiquetas.
## Ejemplo de instrucciones de políticas basadas en identidades para clústeres
Los ejemplos que se muestran a continuación muestran las políticas de permisos basadas en identidades que se utilizan para controlar las acciones que se permiten con clústeres de EMR.
**importante**
La acción `ModifyInstanceGroup` en Amazon EMR no requiere que especifique un ID de clúster. Por ese motivo, denegar esta acción en función de las etiquetas de clúster requiere una consideración adicional. Para obtener más información, consulte [Denegar la ModifyInstanceGroup acción en Amazon EMR](emr-cluster-deny-modifyinstancegroup.md).
**Topics**
+ [Permitir acciones solo en clústeres con valores de etiqueta específicos](#emr-cluster-access-example-tagvalue)
+ [Etiquetado obligatorio de un clúster al crear un clúster](#emr-cluster-access-example-require-tagging)
+ [Permitir acciones en clústeres con una etiqueta específica, con independencia del valor de su etiqueta](#emr-cluster-access-example-tag)
### Permitir acciones solo en clústeres con valores de etiqueta específicos
Los ejemplos que aparecen a continuación muestran una política que permite a un usuario realizar acciones en función de la etiqueta de clúster `department` con el valor `dev` y también permite a un usuario etiquetar clústeres con la misma etiqueta. El ejemplo de política muestra cómo denegar los privilegios para etiquetar clústeres de EMR con cualquier otra cosa excepto la misma etiqueta.
En el siguiente ejemplo de política, la condición `StringEquals` intenta hacer coincidir `dev` con el valor de la etiqueta `department`. Si la etiqueta `department` no se ha añadido al clúster o no contiene el valor `dev`, la política no se aplica y esta política no permite las acciones. Si no hay otras instrucciones de política que permitan las acciones, el usuario solo puede trabajar con clústeres que tenga esta etiqueta con este 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"
}
}
}
]
}
```
------
También puede especificar varios valores de etiqueta utilizando un operador de condición. Por ejemplo, a fin de permitir que todas las acciones en clústeres donde la etiqueta `department` contiene el valor `dev` o `test`, podría sustituir el bloque de condición en el ejemplo anterior por los siguientes.
```
"Condition": {
"StringEquals": {
"elasticmapreduce:ResourceTag/department":["dev", "test"]
}
}
```
### Etiquetado obligatorio de un clúster al crear un clúster
Como en el ejemplo anterior, la siguiente política de ejemplo busca la misma etiqueta coincidente: el valor `dev` para la etiqueta `department`. Sin embargo, en este ejemplo, la clave de condición `RequestTag` especifica que la política se aplica durante la creación de la etiqueta. Por lo tanto, debe crear un clúster con una etiqueta que coincida con el valor especificado.
Para crear un clúster con una etiqueta, también debe tener permiso para realizar la acción `elasticmapredue:AddTags`. En esta instrucción, la clave de condición `elasticmapreduce:ResourceTag` garantiza que IAM solo conceda acceso a los recursos de etiquetas con el valor `dev` en la etiqueta `department`. El elemento `Resource` se utiliza para limitar este permiso a los recursos del clúster.
En el caso de `PassRole` los recursos, debe proporcionar el identificador o alias de la AWS cuenta, el nombre de la función de servicio en la `PassRoleForEMR` declaración y el nombre del perfil de la instancia en la `PassRoleForEC2` declaración. Para obtener más información sobre el formato ARN de IAM, [consulte](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) IAM en la Guía *del* usuario de ARNs IAM.
Para obtener más información sobre cómo hacer coincidir los valores de las claves 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) en la *Guía del usuario de 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 acciones en clústeres con una etiqueta específica, con independencia del valor de su etiqueta
También puede permitir acciones solo en clústeres que tengan una etiqueta particular, con independencia del valor de la etiqueta. Para ello, puede utilizar el operador `Null`. Para obtener más información, consulte [Operador de condición para comprobar la existencia de claves de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null) en la *Guía del usuario de IAM*. Por ejemplo, para permitir acciones solo en clústeres de EMR que tengan la etiqueta `department`, con independencia del valor que contenga, podría sustituir los bloques Condition del ejemplo anterior por el siguiente. El operador `Null` buscará la presencia de la etiqueta `department` en un clúster de EMR. Si la etiqueta existe, la instrucción `Null` se evalúa como falsa, ajustándose a la condición especificada en esta instrucción de política y se permiten las acciones adecuadas.
```
1. "Condition": {
2. "Null": {
3. "elasticmapreduce:ResourceTag/department":"false"
4. }
5. }
```
La siguiente instrucción de política permite a un usuario crear un clúster de EMR solo si el clúster tendrá una etiqueta `department`, que puede contener cualquier valor. Para el `PassRole` recurso, debe proporcionar el identificador o alias de la AWS cuenta y el nombre de la función de servicio. Para obtener más información sobre el formato ARN de IAM, [consulte](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) IAM en la Guía *del* usuario de ARNs IAM.
Para obtener más información sobre cómo especificar el operador de condición null (“false”), consulte [Operador de condición para comprobar la existencia de claves de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null) en la *Guía del usuario de 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*"
}
}
}
]
}
```
------
## Ejemplo de instrucciones de políticas basadas en identidades para Cuadernos de Amazon EMR
Las instrucciones de políticas de IAM de ejemplo de esta sección muestran escenarios comunes del uso de claves para limitar las acciones permitidas mediante Cuadernos de Amazon EMR. Siempre que no haya ninguna otra política asociada a la entidad principal (usuario) que permita las acciones, las claves de contexto de condición limitan las acciones permitidas tal como se indica.
**Example : permitir el acceso únicamente a Cuadernos de Amazon EMR que un usuario cree en función del etiquetado**
La instrucción de política de ejemplo mostrada a continuación, cuando se asocia a un rol o a un usuario, permite al usuario trabajar solamente con los cuadernos que haya creado. Esta instrucción de política utiliza la etiqueta predeterminada que se aplica al crear un bloc de notas.
En el ejemplo, el operador de condición `StringEquals` intenta emparejar una variable que representa el ID de usuario del usuario actual (`{aws:userId}`) con el valor de la etiqueta `creatorUserID`. Si la etiqueta `creatorUserID` no se ha añadido al bloc de notas o no contiene el valor del ID del usuario actual, la política no se aplica y esta política no permite las acciones. Si no hay otras instrucciones de política que permitan las acciones, el usuario solo puede trabajar con blocs de notas que tengan este valor para esta etiqueta.
****
```
{
"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 — Etiquetado de cuadernos obligatorio al crearlos**
En este ejemplo, se utiliza la clave de contexto `RequestTag`. La acción `CreateEditor` solo se permite si el usuario no cambia ni elimina la etiqueta `creatorUserID` que se añade de forma predeterminada. La variable \$1\$1aws:userId\$1, especifica el ID de usuario del usuario activo actualmente, que es el valor predeterminado de la etiqueta.
La instrucción de política se puede utilizar para ayudar a garantizar que los usuarios no eliminan la etiqueta `createUserId` ni cambian su valor.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"elasticmapreduce:CreateEditor"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"elasticmapreduce:RequestTag/creatorUserId": "${aws:userid}"
}
},
"Sid": "AllowELASTICMAPREDUCECreateeditor"
}
]
}
```
Este ejemplo requiere que el usuario cree el clúster con una etiqueta que tenga la cadena de clave `dept` establecida en uno de los siguientes valores: `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 — Limitación de la creación de cuadernos a clústeres etiquetados y etiquetas de cuadernos obligatorias**
Este ejemplo permite la creación de blocs de notas solo si el bloc de notas se crea con una etiqueta que tiene la cadena de clave `owner` establecida en uno de los valores especificados. Además, el bloc de notas solo se puede crear si el clúster tiene una etiqueta con la cadena de clave `department` establecida en uno de los 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 — Limitación de la capacidad de iniciar un cuaderno en función de las etiquetas**
Este ejemplo limita la capacidad de iniciar blocs de notas únicamente a aquellos blocs de notas que tienen una etiqueta con la cadena de clave `owner` establecida en uno de los valores especificados. Debido a que el elemento `Resource` se utiliza solo para especificar el valor `editor`, la condición no se aplica al clúster y no es necesario etiquetarlo.
****
```
{
"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 ejemplo es similar a uno anterior. Sin embargo, el límite solo se aplica a los clústeres etiquetados, no a los blocs de notas.
****
```
{
"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"
}
]
}
```
En este ejemplo, se utiliza un conjunto diferente de etiquetas de bloc de notas y de clúster. Permite el inicio de un bloc de notas solo si:
+ El bloc de notas tiene una etiqueta con la cadena de clave `owner` establecida en cualquiera de los valores especificados
—y—
+ El clúster tiene una etiqueta con la cadena de clave `department` establecida en cualquiera de los 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 — Limitación de la capacidad de abrir el editor de cuadernos en función de las etiquetas**
En este ejemplo, se permite la apertura del editor de blocs de notas solo si:
+ El bloc de notas tiene una etiqueta con la cadena de clave `owner` establecida en cualquiera de los valores especificados.
—y—
+ El clúster tiene una etiqueta con la cadena de clave `department` establecida en cualquiera de los 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"
}
]
}
```
# Denegar la ModifyInstanceGroup acción en Amazon EMR
La [ModifyInstanceGroups](https://docs.aws.amazon.com/emr/latest/APIReference/API_ModifyInstanceGroups.html)acción en Amazon EMR no requiere que proporcione un ID de clúster junto con la acción. En su lugar, puede especificar solo un ID de grupo de instancias. Por este motivo, es posible que una política de denegación aparentemente simple para esta acción basada en el ID de clúster o en una etiqueta de clúster no tenga el efecto deseado. Considere la política de ejemplo siguiente.
------
#### [ 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"
}
]
}
```
------
Si un usuario con esta política adjunta realiza una acción `ModifyInstanceGroup` y especifica solo el ID del grupo de instancias, la política no se aplica. Como la acción está permitida en todos los demás recursos, se realiza correctamente.
Una solución a este problema consiste en adjuntar a la identidad una declaración de política que utilice un [NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html)elemento para denegar cualquier `ModifyInstanceGroup` acción realizada sin un ID de clúster. El siguiente ejemplo de política agrega una declaración de denegación de este tipo para que cualquier solicitud `ModifyInstanceGroups` falle, a menos que se especifique un ID de clúster. Como una identidad debe especificar un ID de clúster con la acción, las instrucciones de denegación basadas en el ID de clúster son, por lo tanto, eficaces.
------
#### [ 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"
}
]
}
```
------
Se produce un problema similar cuando se quiere denegar la acción `ModifyInstanceGroups` en función del valor asociado a una etiqueta de clúster. La solución es similar. Además de una sentencia de denegación que especifique el valor de la etiqueta, puede agregar una declaración de política que deniegue la acción `ModifyInstanceGroup` si la etiqueta que ha especificado no está presente, independientemente del valor.
El siguiente ejemplo muestra una política que, cuando se adjunta a una identidad, niega la identidad de la acción `ModifyInstanceGroups` a cualquier clúster con la etiqueta `department` establecida en `dev`. Esta declaración solo es efectiva debido a la declaración de denegación, que utiliza la condición `StringNotLike` para denegar la acción, a menos que la etiqueta `department` esté 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"
}
]
}
```
------
# Solución de problemas de identidad y acceso de Amazon EMR
Utilice la siguiente información para diagnosticar y solucionar los problemas habituales que pueden surgir cuando se trabaja con Amazon EMR e IAM.
**Topics**
+ [No tengo autorización para realizar una acción en Amazon EMR](#security_iam_troubleshoot-no-permissions)
+ [No estoy autorizado a realizar lo siguiente: PassRole](#security_iam_troubleshoot-passrole)
+ [Quiero permitir que personas ajenas a mi AWS cuenta accedan a mis recursos de Amazon EMR](#security_iam_troubleshoot-cross-account-access)
## No tengo autorización para realizar una acción en Amazon EMR
Si Consola de administración de AWS le indica que no está autorizado a realizar una acción, debe ponerse en contacto con su administrador para obtener ayuda. El administrador es la persona que le facilitó el nombre de usuario y la contraseña.
En el siguiente ejemplo, el error se produce cuando el usuario `mateojackson` intenta utilizar la consola para consultar los detalles acerca de un recurso ficticio `my-example-widget`, pero no tiene los permisos ficticios `EMR:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: EMR:GetWidget on resource: my-example-widget
```
En este caso, Mateo pide a su administrador que actualice sus políticas de forma que pueda obtener acceso al recurso `my-example-widget` mediante la acción `EMR:GetWidget`.
## No estoy autorizado a realizar lo siguiente: PassRole
Si recibe un error que indica que no tiene autorización para llevar a cabo la acción `iam:PassRole`, las políticas se deben actualizar para permitirle pasar un rol a Amazon EMR.
Algunas Servicios de AWS permiten transferir una función existente a ese servicio en lugar de crear una nueva función de servicio o una función vinculada a un servicio. Para ello, debe tener permisos para transferir la función al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en Amazon EMR. Sin embargo, la acción requiere que el servicio cuente con permisos que otorguen un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, las políticas de Mary se deben actualizar para permitirle realizar la acción `iam:PassRole`.
Si necesita ayuda, póngase en contacto con su AWS administrador. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## Quiero permitir que personas ajenas a mi AWS cuenta accedan a mis recursos de Amazon EMR
Se puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que admiten políticas basadas en recursos o listas de control de acceso (ACLs), puede utilizar esas políticas para permitir que las personas accedan a sus recursos.
Para obtener más información, consulte lo siguiente:
+ Para saber si Amazon EMR admite estas características, consulte [Cómo funciona Amazon EMR con IAM](security_iam_service-with-iam.md).
+ Para obtener información sobre cómo proporcionar acceso a los recursos de su Cuentas de AWS propiedad, consulte [Proporcionar acceso a un usuario de IAM en otro de su propiedad en la Cuenta de AWS Guía del usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) de *IAM*.
+ Para obtener información sobre cómo proporcionar acceso a tus recursos a terceros Cuentas de AWS, consulta Cómo [proporcionar acceso a recursos que Cuentas de AWS son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la Guía del usuario de *IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para conocer sobre la diferencia entre las políticas basadas en roles y en recursos para el acceso entre cuentas, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
# Uso de Amazon S3 Access Grants con Amazon EMR
## Información general de S3 Access Grants para Amazon EMR
Con las versiones 6.15.0 y posteriores de Amazon EMR, Amazon S3 Access Grants proporciona una solución de control de acceso escalable que puede utilizar para aumentar el acceso a los datos de Amazon S3 desde Amazon EMR. Si cuenta con una configuración de permisos compleja o amplia de datos de S3, puede utilizar las concesiones de acceso a fin de escalar los permisos de datos de S3 para usuarios, grupos, roles y aplicaciones de un clúster.
Utilice S3 Access Grants para incrementar el acceso a los datos de Amazon S3, más allá de los permisos que conceden el rol de tiempo de ejecución o los roles de IAM asociados a las identidades con acceso al clúster de EMR. Para obtener más información, consulte [Administración del acceso con S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) en la *Guía del usuario de Amazon S3*.
Para conocer los pasos para utilizar S3 Access Grants con otras implementaciones de Amazon EMR, consulte la siguiente documentación:
+ [Uso de S3 Access Grants con Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Uso de S3 Access Grants con Amazon EMR sin servidor](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
## Cómo funciona Amazon EMR con S3 Access Grants
Las versiones 6.15.0 y posteriores de Amazon EMR proporcionan una integración nativa con S3 Access Grants. Puede habilitar S3 Access Grants en Amazon EMR y ejecutar trabajos de Spark. Cuando un trabajo de Spark solicita datos de S3, Amazon S3 proporciona credenciales temporales que se limitan al bucket, al prefijo o al objeto.
A continuación, se ofrece información general de alto nivel sobre cómo Amazon EMR obtiene acceso a los datos protegidos por S3 Access Grants.
![\[Cómo funciona Amazon EMR con S3 Access Grants\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/access-grants-overview.png)
1. Un usuario envía un trabajo de Spark de Amazon EMR que utiliza datos almacenados en Amazon S3.
1. Amazon EMR solicita a S3 Access Grants que permita el acceso al bucket, al prefijo o al objeto en nombre de ese usuario.
1. Amazon S3 devuelve credenciales temporales en forma de token AWS Security Token Service (STS) para el usuario. El token tiene el alcance para acceder al bucket, al prefijo o al objeto de S3.
1. Amazon EMR utiliza el token de STS para recuperar datos de S3.
1. Amazon EMR recibe los datos de S3 y devuelve los resultados al usuario.
## Consideraciones sobre el uso de S3 Access Grants con Amazon EMR
Tenga en cuenta los siguientes comportamientos y limitaciones cuando utilice S3 Access Grants con Amazon EMR.
### Compatibilidad de características
+ S3 Access Grants es compatible con las versiones 6.15.0 y posteriores de Amazon EMR.
+ Spark es el único motor de consultas compatible cuando se utiliza S3 Access Grants con Amazon EMR.
+ Delta Lake y Hudi son los únicos formatos de tabla abierta compatibles cuando se utiliza S3 Access Grants con Amazon EMR.
+ Las siguientes capacidades de Amazon EMR no son compatibles para su uso con S3 Access Grants:
+ Tablas de Apache Iceberg
+ Autenticación nativa de LDAP
+ Autenticación nativa de Apache Ranger
+ AWS CLI solicitudes a Amazon S3 que utilizan funciones de IAM
+ Acceso a S3 mediante el protocolo de código abierto de S3A
+ La opción `fallbackToIAM` no es compatible con los clústeres de EMR que utilizan la propagación de identidades de confianza con IAM Identity Center.
+ [S3 Access Grants con AWS Lake Formation](#emr-access-grants-lf) solo es compatible con los clústeres de Amazon EMR que se ejecutan en Amazon EC2.
### Consideraciones sobre el comportamiento
+ La integración nativa de Apache Ranger con Amazon EMR incluye una funcionalidad congruente con S3 Access Grants como parte del complemento Apache Ranger S3 de EMRFS. Si utiliza Apache Ranger para un control de acceso detallado (FGAC), recomendamos utilizar ese complemento en lugar de S3 Access Grants.
+ Amazon EMR proporciona una caché de credenciales en EMRFS para garantizar que un usuario no necesite realizar solicitudes repetidas de las mismas credenciales en un trabajo de Spark. Por lo tanto, Amazon EMR siempre solicita el privilegio de nivel predeterminado cuando solicita credenciales. Para obtener más información, consulte [Solicitud de acceso a datos de S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants-credentials.html) en la *Guía del usuario de Amazon S3*.
+ En el caso de que un usuario realice una acción que no sea compatible con S3 Access Grants, Amazon EMR está configurado para utilizar el rol de IAM que se especificó para la ejecución del trabajo. Para obtener más información, consulte [Alternativa de roles de IAM](#emr-access-grants-fallback).
## Lanzamiento de un clúster de Amazon EMR con S3 Access Grants
En esta sección, se describe cómo lanzar un clúster de EMR que se ejecute en Amazon EC2 y utilice S3 Access Grants para administrar el acceso a los datos en Amazon S3. Para conocer los pasos para utilizar S3 Access Grants con otras implementaciones de Amazon EMR, consulte la siguiente documentación:
+ [Uso de S3 Access Grants con Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/access-grants.html)
+ [Uso de S3 Access Grants con EMR sin servidor](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/access-grants.html)
Realice los siguientes pasos a fin de lanzar un clúster de EMR que se ejecute en Amazon EC2 y utilice S3 Access Grants para administrar el acceso a los datos en Amazon S3.
1. Configure un rol de ejecución de trabajos para el clúster de EMR. Incluya los permisos de IAM necesarios para ejecutar los trabajos de Spark, `s3:GetDataAccess` y `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**
Con Amazon EMR, S3 Access Grants aumenta los permisos que se configuran en los roles de IAM. Si los roles de IAM que especifica para la ejecución de trabajos contienen permisos para acceder directamente a S3, es posible que los usuarios puedan acceder a más datos además de los que usted define en S3 Access Grants.
1. A continuación, utilice AWS CLI para crear un clúster con Amazon EMR 6.15 o superior y la `emrfs-site` clasificación para habilitar S3 Access Grants, similar al ejemplo siguiente:
```
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"}}]'
```
## S3 Access Grants con AWS Lake Formation
Si utiliza Amazon EMR con la [integración de AWS Lake Formation](emr-lake-formation.md), puede utilizar Amazon S3 Access Grants para el acceso directo o tabular a los datos de Amazon S3.
**nota**
S3 Access Grants with solo AWS Lake Formation es compatible con los clústeres de Amazon EMR que se ejecutan en Amazon EC2.
**Acceso directo**
El acceso directo implica todas las llamadas para acceder a los datos de S3 que no invoquen la API del servicio AWS Glue que Lake Formation utiliza como metaalmacén con Amazon EMR, por ejemplo, para llamar a: `spark.read`
```
spark.read.csv("s3://...")
```
Cuando utiliza S3 Access Grants con AWS Lake Formation Amazon EMR, todos los patrones de acceso directo pasan por S3 Access Grants para obtener credenciales de S3 temporales.
**Acceso tabular**
El acceso tabular se produce cuando Lake Formation invoca la API del almacén de metadatos para acceder a su ubicación de S3, por ejemplo, para consultar datos de tablas:
```
spark.sql("select * from test_tbl")
```
Cuando utiliza S3 Access Grants con AWS Lake Formation Amazon EMR, todos los patrones de acceso tabulares pasan por Lake Formation.
## Alternativa de roles de IAM
Si un usuario intenta realizar una acción que no es compatible con S3 Access Grants, Amazon EMR está configurado para utilizar de forma predeterminada el rol de IAM que se especificó para la ejecución de trabajos cuando la configuración `fallbackToIAM` es `true`. Esto permite a los usuarios recurrir al rol de ejecución de trabajos para proporcionar credenciales de acceso a S3 en situaciones que S3 Access Grants no cubre.
Si `fallbackToIAM` está habilitado, los usuarios pueden acceder a los datos que permite Access Grant. Si no hay un token de S3 Access Grants para los datos de destino, Amazon EMR comprueba el permiso en su rol de ejecución de trabajos.
**nota**
Recomendamos probar los permisos de acceso con la configuración `fallbackToIAM` habilitada, incluso si planea deshabilitar la opción para las cargas de trabajo de producción. Con los trabajos de Spark, hay otras formas en las que los usuarios pueden acceder a todos los conjuntos de permisos con sus credenciales de IAM. Cuando se habilitan en los clústeres de EMR, las concesiones de S3 permiten que los trabajos de Spark accedan a las ubicaciones de S3. Debe asegurarse de proteger estas ubicaciones de S3 del acceso externo a EMRFS. Por ejemplo, debe proteger las ubicaciones de S3 del acceso de los clientes de S3 que se utilizan en las computadoras portátiles o de las aplicaciones que no son compatibles con S3 Access Grants, como Hive o Presto.
# Autenticación en nodos de clúster de Amazon EMR
Lo clientes SSH pueden utilizar un par de claves de Amazon EC2 para autenticarse en instancias de clúster. De forma alternativa, con las versiones 5.10.0 y posteriores de Amazon EMR, puede configurar Kerberos para autenticar a los usuarios y las conexiones SSH con el nodo principal. Además, con las versiones 5.12.0 y posteriores de Amazon EMR, puede autenticarse con LDAP.
**Topics**
+ [Use un par de claves de EC2 para credenciales de SSH para Amazon EMR](emr-plan-access-ssh.md)
+ [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md)
+ [Uso de servidores de Active Directory o LDAP para la autenticación con Amazon EMR](ldap.md)
# Use un par de claves de EC2 para credenciales de SSH para Amazon EMR
Los nodos de clúster de Amazon EMR se ejecutan en instancias de Amazon EC2. Puede conectarse a nodos del clúster de la misma forma que puede conectarse a instancias de Amazon EC2. Puede utilizar Amazon EC2 para crear un par de claves, o bien puede importar un par de claves. Al crear un clúster, puede especificar el par de claves de Amazon EC2 que se utilizará para las conexiones SSH en todas las instancias del clúster. También puede crear un clúster sin un par de claves. Esto se hace con clústeres transitorios que se inician, ejecutan pasos, y luego se terminan de forma automática.
El cliente SSH que se utiliza para conectar al clúster necesita utilizar el archivo de clave privada asociado a este par de claves. Se trata de un archivo.pem para clientes SSH que utilizan Linux, Unix y MacOS. Debe establecer permisos para que solo el propietario de la clave tenga permiso para acceder al archivo. Para los clientes SSH que utilizan Windows, es un archivo .ppk, que normalmente se crea a partir del archivo .pem.
+ Para obtener más información sobre la creación de un par de claves de Amazon EC2, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
+ *Para obtener instrucciones sobre cómo usar Pu TTYgen para crear un archivo.ppk a partir de un archivo.pem, [consulte Convertir la clave privada mediante Pu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) en la Guía del usuario de TTYgen Amazon EC2.*
+ Para obtener más información sobre cómo configurar los permisos del archivo.pem y cómo conectarse al nodo principal de un clúster de EMR mediante diferentes métodos, incluidos `ssh` Linux o macOS, PuTTY desde Windows o AWS CLI desde cualquier sistema operativo compatible, consulte. [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md)
# Uso de Kerberos para la autenticación con Amazon EMR
Las versiones 5.10.0 y posteriores de Amazon EMR son compatibles con Kerberos. Kerberos es un protocolo de autenticación de redes que utiliza la criptografía de clave secreta para proporcionar una autenticación sólida, de forma que las contraseñas u otras credenciales no se envíen a través de la red en un formato no cifrado.
En Kerberos, los servicios y los usuarios que necesitan autenticarse se conocen como *entidades principales*. Las entidades principales existen dentro de un *ámbito* de Kerberos. En el ámbito, un servidor de Kerberos conocido como *centro de distribución de claves (KDC)* proporciona los medios para que se autentiquen las entidades principales. El KDC lo hace mediante la emisión de *tickets* para la autenticación. El KDC mantiene una base de datos de las entidades principales dentro de su ámbito, sus contraseñas y otros datos administrativos sobre cada una de las entidades principales. Un KDC también puede aceptar credenciales de autenticación de entidades principales de otros ámbitos, lo que se conoce como una *confianza entre ámbitos*. Además, un clúster de EMR puede utilizar un KDC externo para autenticar principales.
Una forma común de establecer una relación de confianza entre ámbitos o de utilizar un KDC externo es autenticar a los usuarios desde un dominio de Active Directory. Esto permite a los usuarios obtener acceso a un clúster de EMR con su cuenta de dominio cuando utilizan SSH para conectarse a un clúster o trabajan con aplicaciones de macrodatos.
Si utiliza autenticación de Kerberos, Amazon EMR configura Kerberos para las aplicaciones, componentes y subsistemas que instala en el clúster, de forma que se autentiquen entre sí.
**importante**
Amazon EMR no se admite AWS Directory Service for Microsoft Active Directory en un fideicomiso entre dominios ni como un KDC externo.
Antes de configurar Kerberos con Amazon EMR, le recomendamos que se familiarice con los conceptos de Kerberos, los servicios que se ejecutan en un KDC y las herramientas de administración de servicios de Kerberos. Para obtener más información, consulte la [documentación de Kerberos del MIT](http://web.mit.edu/kerberos/krb5-latest/doc/), que publica el [consorcio Kerberos](http://kerberos.org/).
**Topics**
+ [Aplicaciones compatibles con Amazon EMR](emr-kerberos-principals.md)
+ [Opciones de la arquitectura de Kerberos con Amazon EMR](emr-kerberos-options.md)
+ [Configuración de Kerberos en Amazon EMR](emr-kerberos-configure.md)
+ [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: Configuración de un KDC dedicado del clúster con Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md)
# Aplicaciones compatibles con Amazon EMR
Dentro de un clúster de EMR, las entidades principales de Kerberos son los servicios de aplicaciones de macrodatos y los subsistemas que se ejecutan en todos los nodos del clúster. Amazon EMR puede configurar las aplicaciones y componentes que se indican a continuación para utilizar Kerberos. Cada aplicación tiene una entidad principal de Kerberos asociada.
Amazon EMR no admite las relaciones de confianza entre ámbitos con AWS Directory Service for Microsoft Active Directory.
Amazon EMR solo configura las características de autenticación de Kerberos de código abierto para las aplicaciones y los componentes indicados a continuación. Cualquier otra aplicación instalada no utiliza Kerberos, lo que puede provocar la incapacidad para comunicarse con los componentes que utilizan Kerberos y generar errores en la aplicación. Las aplicaciones y componentes que no utilizan Kerberos no tienen habilitada la autenticación. Las aplicaciones y los componentes compatibles pueden variar según las distintas versiones de Amazon EMR.
La interfaz de usuario de Livy es la única interfaz de usuario web alojada en el clúster que está kerberizado.
+ **Hadoop MapReduce**
+ **HBase**
+ **HCatalog**
+ **HDFS**
+ **Hive**
+ No active Hive con la autenticación LDAP. Esto puede provocar problemas al comunicarse con el YARN que utiliza Kerberos.
+ **Hue**
+ Hue la autenticación de usuarios no se establece automáticamente y se pueden configurar mediante la configuración de la API.
+ El servidor de Hue utiliza Kerberos. El front-end (la UI) de Hue no está configurado para la autenticación. La autenticación LDAP se puede configurar para la UI de Hue.
+ **Livy**
+ La suplantación de Livy con clústeres kerberizados es compatible con las versiones 5.22.0 y posteriores de Amazon EMR.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto admite la autenticación de Kerberos en las versiones 6.9.0 y posteriores de Amazon EMR.
+ Si quiere usar la autenticación de Kerberos para Presto, debe habilitar el [cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **Spark**
+ **Tez**
+ **Trino**
+ Trino admite la autenticación de Kerberos en las versiones 6.11.0 y posteriores de Amazon EMR.
+ Si quiere usar la autenticación de Kerberos para Trino, debe habilitar el [cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
+ **YARN**
+ **Zeppelin**
+ Zeppelin solo está configurado para utilizar Kerberos con el intérprete Spark. No está configurado para otros intérpretes.
+ Los intérpretes de Zeppelin kerberizado que no sean Spark no admiten la suplantación de identidad de usuario.
+ **ZooKeeper**
+ Zookeeper cliente no es compatible.
# Opciones de la arquitectura de Kerberos con Amazon EMR
Cuando se utiliza Kerberos con Amazon EMR, puede elegir entre las arquitecturas que se indican en esta sección. Independientemente de la arquitectura que elija, para configurar Kerberos hay que seguir los mismos pasos. Debe crear una configuración de seguridad, especificar la configuración de seguridad y las opciones de Kerberos específicas del clúster compatibles al crear el clúster y crear directorios de HDFS para los usuarios de Linux en el clúster que coincidan con las entidades principales de usuarios en el KDC. Para leer una explicación sobre las opciones de configuración y configuraciones de ejemplo de cada arquitectura, consulte [Configuración de Kerberos en Amazon EMR](emr-kerberos-configure.md).
## KDC dedicado del clúster (KDC en nodo principal)
Esta configuración está disponible con las versiones 5.10.0 y posteriores de Amazon EMR.
![\[Amazon EMRclúster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Ventajas**
+ Amazon EMR tiene la plena propiedad del KDC.
+ El KDC en el clúster de EMR es independiente de las implementaciones de KDC centralizadas, como Microsoft Active Directory o AWS Managed Microsoft AD.
+ El impacto en el rendimiento es mínimo, ya que el KDC administra la autenticación solo para los nodos locales del clúster.
+ Opcionalmente, otros clústeres que utilizan Kerberos pueden hacer referencia al KDC como un KDC externo. Para obtener más información, consulte [KDC externo: nodo principal en un clúster diferente](#emr-kerberos-extkdc-cluster-summary).
**Consideraciones y limitaciones**
+ Los clústeres que utilizan Kerberos no se pueden autenticarse entre sí, por lo que las aplicaciones no pueden interactuar. Si las aplicaciones de clústeres tienen que interactuar, debe establecer una relación de confianza entre ámbitos entre los clústeres o configurar un clúster como el KDC externo para otros clústeres. Si se establece una confianza entre dominios, estos KDCs deben tener diferentes dominios de Kerberos.
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuario deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse al clúster mediante SSH.
## Relación de confianza entre ámbitos
En esta configuración, las entidades principales (normalmente usuarios) de otro ámbito de Kerberos se autentican para los componentes de la aplicación en un clúster de EMR que utiliza Kerberos y que tiene su propio KDC. El KDC del nodo principal establece una relación de confianza con otro KDC mediante un principal *entre dominios* que existe en ambos. KDCs El nombre y la contraseña de la entidad principal deben coincidir exactamente en cada KDC. Las relaciones de confianza entre ámbitos son más comunes con las implementaciones de Active Directory, tal y como se muestra en el siguiente diagrama. También se admiten relaciones de confianza entre ámbitos con un KDC de MIT externo o un KDC en otro clúster de Amazon EMR.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Ventajas**
+ El clúster de EMR en el que está instalado el KDC mantiene la plena propiedad del KDC.
+ Con Active Directory, Amazon EMR crea automáticamente usuarios de Linux que se corresponden con las entidades principales de usuario del KDC. Aun así, debe crear directorios de HDFS para cada usuario. Además, las entidades principales de usuario del dominio de Active Directory pueden obtener acceso a los clústeres que utilizan Kerberos mediante credenciales de `kinit`, sin el archivo de clave privada de EC2. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.
+ Dado que cada KDC del clúster administra la autenticación de los nodos del clúster, se minimizan los efectos de la latencia de la red y la sobrecarga de procesamiento de un gran número de nodos entre clústeres.
**Consideraciones y limitaciones**
+ Si va a establecer una relación de confianza con un ámbito de Active Directory, debe proporcionar un nombre de usuario y contraseña de Active Directory con permisos para unir entidades principales al dominio al crear el clúster.
+ Las relaciones de confianza entre ámbitos no se pueden establecer entre ámbitos de Kerberos con el mismo nombre.
+ Las relaciones de confianza entre ámbitos deben establecerse de forma explícita. Por ejemplo, si el Clúster A y B establecen una relación de confianza entre ámbitos con un KDC, no confían intrínsecamente uno en el otro y sus aplicaciones no pueden autenticarse entre sí para interaccionar.
+ KDCs debe mantenerse de forma independiente y coordinada para que las credenciales de los principales usuarios coincidan con precisión.
## KDC externo
Las configuraciones con un KDC externo son compatibles con las versiones 5.20.0 y posteriores de Amazon EMR.
+ [KDC externo: KDC de MIT](#emr-kerberos-extkdc-mit-summary)
+ [KDC externo: nodo principal en un clúster diferente](#emr-kerberos-extkdc-cluster-summary)
+ [KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory](#emr-kerberos-extkdc-ad-trust-summary)
### KDC externo: KDC de MIT
Esta configuración permite que uno o varios clústeres de EMR utilicen entidades principales definidas y mantenidos en un servidor de KDC de MIT.
![\[Amazon EMRclúster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Ventajas**
+ La administración de principales se consolida en un solo KDC.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
+ El nodo principal en un clúster que utiliza Kerberos no tiene la carga de rendimiento asociada con el mantenimiento del KDC.
**Consideraciones y limitaciones**
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal del clúster que tiene Kerberos que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuarios deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse a los clústeres que utilizan Kerberos mediante SSH.
+ Cada nodo de los clústeres de EMR que utilizan Kerberos debe tener una ruta de red al KDC.
+ Cada nodo en los clústeres que utilizan Kerberos impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos en los clústeres que utilizan Kerberos y el KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
### KDC externo: nodo principal en un clúster diferente
Esta configuración es casi idéntica a la implementación de KDC de MIT externo anterior, salvo que el KDC está en el nodo principal de un clúster de EMR. Para obtener más información, consulte [KDC dedicado del clúster (KDC en nodo principal)](#emr-kerberos-localkdc-summary) y [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de 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/es_es/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Ventajas**
+ La administración de principales se consolida en un solo KDC.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
**Consideraciones y limitaciones**
+ Debe crear usuarios de Linux en la instancia de EC2 del nodo principal del clúster que tiene Kerberos que se correspondan con las entidades principales de usuarios de KDC, junto con los directorios de HDFS de cada usuario.
+ Las entidades principales de usuarios deben utilizar un archivo de clave privada de EC2 y credenciales de `kinit` para conectarse a los clústeres que utilizan Kerberos mediante SSH.
+ Cada nodo de cada clúster de EMR debe tener una ruta de red al KDC.
+ Cada nodo de Amazon EMR de los clústeres que utilizan Kerberos impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos de clústeres y el KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
### KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory
En esta configuración, primero se crea un clúster con un KDC dedicado del clúster que tiene una relación de confianza entre ámbitos unidireccional con Active Directory. Para ver un tutorial detallado, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md). A continuación, lance clústeres adicionales, haciendo referencia al KDC del clúster que tiene la relación de confianza con un KDC externo. Para ver un ejemplo, consulta [KDC externo del clúster con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). De este modo, cada clúster de Amazon EMR puede utilizar el KDC externo para autenticar entidades principales definidas y mantenidas en un dominio de Microsoft Active Directory.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Ventajas**
+ La administración de entidades principales se consolida en el dominio de Active Directory.
+ Amazon EMR se incorpora al ámbito de Active Directory, lo que elimina la necesidad de crear usuarios de Linux que se correspondan con usuarios de Active Directory. Aun así, debe crear directorios de HDFS para cada usuario.
+ Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Para obtener más información, consulte [Requisitos para utilizar varios clústeres con el mismo KDC](#emr-kerberos-multi-kdc).
+ Las entidades principales de usuarios del dominio de Active Directory pueden acceder a los clústeres que utilizan Kerberos mediante credenciales de `kinit`, sin el archivo de clave privada de EC2. Así se elimina la necesidad de compartir el archivo de clave privada entre usuarios de clústeres.
+ Solo un nodo principal de Amazon EMR tiene la carga del mantenimiento del KDC y solo ese clúster debe crearse con credenciales de Active Directory para la relación de confianza entre ámbitos entre el KDC y Active Directory.
**Consideraciones y limitaciones**
+ Cada nodo de cada clúster de EMR debe tener una ruta de red al KDC y el controlador de dominio de Active Directory.
+ Cada nodo de Amazon EMR impone un carga de autenticación en el KDC externo, por lo que la configuración del KDC afecta al rendimiento del clúster. Cuando configure el hardware del servidor de KDC, tenga en cuenta el número máximo de nodos de Amazon EMR que se pueden admitir de forma simultánea.
+ El rendimiento del clúster depende de la latencia de red entre los nodos de los clústeres y el servidor de KDC.
+ La solución de problemas puede ser más difícil debido a las interdependencias.
## Requisitos para utilizar varios clústeres con el mismo KDC
Varios clústeres pueden utilizar el mismo KDC en el mismo ámbito de Kerberos. Sin embargo, si los clústeres se ejecutan simultáneamente, es posible que fallen si utilizan ServicePrincipal nombres de Kerberos que entren en conflicto.
Si tiene varios clústeres simultáneos con el mismo KDC externo, asegúrese de que los clústeres utilicen distintos ámbitos de Kerberos. Si los clústeres deben usar el mismo dominio de Kerberos, asegúrese de que estén en subredes diferentes y de que sus rangos de CIDR no se superpongan.
# Configuración de Kerberos en Amazon EMR
En esta sección, se proporcionan detalles y ejemplos de la configuración de Kerberos con arquitecturas comunes. Independientemente de la arquitectura que elija, los aspectos básicos de la configuración son los mismos y se realizan en tres pasos. Si utiliza un KDC externo o configura una relación de confianza entre ámbitos, debe asegurarse de que todos los nodos de un clúster tengan una ruta de red al KDC externo, incluida la configuración de los grupos de seguridad aplicables para permitir el tráfico de entrada y salida de Kerberos.
## Paso 1: Cree una configuración de seguridad con propiedades de Kerberos
La configuración de seguridad especifica detalles sobre el KDC de Kerberos y permite reutilizar la configuración de Kerberos cada vez que se crea un clúster. Puede crear una configuración de seguridad mediante la consola de Amazon EMR AWS CLI, la o la API de EMR. La configuración de seguridad también pueden contener otras opciones de seguridad, como, por ejemplo, el cifrado. Para obtener más información acerca de la creación y especificación de las configuraciones de seguridad cuando se crea un clúster, consulte [Uso de configuraciones de seguridad para configurar la seguridad del clúster de Amazon EMR](emr-security-configurations.md). Para obtener más información acerca de las propiedades de Kerberos en una configuración de seguridad, consulte [Configuración de Kerberos para las configuraciones de seguridad](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Paso 2: Cree un clúster y especifique los atributos de Kerberos específicos del clúster
Al crear un clúster, especifique la configuración de seguridad de Kerberos junto con las opciones de Kerberos específicas del clúster. Cuando utilice la consola de Amazon EMR, solo están disponibles las opciones de Kerberos compatibles con la configuración de seguridad especificada. Cuando utilice la AWS CLI API de Amazon EMR, asegúrese de especificar las opciones de Kerberos compatibles con la configuración de seguridad especificada. Por ejemplo, si especifica la contraseña de la entidad principal para una relación de confianza entre ámbitos al crear un clúster mediante la CLI y la configuración de seguridad especificada no tiene parámetros de relación de confianza entre ámbitos, se produce un error. Para obtener más información, consulte [Configuración de Kerberos para clústeres](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Paso 3: configure el nodo principal del clúster
En función de los requisitos de su arquitectura e implementación, es posible que sea necesario realizar una configuración adicional en el clúster. Puede hacer esto después de crearla o mediante pasos o acciones de arranque durante el proceso de creación.
Para cada usuario autenticado de Kerberos que se conecte al clúster utilizando SSH, debe asegurarse de que se crean cuentas de Linux que se corresponden con el usuario de Kerberos. Si el controlador de dominio de Active Directory proporciona las entidades principales de usuario, ya sea como el KDC externo o a través de una relación de confianza entre ámbitos, Amazon EMR crea cuentas de usuario de Linux de forma automática. Si no se utiliza Active Directory, debe crear entidades principales para cada usuario que se correspondan con su usuario de Linux. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
Cada usuario también debe tener un directorio de usuarios de HDFS propio que debe crear usted. Además, SSH debe estar configurado con GSSAPI habilitado para permitir conexiones de los usuarios autenticados por Kerberos. GSSAPI debe estar habilitado en el nodo principal y se debe configurar la aplicación SSH del cliente para que utilice GSSAPI. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
# Configuración de seguridad y configuración de clústeres para Kerberos en Amazon EMR
Al crear un clúster que utiliza Kerberos, debe especificar la configuración de seguridad junto con los atributos de Kerberos específicos para el clúster. No puede especificar un conjunto sin el otro, o se producirá un error.
En este tema, se ofrece información general de los parámetros de configuración disponibles para Kerberos al crear una configuración de seguridad y un clúster. Además, se proporcionan ejemplos de CLI para crear configuraciones de seguridad compatibles y clústeres para arquitecturas comunes.
## Configuración de Kerberos para las configuraciones de seguridad
Puede crear una configuración de seguridad que especifique los atributos de Kerberos mediante la consola de Amazon EMR, AWS CLI la o la API EMR. La configuración de seguridad también pueden contener otras opciones de seguridad, como, por ejemplo, el cifrado. Para obtener más información, consulte [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md).
Utilice las siguientes referencias para conocer las opciones de configuración de seguridad disponibles para la arquitectura Kerberos que elija. Se muestra la configuración de la consola de Amazon EMR. Para ver las opciones de la CLI correspondientes, consulte [Especificar la configuración de Kerberos mediante AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) o [Ejemplos de configuraciones](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Configuración de Kerberos para clústeres
Puede especificar la configuración de Kerberos al crear un clúster mediante la consola Amazon EMR, la API EMR o AWS CLI la API EMR.
Utilice las siguientes referencias para conocer las opciones de configuración de clústeres disponibles para la arquitectura Kerberos que elija. Se muestra la configuración de la consola de Amazon EMR. Para ver las opciones de la CLI correspondientes, consulte [Ejemplos de configuraciones](emr-kerberos-config-examples.md).
| Parámetro | Description (Descripción) |
| --- | --- |
| Ámbito | El nombre del ámbito de Kerberos para el clúster. La convención de Kerberos consiste en establecerlo igual que el nombre del dominio, pero en mayúsculas. Por ejemplo, para el dominio `ec2.internal`, se utiliza `EC2.INTERNAL` como nombre de ámbito. |
| Contraseña de administración de KDC | La contraseña utilizada en el clúster `kadmin` o `kadmin.local`. Son interfaces de línea de comandos para el sistema de administración de Kerberos V5, que mantiene las entidades principales, las políticas de contraseñas y las tablas de claves de Kerberos para el clúster. |
| Contraseña de la entidad principal de confianza entre ámbitos (opcional) | Es necesaria para establecer una confianza entre ámbitos. La contraseña de la entidad principal de confianza entre ámbitos, que debe ser idéntica en los distintos ámbitos. Use una contraseña segura. |
| Usuario de incorporación al dominio de Active Directory (opcional) | Obligatorio cuando se utiliza Active Directory en una relación de confianza entre ámbitos. Se trata de un nombre de inicio de sesión de usuario de una cuenta de Active Directory con permisos para incorporar equipos al dominio. Amazon EMR utiliza esta identidad para incorporar el clúster al dominio. Para obtener más información, consulte [Paso 3: adición de cuentas al dominio para el clúster de EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Contraseña de incorporación al dominio de Active Directory (opcional) | La contraseña del usuario de incorporación a un dominio de Active Directory. Para obtener más información, consulte [Paso 3: adición de cuentas al dominio para el clúster de EMR](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Ejemplos de configuraciones
Los siguientes ejemplos muestran las configuraciones de seguridad y las configuraciones de clúster para escenarios comunes. AWS CLI los comandos se muestran por motivos de brevedad.
## KDC local
Los siguientes comandos crean un clúster con un KDC dedicado del clúster que se ejecuta en el nodo principal. Es necesario realizar una configuración adicional en el clúster. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
**Crear configuración de seguridad**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Crear un clúster**
```
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 del clúster con una relación de confianza entre ámbitos de Active Directory
Los siguientes comandos crean un clúster con un KDC dedicado del clúster que se ejecuta en el nodo principal con una relación de confianza entre ámbitos con un dominio de Active Directory. Se necesita realizar configuración adicional en el clúster y en Active Directory. Para obtener más información, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md).
**Crear configuración de seguridad**
```
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"}}}}}'
```
**Crear un clúster**
```
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 en un clúster diferente
Los siguientes comandos crean un clúster que hace referencia a un KDC dedicado del clúster en el nodo principal de un clúster diferente para autenticar entidades principales. Es necesario realizar una configuración adicional en el clúster. Para obtener más información, consulte [Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos](emr-kerberos-configuration-users.md).
**Crear configuración de seguridad**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Crear un clúster**
```
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 del clúster con una relación de confianza entre ámbitos de Active Directory
Los siguientes comandos crean un clúster sin KDC. El clúster hace referencia a un KDC dedicado del clúster que se ejecuta en el nodo principal de otro clúster para autenticar entidades principales. Esa KDC posee una relación de confianza entre ámbitos con un controlador de dominio de Active Directory. Es necesario realizar una configuración adicional en el nodo principal con el KDC. Para obtener más información, consulte [Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory](emr-kerberos-cross-realm.md).
**Crear configuración de seguridad**
```
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"}}}}}'
```
**Crear un clúster**
```
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
```
# Configuración de un clúster de Amazon EMR para conexiones SSH y usuarios de HDFS autenticados en Kerberos
Amazon EMR crea clientes de usuario autenticados por Kerberos para las aplicaciones que se ejecutan en el clúster; por ejemplo, el usuario `hadoop`, el usuario `spark` y otros. También puede añadir usuarios autenticados a los procesos del clúster mediante Kerberos. Luego, los usuarios autenticados pueden conectarse al clúster con sus credenciales de Kerberos y trabajar con aplicaciones. Para que un usuario pueda autenticarse en el clúster, es necesario realizar las siguientes configuraciones:
+ En el clúster debe existir una cuenta de Linux que coincida con la entidad principal de Kerberos en el KDC. Amazon EMR lo hace automáticamente en arquitecturas que se integran con Active Directory.
+ Debe crear un directorio de usuarios de HDFS en el nodo principal para cada usuario y proporcionar permisos de usuario al directorio.
+ Debe configurar el servicio SSH para que GSSAPI esté habilitado en el nodo principal. Además, los usuarios deben tener un cliente SSH con GSSAPI habilitado.
## Adición de usuarios de Linux y entidades principales de Kerberos al nodo principal
Si no utiliza Active Directory, debe crear las cuentas de Linux en el nodo principal del clúster y agregar entidades principales para estos usuarios de Linux al KDC. Esto incluye una entidad principal en el KDC para el nodo principal. Además de las entidades principales de usuarios, el KDC que se ejecuta en el nodo principal necesita una entidad principal para el host local.
Cuando la arquitectura incluye integración con Active Directory, los usuarios y entidades principales de Linux en el KDC local, si procede, se crean automáticamente. Puede omitir este paso. Para obtener más información, consulte [Relación de confianza entre ámbitos](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) y [KDC externo: KDC de clúster en un clúster diferente con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**importante**
El KDC, junto con la base de datos de entidades principales, se pierde cuando el nodo principal termina porque el nodo principal utiliza almacenamiento efímero. Si crea usuarios para las conexiones SSH, le recomendamos que establezca una relación de confianza entre dominios con un KDC externo configurado para lograr una alta disponibilidad. Como alternativa, si crea usuarios para las conexiones SSH mediante cuentas de Linux, automatice el proceso de creación de cuentas mediante acciones y scripts de arranque para que pueda repetirse al crear un clúster nuevo.
La manera más sencilla de añadir usuarios y entidades principales de KDC es enviar un paso al clúster después de crearlo o al crear el clúster. Si lo prefiere, puede conectarse al nodo principal utilizando un par de claves de EC2 como el usuario predeterminado `hadoop` para ejecutar los comandos. Para obtener más información, consulte [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md).
En el siguiente ejemplo, se envía un script bash `configureCluster.sh` a un clúster que ya existe, especificando su ID de clúster. El script se almacena en 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"]
```
El siguiente ejemplo muestra el contenido del script `configureCluster.sh`. El script también se encarga de la creación de los directorios de usuario de HDFS y de habilitar GSSAPI para SSH, lo que se explica en las siguientes secciones.
```
#!/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
```
## Adición de directorios de HDFS de usuarios
Para permitir a los usuarios iniciar sesión en el clúster para ejecutar los trabajos de Hadoop, debe agregar directorios de usuario de HDFS para sus cuentas de Linux y conceder a cada usuario la propiedad de su directorio.
La manera más sencilla de crear directorios de HDFS es enviar un paso al clúster después de crearlo o al crear el clúster. Si lo prefiere, podría conectarse al nodo principal utilizando un par de claves de EC2 como el usuario predeterminado `hadoop` para ejecutar los comandos. Para obtener más información, consulte [Conexión al nodo principal del clúster de Amazon EMR mediante SSH](emr-connect-master-node-ssh.md).
En el siguiente ejemplo, se envía un script bash `AddHDFSUsers.sh` a un clúster que ya existe, especificando su ID de clúster. El script se almacena en 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"]
```
El siguiente ejemplo muestra el contenido del 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
```
## Habilitación de GSSAPI para SSH
Para que los usuarios autenticados por Kerberos se conecten al nodo principal mediante SSH, el servicio SSH debe tener habilitada la autenticación de GSSAPI. Para habilitar GSSAPI, ejecute los siguientes comandos desde la línea de comandos del nodo principal o utilice un paso para ejecutarlo como un script. Después de volver a configurar SSH, reinicie el servicio.
```
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 conectarse a clústeres que utilizan Kerberos con Amazon EMR
En esta sección, se muestran los pasos para que un usuario autenticado por Kerberos se conecte al nodo principal de un clúster de EMR.
Cada equipo que se utiliza para una conexión SSH debe tener instalados un cliente SSH y aplicaciones de cliente de Kerberos. Lo más probable es que los equipos Linux los incluyan de forma predeterminada. Por ejemplo, OpenSSH está instalado en la mayoría de los sistemas operativos Linux, Unix y macOS. Puede comprobar si tiene un cliente SSH escribiendo **ssh** en la línea de comandos. Si su equipo no reconoce el comando, instale un cliente SSH para conectarse al nodo principal. El proyecto OpenSSH ofrece una implementación gratuita de toda la suite de herramientas de SSH. Para obtener más información, consulte el sitio web [OpenSSH](http://www.openssh.org/). Los usuarios de Windows pueden utilizar aplicaciones como [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/) como cliente SSH.
Para obtener más información sobre las conexiones SSH persistentes, use [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
SSH utiliza GSSAPI para autenticar a los clientes de Kerberos y debe habilitar la autenticación de GSSAPI para el servicio SSH en el nodo principal del clúster. Para obtener más información, consulte [Habilitación de GSSAPI para SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Los clientes SSH también deben utilizar GSSAPI.
En los siguientes ejemplos, *MasterPublicDNS* utilice el valor que aparece para el **DNS público maestro** en la pestaña **Resumen** del panel de detalles del clúster, por ejemplo,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Requisito previo para krb5.conf (sin Active Directory)
Cuando se utiliza una configuración sin integración con Active Directory, además del cliente SSH y las aplicaciones de cliente de Kerberos, cada equipo cliente debe tener una copia del archivo `/etc/krb5.conf` que coincida con el archivo `/etc/krb5.conf` en el nodo principal del clúster.
**Para copiar el archivo krb5.conf**
1. Utilice SSH para conectarse al nodo principal mediante un par de claves de EC2 y el usuario `hadoop`predeterminado, por ejemplo, `hadoop@MasterPublicDNS`. Para obtener instrucciones detalladas, consulte [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
1. Desde el nodo principal, copie el contenido del archivo `/etc/krb5.conf`. Para obtener más información, consulte [Conectar a un clúster de Amazon EMR](emr-connect-master-node.md).
1. En cada equipo cliente que se utilice para conectarse al clúster, cree un archivo `/etc/krb5.conf` idéntico a partir de la copia que hizo en el paso anterior.
## Uso de kinit y SSH
Cada vez que un usuario se conecta desde un equipo cliente con credenciales de Kerberos, el usuario debe renovar primero los tickets de Kerberos para su usuario en el equipo cliente. Además, se debe configurar el cliente SSH para utilizar la autenticación GSSAPI.
**Para utilizar SSH para conectarse a un clúster de EMR que utilice Kerberos**
1. Utilice `kinit` para renovar sus tickets de Kerberos, como se muestra en el siguiente ejemplo
```
kinit user1
```
1. Utilice un cliente `ssh` junto con la entidad principal que creó en el KDC dedicado del clúster o el nombre de usuario de Active Directory. Asegúrese de que la autenticación GSSAPI está habilitada, tal y como se muestra en los siguientes ejemplos.
**Ejemplo: usuarios de Linux**
La opción `-K `especifica la autenticación GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Ejemplo: usuarios de Windows (PuTTY)**
Asegúrese de que la opción de autenticación GSSAPI de la sesión está habilitada, tal y como se muestra:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: Configuración de un KDC dedicado del clúster con Amazon EMR
En este tema, le enseñaremos cómo crear un clúster con un *centro de distribución de claves (KDC)* dedicado, cómo agregar manualmente cuentas de usuario de Linux a todos los nodos del clúster, cómo agregar entidades principales de Kerberos al KDC en el nodo principal y cómo asegurarse de que los equipos cliente tengan instalado un cliente de Kerberos.
Para obtener más información sobre la compatibilidad de Amazon EMR con Kerberos y KDC, así como enlaces a la documentación de Kerberos del MIT, consulte [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md).
## Paso 1: creación del clúster que utiliza Kerberos
1. Cree una configuración de seguridad que habilite Kerberos. En el siguiente ejemplo, se muestra un `create-security-configuration` comando que utiliza el AWS CLI que especifica la configuración de seguridad como una estructura JSON en línea. También puede hacer referencia a un archivo guardado de forma local.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Cree un clúster que haga referencia a la configuración de seguridad, establezca los atributos de Kerberos para el clúster y añada las cuentas de Linux mediante una acción de arranque. El siguiente ejemplo muestra el uso de un comando `create-cluster `en la AWS CLI. El comando hace referencia a la configuración de seguridad que se ha creado anteriormente, `MyKerberosConfig`. También hace referencia a un script sencillo, `createlinuxusers.sh`, como acción de arranque, que debe crear y cargar en Amazon S3 antes de crear el clúster.
```
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
```
El siguiente código ilustra el contenido del script `createlinuxusers.sh`, que agrega user1, user2 y user3 en cada nodo del clúster. En el siguiente paso, añadirá estos usuarios como entidades principales de KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Paso 2: adición de entidades principales al KDC, creación directorios de usuarios de HDFS y configuración de SSH
En el KDC que se ejecuta en el nodo principal, se debe agregar una entidad principal para el host local y para cada usuario que se cree en el clúster. También puede crear directorios de HDFS para cada usuario en caso de que necesitan conectarse al clúster y ejecutar trabajos de Hadoop. Del mismo modo, configurae el servicio SSH para activar la autenticación GSSAPI, que es necesaria para Kerberos. Después de habilitar GSSAPI, reinicie el servicio SSH.
La forma más sencilla de realizar estas tareas es enviar un paso para el clúster. El siguiente ejemplo envía un script bash `configurekdc.sh` al clúster que ha creado en el paso anterior, haciendo referencia a su ID de clúster. El script se almacena en Amazon S3. De forma alternativa, puede conectarse al nodo principal utilizando un par de claves de EC2 para ejecutar los comandos o enviar el paso durante la creación del clúster.
```
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"]
```
El siguiente código muestra el contenido del 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
```
Los usuarios que ha añadido ahora deberían ser capaces de conectarse al clúster mediante SSH. Para obtener más información, consulte [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: Configuración de una relación de confianza entre ámbitos con un dominio de Active Directory
Al crear una relación de confianza entre ámbitos, se permite a las entidades principales (normalmente usuarios) de otro ámbito de Kerberos autenticar a los componentes de la aplicación en el clúster de EMR. El *centro de distribución de claves (KDC)* dedicado al clúster establece una relación de confianza con otro KDC mediante un principio *multidominio* que existe en ambos. KDCs El nombre y la contraseña de la entidad principal deben coincidir exactamente.
Una relación de confianza entre ámbitos requiere que los KDC puedan tener acceso entre sí a través de la red y resolver sus nombres de dominio. Pasos para establecer una relación de confianza con un ámbito Microsoft AD controlador de dominio se ejecutan como una instancia de EC2 se suministran a continuación, junto con un ejemplo de configuración de red que proporciona la conectividad y la resolución de nombres de dominio. Se acepta cualquier configuración de red que permita el tráfico de red necesario entre ellos. KDCs
Opcionalmente, después de establecer una relación de confianza entre ámbitos con Active Directory utilizando un KDC en un clúster, puede crear otro clúster con una configuración de seguridad diferente para hacer referencia al KDC en el primer clúster como un KDC externo. Para ver un ejemplo de la configuración de seguridad y la configuración del clúster, consulte [KDC externo del clúster con una relación de confianza entre ámbitos de Active Directory](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Para obtener más información sobre la compatibilidad de Amazon EMR con Kerberos y KDC, así como enlaces a la documentación de Kerberos del MIT, consulte [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md).
**importante**
Amazon EMR no admite fideicomisos entre dominios con. AWS Directory Service for Microsoft Active Directory
[Paso 1: Configuración de la VPC y la subred](#emr-kerberos-ad-network)
[Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory](#emr-kerberos-ad-dc)
[Paso 3: adición de cuentas al dominio para el clúster de EMR](#emr-kerberos-ad-users)
[Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory](#emr-kerberos-ad-configure-trust)
[Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC](#emr-kerberos-ad-DHCP)
[Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster)
[Paso 7: creación de usuarios de HDFS y configuración de permisos en el clúster para las cuentas de usuario de Active Directory](#emr-kerberos-ad-hadoopuser)
## Paso 1: Configuración de la VPC y la subred
Los pasos siguientes muestran cómo crear una VPC y una subred para que el KDC dedicado del clúster pueda tener acceso al controlador de dominio de Active Directory y resolver su nombre de dominio. En estos pasos, la resolución de nombres de dominio se proporciona haciendo referencia al controlador de dominio de Active Directory como el servidor de nombres de dominio en el conjunto de opciones de DHCP. Para obtener más información, consulte [Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC](#emr-kerberos-ad-DHCP).
El KDC y el controlador de dominio de Active Directory deben ser capaces de resolver sus respectivos nombres de dominio. Esto permite a Amazon EMR incorporar equipos al dominio y configurar automáticamente las cuentas de Linux y los parámetros de SSH correspondientes en las instancias de clúster.
Si Amazon EMR no puede resolver el nombre de dominio, se puede hacer referencia a la relación de confianza mediante la dirección IP del controlador de dominio de Active Directory. Sin embargo, debe agregar manualmente las cuentas de usuario de Linux, agregar las correspondientes entidades principales al KDC dedicado del clúster y configurar SSH.
**Para configurar la VPC y la subred**
1. Cree una instancia de Amazon VPC con una única subred pública. Para obtener más información, consulte [Paso 1: creación de la VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) en la *Guía de introducción a Amazon VPC*.
**importante**
Cuando utilice un controlador de dominio de Microsoft Active Directory, elija un bloque CIDR para el clúster de EMR de modo que IPv4 todas las direcciones tengan menos de nueve caracteres (por ejemplo, 10.0.0.0/16). Esto se debe a que los nombres DNS de los equipos del clúster se utilizan cuando los equipos se unen al directorio de Active Directory. AWS asigna [nombres de host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) en función de la IPv4 dirección, de manera que las direcciones IP más largas pueden dar como resultado nombres DNS de más de 15 caracteres. Active Directory tiene un límite de 15 caracteres para registrar los nombres de los equipos que se incorporan, y trunca los nombres que son más largos, lo que puede provocar errores impredecibles.
1. Elimine el conjunto de opciones de DHCP predeterminado asignado a la VPC. Para obtener más información, consulte [Cambiar una VPC para que no utilice ninguna opción de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Posteriormente, puede añadir uno nuevo que especifique el controlador de dominio de Active Directory como servidor DNS.
1. Confirme que se ha activado el soporte de DNS para la VPC, es decir, que se han activado los nombres de host DNS y la resolución de DNS. De forma predeterminada, están habilitadas. Para obtener más información, consulte [Actualización de la compatibilidad de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Confirme que la VPC tiene un asociada una gateway de Internet, que es la opción predeterminada. Para obtener más información, consulte [Creación y asociación de una gateway de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**nota**
En este ejemplo, se utiliza una gateway de Internet porque se está estableciendo un nuevo controlador de dominio para la VPC. Puede que no sea necesaria una gateway de Internet para su aplicación. El único requisito es que el KDC dedicado del clúster pueda tener acceso al controlador de dominio de Active Directory.
1. Cree una tabla de ruteo personalizada, añada una ruta que se dirija a la gateway de Internet y, a continuación, asóciela a la subred. Para obtener más información, consulte [Creación de una tabla de enrutamiento personalizada](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Al lanzar la instancia EC2 para el controlador de dominio, debe tener una IPv4 dirección pública estática para que pueda conectarse a ella mediante RDP. La forma más sencilla de hacerlo es configurar la subred para que asigne automáticamente direcciones públicas IPv4 . Este no es el valor predeterminado cuando se crea una subred. Para obtener más información, consulte [Modificación del atributo de IPv4 direccionamiento público de la subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si lo prefiere, puede asignar la dirección al lanzar la instancia. Para obtener más información, consulta Cómo [asignar una IPv4 dirección pública durante el lanzamiento de una instancia](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Cuando termine, anote la VPC y la subred. IDs Los utilizará posteriormente al lanzar el controlador de dominio de Active Directory y el clúster.
## Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory
1. Lance una instancia de EC2 basada en la AMI base de Microsoft Windows Server 2016. Le recomendamos un tipo de instancia m4.xlarge o mejor. Para obtener más información, consulte [Lanzamiento de una instancia AWS Marketplace](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) en la *Guía del usuario de Amazon EC2*.
1. Anote el Group ID (ID de grupo) del grupo de seguridad asociado a la instancia EC2. Lo necesitará para [Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster). Usamos. *sg-012xrlmdomain345* También puede especificar distintos grupos de seguridad para el clúster de EMR y esta instancia que permita el tráfico entre ellos. Para obtener más información, consulte [Grupos de seguridad de Amazon EC2 para instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) en la *Guía del usuario de Amazon EC2*.
1. Conéctese a la instancia de EC2 a través de RDP. Para obtener más información, consulte [Conexión a su instancia de Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) en la *Guía del usuario de Amazon EC2*.
1. Inicie **Administrador del servidor** para instalar y configurar el rol de los servicios de dominio de Active Directory en el servidor. Promocione el servidor a controlador de dominio y asígnele un nombre de dominio (el ejemplo que utilizamos aquí es `ad.domain.com`). Anote el nombre de dominio porque lo necesitará más adelante al crear el clúster y la configuración de seguridad de EMR. Si es la primera vez que configura Active Directory, puede seguir las instrucciones de [How to Set Up Active Directory (AD) in Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
La instancia se reiniciará cuando termine.
## Paso 3: adición de cuentas al dominio para el clúster de EMR
Establezca una conexión RDP con el controlador de dominio de Active Directory para crear cuentas de usuario en Usuarios y equipos de Active Directory para cada usuario del clúster. Para obtener más información, consulte [Create a User Account in Active Directory Users and Computers](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) en el sitio *Microsoft Learn*. Anote el **User logon name (Nombre de inicio de sesión de usuario)** de cada usuario. Necesitas estas versiones posteriores al configurar el clúster.
Cree también una cuenta con privilegios suficientes para incorporar ordenadores al dominio. Tiene que especificar esta cuenta al crear un clúster. Amazon EMR la utiliza para incorporar las instancias del clúster al dominio Solo debe especificar esta cuenta y su contraseña [Paso 6: Lanzar un clúster de EMR que utiliza Kerberos](#emr-kerberos-ad-cluster). Para delegar los privilegios de incorporación de equipos a la cuenta, le recomendamos que cree un grupo con privilegios de incorporación y, a continuación, asigne el usuario al grupo. Para obtener instrucciones, consulte [Delegación de privilegios de vinculación a directorios](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) en la *Guía de administración de AWS Directory Service *.
## Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory
Los comandos del ejemplo siguiente crean una relación de confianza en Active Directory, que es una confianza de ámbito, entrante, unidireccional y no transitiva con el KDC dedicado del clúster. El ejemplo que utilizamos para el ámbito del clúster es `EC2.INTERNAL`. Sustituya el *KDC-FQDN* nombre de **DNS público** que aparece en la lista para el nodo principal de Amazon EMR que aloja el KDC. El parámetro `passwordt` especifica la **cross-realm principal password (contraseña de la entidad principal de confianza entre ámbitos)**, que se especifica junto con el **realm (ámbito)** del clúster al crear un clúster. El nombre del ámbito se deriva del nombre de dominio predeterminado en `us-east-1` para el clúster. El `Domain` es el dominio de Active Directory en el que va a crear la confianza, que es en minúsculas por convención. El ejemplo utiliza `ad.domain.com`
Abra el símbolo del sistema de Windows con privilegios de administrador y escriba los siguientes comandos para crear la relación de confianza en el controlador de dominio de 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
```
## Paso 5: uso de un conjunto de opciones de DHCP para especificar el controlador de dominio de Active Directory como un servidor DNS de la VPC
Ahora que está configurado el controlador de dominio de Active Directory, debe configurar la VPC para utilizarla como servidor de nombres de dominio para la resolución de nombres en la VPC. Para ello, asocie un conjunto de opciones de DHCP. En **Nombre de dominio**, especifique el nombre de dominio del clúster; por ejemplo, `ec2.internal` si el clúster se encuentra en la región us-east-1 o `region.compute.internal` para las demás regiones. En el caso de **los servidores de nombres de dominio**, debe especificar la dirección IP del controlador de dominio de Active Directory (al que se debe poder acceder desde el clúster) como primera entrada, seguida del **AmazonProvidedDNS** (por ejemplo ***xx.xx.xx.xx*, AmazonProvided** DNS). Para obtener más información, consulte [Cambio de los conjuntos de opciones de DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Paso 6: Lanzar un clúster de EMR que utiliza Kerberos
1. En Amazon EMR, cree una configuración de seguridad que especifique el controlador de dominio de Active Directory que ha creado en los pasos anteriores. A continuación se muestra un ejemplo. Sustituya el dominio, `ad.domain.com`por el nombre del dominio especificado en el [Paso 2: lanzamiento e instalación del controlador de dominio de 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. Cree el clúster con los siguientes atributos:
+ Utilice la opción `--security-configuration` para especificar la configuración de seguridad que ha creado. Usamos *MyKerberosConfig* en el ejemplo.
+ Utilice la propiedad `SubnetId` de `--ec2-attributes option` para especificar la subred que ha creado en [Paso 1: Configuración de la VPC y la subred](#emr-kerberos-ad-network). Usamos *step1-subnet* en el ejemplo.
+ Utilice `AdditionalMasterSecurityGroups` y `AdditionalSlaveSecurityGroups` de la opción `--ec2-attributes` para especificar que el grupo de seguridad asociado al controlador de dominio de AD desde [Paso 2: lanzamiento e instalación del controlador de dominio de Active Directory](#emr-kerberos-ad-dc) está asociado al nodo principal del clúster, así como a los nodos secundarios y de tareas. Usamos *sg-012xrlmdomain345* en el ejemplo.
Utilice `--kerberos-attributes` para especificar los siguientes atributos de Kerberos específicos del clúster:
+ El ámbito para el clúster que especificó al configurar el controlador de dominio de Active Directory.
+ La contraseña de la entidad principal de confianza entre ámbitos que especificó como `passwordt` en el [Paso 4: configuración de una relación de confianza entrante en el controlador de dominio de Active Directory](#emr-kerberos-ad-configure-trust).
+ Una `KdcAdminPassword`, que se puede utilizar para administrar el KDC dedicado del clúster.
+ El nombre de inicio de sesión de usuario y la contraseña de la cuenta de Active Directory con privilegios para incorporar equipos que ha creado en el [Paso 3: adición de cuentas al dominio para el clúster de EMR](#emr-kerberos-ad-users).
El siguiente ejemplo lanza un clúster que utiliza Kerberos.
```
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
```
## Paso 7: creación de usuarios de HDFS y configuración de permisos en el clúster para las cuentas de usuario de Active Directory
Cuando se configura una relación de confianza con Active Directory, Amazon EMR crea usuarios de Linux en el clúster para cada cuenta de usuario de Active Directory. Por ejemplo, el nombre de inicio de sesión de usuario `LiJuan` en Active Directory se corresponde con la cuenta de Linux de `lijuan`. Los nombres de usuario de Active Directory pueden contener letras mayúsculas, pero Linux no distingue entre mayúsculas y minúsculas para dichos nombres.
Para permitir a los usuarios iniciar sesión en el clúster para ejecutar los trabajos de Hadoop, debe agregar directorios de usuario de HDFS para sus cuentas de Linux y conceder a cada usuario la propiedad de su directorio. Para ello, le recomendamos que ejecute un script almacenado en Amazon S3 como un paso de clúster. De forma alternativa, puede ejecutar los comandos en el script siguiente desde la línea de comandos en el nodo principal. Utilice el par de claves de EC2 especificado al crear el clúster para conectarse al nodo principal a través de SSH como usuario de Hadoop. Para obtener más información, consulte [Use un par de claves de EC2 para credenciales de SSH para Amazon EMR](emr-plan-access-ssh.md).
Ejecute el siguiente comando para añadir un paso al clúster que ejecuta un 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"]
```
El contenido del archivo *AddHDFSUsers.sh* es el siguiente.
```
#!/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 de Active Directory asignados a grupos de Hadoop
Amazon EMR utiliza System Security Services Daemon (SSD) para asignar grupos de Active Directory a grupos de Hadoop. Para confirmar las asignaciones de grupos, después de iniciar sesión en el nodo principal tal y como se describe en [Uso de SSH para conectarse a clústeres que utilizan Kerberos con Amazon EMR](emr-kerberos-connect-ssh.md), puede utilizar el comando `hdfs groups` para confirmar que los grupos de Active Directory a los que pertenece su cuenta de Active Directory se han asignado a los grupos de Hadoop del usuario de Hadoop correspondiente en el clúster. También puede comprobar los mapeos de grupos de otros usuarios especificando uno o varios nombres de usuario con el comando, por ejemplo `hdfs groups lijuan`. Para obtener más información, consulte [groups](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) en la [Apache HDFS Commands Guide](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Uso de servidores de Active Directory o LDAP para la autenticación con Amazon EMR
Con las versiones 6.12.0 y posteriores de Amazon EMR, puede utilizar el protocolo LDAP sobre SSL (LDAPS) para lanzar un clúster que se integre de forma nativa con su servidor de identidad corporativa. El LDAP (protocolo ligero de acceso a directorios) es un protocolo de aplicaciones abierto e independiente del proveedor que accede a los datos y los mantiene. El LDAP se utiliza habitualmente para la autenticación de usuarios en servidores de identidad corporativa alojados en aplicaciones como Active Directory (AD) y OpenLDAP. Con esta integración nativa, puede usar su servidor LDAP para autenticar a los usuarios en Amazon EMR.
Entre los aspectos destacados de la integración del LDAP de Amazon EMR se encuentran los siguientes:
+ Amazon EMR configura las aplicaciones compatibles para que se autentiquen con la autenticación LDAP en su nombre.
+ Amazon EMR configura y mantiene la seguridad de las aplicaciones compatibles con el protocolo Kerberos. No es necesario introducir ningún comando o script.
+ Se obtiene un control de acceso detallado (FGAC) mediante la autorización de Apache Ranger para las bases de datos y tablas del metaalmacén de Hive. Para obtener más información, consulte [Integración de Amazon EMR con Apache Ranger](emr-ranger.md).
+ Cuando necesita credenciales del LDAP para acceder a un clúster, obtiene un control de acceso detallado (FGAC) sobre quién puede acceder a sus clústeres de EMR a través de SSH.
En las siguientes páginas se proporciona información general conceptual, los requisitos previos y los pasos para lanzar un clúster de EMR con la integración del LDAP de Amazon EMR.
**Topics**
+ [Descripción general del LDAP con Amazon EMR](ldap-overview.md)
+ [Componentes del LDAP para Amazon EMR](ldap-components.md)
+ [Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR](ldap-considerations.md)
+ [Configuración y lanzamiento de un clúster de EMR con el LDAP](ldap-setup.md)
+ [Ejemplos de uso del LDAP con Amazon EMR](ldap-examples.md)
# Descripción general del LDAP con Amazon EMR
El protocolo ligero de acceso a directorios (LDAP) es un protocolo de software que los administradores de red utilizan para administrar y controlar el acceso a los datos mediante la autenticación de los usuarios dentro de la red de una empresa. El protocolo LDAP almacena la información en una estructura jerárquica de directorios en árbol. Para obtener más información, consulte [Basic LDAP Concepts](https://ldap.com/basic-ldap-concepts/) en *LDAP.com*.
Dentro de la red de una empresa, muchas aplicaciones pueden utilizar el protocolo LDAP para autenticar a los usuarios. Con la integración del LDAP de Amazon EMR, los clústeres de EMR pueden utilizar de forma nativa el mismo protocolo LDAP con una configuración de seguridad adicional.
Amazon EMR admite dos implementaciones principales del protocolo LDAP: **Active Directory** y **OpenLDAP**. Si bien son posibles otras implementaciones, la mayoría se ajusta a los mismos protocolos de autenticación que Active Directory u OpenLDAP.
## Active Directory (AD)
Active Directory (AD) es un servicio de directorios de Microsoft para redes de dominio de Windows. AD está incluido en la mayoría de los sistemas operativos Windows Server y puede comunicarse con los clientes a través de los protocolos LDAP y LDAPS. Amazon EMR intenta vincular un usuario a su instancia de AD con el nombre principal del usuario (UPN) como nombre distintivo y la contraseña para realizar la autenticación. El UPN utiliza el formato estándar `username@domain_name`.
## OpenLDAP
OpenLDAP es una implementación gratuita y de código abierto del protocolo LDAP. Para la autenticación, Amazon EMR intenta vincular un usuario a su instancia de OpenLDAP con el nombre de dominio completo (FQDN) como nombre distintivo y la contraseña. El FQDN utiliza el formato estándar `username_attribute=username,LDAP_user_search_base`. Por lo general, el valor `username_attribute` es `uid` y el valor `LDAP_user_search_base` contiene los atributos del árbol que conduce al usuario. Por ejemplo, `ou=People,dc=example,dc=com`.
Otras implementaciones gratuitas y de código abierto del protocolo LDAP suelen seguir un FQDN similar al de OpenLDAP para los nombres distintivos de sus usuarios.
# Componentes del LDAP para Amazon EMR
Puede usar su servidor LDAP para autenticarse con Amazon EMR y cualquier aplicación que el usuario utilice directamente en el clúster de EMR a través de los siguientes componentes.
**Agente secreto**
El *agente secreto* es un proceso que se ejecuta en el clúster que autentica todas las solicitudes de los usuarios. El agente secreto crea el enlace de usuario a su servidor LDAP en nombre de las aplicaciones compatibles en el clúster de EMR. El agente secreto se ejecuta como el usuario `emrsecretagent` y escribe registros en el directorio `/emr/secretagent/log`. Estos registros proporcionan detalles sobre el estado de la solicitud de autenticación de cada usuario y cualquier error que pueda surgir durante la autenticación del usuario.
**System Security Services Daemon (SSSD)**
*SSSD* es un daemon que se ejecuta en cada nodo de un clúster de EMR habilitado para el LDAP. SSSD crea y administra un usuario de UNIX para sincronizar su identidad corporativa remota con cada nodo. Las aplicaciones basadas en YARN, como Hive y Spark, requieren que haya un usuario local de UNIX en cada nodo que ejecute una consulta para un usuario.
# Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR
En este tema se enumeran las aplicaciones compatibles, las características compatibles y las características no compatibles.
## Aplicaciones compatibles con el LDAP para Amazon EMR
**importante**
Las aplicaciones que aparecen en esta página son las únicas aplicaciones que Amazon EMR admite para el LDAP. Para garantizar la seguridad del clúster, solo puede incluir aplicaciones compatibles con el LDAP al crear un clúster de EMR con el LDAP habilitado. Si intenta instalar otras aplicaciones no compatibles, Amazon EMR rechazará su solicitud de un nuevo clúster.
Las versiones 6.12 y posteriores de Amazon EMR admiten la integración del LDAP con las siguientes aplicaciones:
+ Apache Livy
+ Desde Apache Hive hasta HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
También puede instalar las siguientes aplicaciones en un clúster de EMR y configurarlas para que se ajusten a sus necesidades de seguridad:
+ Apache Spark
+ Apache Hadoop
## Características compatibles con el LDAP para Amazon EMR
Puede utilizar las siguientes características de Amazon EMR con la integración del LDAP:
**nota**
Para mantener seguras las credenciales del LDAP, debe utilizar el cifrado en tránsito para proteger el flujo de datos dentro y fuera del clúster. Para obtener más información sobre el cifrado en tránsito, consulte [Cifrar datos en reposo y en tránsito con Amazon EMR](emr-data-encryption.md).
+ Cifrado en reposo y en tránsito (obligatorio)
+ Grupos de instancias, flotas de instancias e instancias de spot
+ Reconfiguración de aplicaciones en un clúster en ejecución
+ Cifrado del servidor (SSE) de EMRFS
## Características no admitidas
Tenga en cuenta las siguientes limitaciones cuando utilice la integración del LDAP de Amazon EMR:
+ Amazon EMR deshabilita los pasos para los clústeres con el LDAP habilitado.
+ Amazon EMR no admite funciones e AWS Lake Formation integraciones de tiempo de ejecución para clústeres con LDAP habilitado.
+ Amazon EMR no admite el LDAP con StartTLS.
+ Amazon EMR no admite el modo de alta disponibilidad (clústeres con varios nodos principales) en los clústeres con el LDAP habilitado.
+ No puede vincular de forma rotativa las credenciales ni los certificados de los clústeres con el LDAP habilitado. Si alguno de esos campos se ha rotado, le recomendamos que inicie un clúster nuevo con las credenciales o certificados de vinculación actualizados.
+ Debe utilizar bases de búsqueda exactas con LDAP. La base de búsqueda de usuarios y grupos de LDAP no admite los filtros de búsqueda de LDAP.
# Configuración y lanzamiento de un clúster de EMR con el LDAP
En esta sección, se explica cómo configurar Amazon EMR para su uso con la autenticación LDAP.
**Topics**
+ [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md)
+ [Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP](ldap-setup-security.md)
+ [Lanzamiento de un clúster de EMR que se autentique con LDAP](ldap-setup-launch.md)
# Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR
Amazon EMR utiliza un rol de servicio de IAM para realizar acciones en su nombre para aprovisionar y administrar clústeres. El rol de servicio para instancias de EC2 de clúster, también conocido como el *perfil de instancia de EC2 para Amazon EMR*, es un tipo especial de rol de servicio que Amazon EMR asigna a cada instancia de EC2 de un clúster en el momento del lanzamiento.
Para definir los permisos para que un clúster de EMR interactúe con los datos de Amazon S3 y otros productos de AWS , defina un perfil de instancia de Amazon EC2 personalizado en lugar de `EMR_EC2_DefaultRole` al lanzar el clúster. Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md) y [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md).
Añada las siguientes instrucciones al perfil de instancia EC2 predeterminado para permitir que Amazon EMR etiquete las sesiones y acceda al que almacena AWS Secrets Manager los 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**
Las solicitudes de clúster fallarán si olvida agregar el carácter comodín `*` al final del nombre del secreto al configurar los permisos de Secrets Manager. El comodín representa las versiones secretas.
También debe limitar el alcance de la AWS Secrets Manager política a solo los certificados que su clúster necesita para aprovisionar instancias.
# Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP
Antes de lanzar un clúster de EMR con integración del LDAP, siga los pasos de [Cree una configuración de seguridad con la consola Amazon EMR o con AWS CLI](emr-create-security-configuration.md) para crear una configuración de seguridad de Amazon EMR para el clúster. Complete las siguientes configuraciones en el bloque `LDAPConfiguration` en `AuthenticationConfiguration` o en los campos correspondientes de la sección **Configuraciones de seguridad** de la consola de Amazon EMR:
**`EnableLDAPAuthentication`**
Opción de consola: **Protocolo de autenticación: LDAP**
Para usar la integración del LDAP, establezca esta opción en `true` o selecciónela como protocolo de autenticación al crear un clúster en la consola. De forma predeterminada, `EnableLDAPAuthentication` es `true` cuando crea una configuración de seguridad en la consola de Amazon EMR.
**`LDAPServerURL`**
Opción de consola: **ubicación del servidor LDAP**
La ubicación del servidor LDAP, incluido el prefijo: `ldaps://location_of_server`.
**`BindCertificateARN`**
Opción de consola: **Certificado SSL del LDAP**
El AWS Secrets Manager ARN que contiene el certificado para firmar el certificado SSL que utiliza el servidor LDAP. Si su servidor LDAP está firmado por una autoridad de certificación (CA) pública, puede proporcionar un AWS Secrets Manager ARN con un archivo en blanco. Para obtener más información sobre cómo almacenar el certificado en Secrets Manager, consulte [Guarde los certificados TLS en AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opción de consola: **credenciales de vinculación del servidor LDAP**
Un AWS Secrets Manager ARN que contiene las credenciales de enlace de usuario administrador de LDAP. Las credenciales se almacenan como un objeto JSON. Solo hay un par clave-valor en este secreto; la clave del par es el nombre de usuario y el valor es la contraseña. Por ejemplo, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Este campo es opcional, a menos que habilite el inicio de sesión SSH para su clúster de EMR. En muchas configuraciones, las instancias de Active Directory requieren credenciales de vinculación para permitir que SSSD sincronice los usuarios.
**`LDAPAccessFilter`**
Opción de consola: **filtro de acceso del LDAP**
Especifica el subconjunto de objetos del servidor LDAP que pueden autenticarse. Por ejemplo, si desea conceder acceso a todos los usuarios con la clase de objeto `posixAccount` de su servidor LDAP, defina el filtro de acceso como `(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opción de consola: **base de búsqueda de usuarios de LDAP**
La base de búsqueda a la que pertenecen sus usuarios en su servidor LDAP. Por ejemplo, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Opción de consola: **base de búsqueda de grupos LDAP**
La base de búsqueda a la que pertenecen sus grupos dentro de su servidor LDAP. Por ejemplo, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Opción de consola: **inicio de sesión SSH**
Especifica si se permite o no la autenticación por contraseña con credenciales del LDAP. No le recomendamos habilitar esta opción. Los pares de claves son una ruta más segura para permitir el acceso a los clústeres de EMR. Este campo es opcional y de forma predeterminada es `false`.
**`LDAPServerType`**
Opción de consola: **tipo de servidor LDAP**
Especifica el tipo de servidor LDAP al que se conecta Amazon EMR. Las opciones compatibles son Active Directory y OpenLDAP. Es posible que otros tipos de servidores LDAP funcionen, pero Amazon EMR no admite oficialmente otros tipos de servidores. Para obtener más información, consulte [Componentes del LDAP para Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Un subbloque obligatorio para las configuraciones de seguridad que utilizan el tipo de servidor Active Directory.
**`ADDomain`**
Opción de consola: **dominio de Active Directory**
El nombre de dominio utilizado para crear el nombre principal de usuario (UPN) para la autenticación del usuario con configuraciones de seguridad que utilizan el tipo de servidor Active Directory.
## Aspectos que hay que tener en cuenta para realizar las configuraciones de seguridad con el LDAP y Amazon EMR
+ Para crear una configuración de seguridad con la integración del LDAP de Amazon EMR, debe utilizar el cifrado en tránsito. Para obtener información sobre el cifrado en tránsito, consulte [Cifrar datos en reposo y en tránsito con Amazon EMR](emr-data-encryption.md).
+ No puede definir la configuración de Kerberos en la misma configuración de seguridad. Amazon EMR aprovisiona un KDC dedicado al KDC de forma automática y administra la contraseña de administrador de este KDC. Los usuarios no pueden acceder a esta contraseña de administrador.
+ No puede definir las funciones de tiempo de ejecución de IAM ni AWS Lake Formation en la misma configuración de seguridad.
+ La `LDAPServerURL` debe tener el protocolo `ldaps://` en su valor.
+ El `LDAPAccessFilter` no puede estar vacío.
## Uso del LDAP con la integración de Apache Ranger para Amazon EMR
Con la integración del LDAP para Amazon EMR, puede ampliar su integración con Apache Ranger. Cuando extraiga sus usuarios del LDAP en Ranger, podrá asociarlos a un servidor de políticas de Apache Ranger para integrarlos con Amazon EMR y otras aplicaciones. Para ello, defina el campo `RangerConfiguration` de la configuración de seguridad que `AuthorizationConfiguration` va a utilizar con el clúster del LDAP. Para obtener más información acerca de cómo definir la configuración de seguridad, consulte [Creación de la configuración de seguridad de EMR](emr-ranger-security-config.md).
Cuando utilice el LDAP con Amazon EMR, no tendrá que proporcionar una `KerberosConfiguration` con la integración de Amazon EMR para Apache Ranger.
# Lanzamiento de un clúster de EMR que se autentique con LDAP
Siga estos pasos para lanzar un clúster de EMR con el LDAP o Active Directory:
1. Configure su entorno:
+ Asegúrese de que los nodos del clúster de EMR puedan comunicarse con Amazon S3 y. AWS Secrets Manager Para obtener más información sobre cómo modificar el rol de su perfil de instancia de EC2 para comunicarse con estos servicios, consulte [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md).
+ Si planea ejecutar su clúster de EMR en una subred privada, debe usar puntos de enlace de AWS PrivateLink Amazon VPC o usar la traducción de direcciones de red (NAT) para configurar la VPC de manera que se comunique con S3 y Secrets Manager. Para obtener más información, consulte [AWS PrivateLink y puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) e [Instancias NAT](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) en la *Guía de introducción a Amazon VPC*.
+ Asegúrese de que haya conectividad de red entre el clúster de EMR y el servidor LDAP. Los clústeres de EMR deben acceder a su servidor LDAP a través de la red. Los nodos principal, central y de tareas del clúster se comunican con el servidor LDAP para sincronizar los datos de los usuarios. Si su servidor LDAP se ejecuta en Amazon EC2, actualice el grupo de seguridad de EC2 para que acepte el tráfico del clúster de EMR. Para obtener más información, consulte [Añadir AWS Secrets Manager permisos al rol de instancia de Amazon EMR](ldap-setup-asm.md).
1. Cree una configuración de seguridad de Amazon EMR para la integración del LDAP. Para obtener más información, consulte [Creación de la configuración de seguridad de Amazon EMR para la integración con el LDAP](ldap-setup-security.md).
1. Una vez completada la configuración, siga los pasos de [Lanzar un clúster de Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) para lanzar el clúster con las siguientes configuraciones:
+ Seleccione Amazon EMR versión 6.12 o superior. Le recomendamos utilizar la última versión de Amazon EMR.
+ Especifique o seleccione únicamente las aplicaciones de su clúster que admitan el LDAP. Para obtener una lista de las aplicaciones que admitan el LDAP con Amazon EMR, consulte [Compatibilidad de aplicaciones y consideraciones que hay que tener en cuenta sobre el LDAP para Amazon EMR](ldap-considerations.md).
+ Aplique la configuración de seguridad que creó en el paso anterior.
# Ejemplos de uso del LDAP con Amazon EMR
Una vez que [aprovisione un clúster de EMR que utilice la integración del LDAP](ldap-setup-launch.md), podrá proporcionar sus credenciales de LDAP a cualquier [aplicación compatible](ldap-considerations.md#ldap-considerations-apps) mediante su mecanismo de autenticación de nombre de usuario y contraseña integrado. Esta página muestra algunos ejemplos.
## Uso de la autenticación LDAP con Apache Hive
**Example : Apache Hive**
El siguiente comando de ejemplo inicia una sesión de Apache Hive a través de 2 y Beeline: HiveServer
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Uso de la autenticación LDAP con Apache Livy
**Example : Apache Livy**
El siguiente comando de ejemplo inicia una sesión de Livy a través de cURL. Sustituya `ENCODED-KEYPAIR` por una cadena cifrada en Base64 para `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
```
## Uso de la autenticación LDAP con Presto
**Example : Presto**
El siguiente comando de ejemplo inicia una sesión de Presto a través de la CLI de Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
## Uso de la autenticación LDAP con Trino
**Example : Trino**
El siguiente comando de ejemplo inicia una sesión de Trino a través de la CLI de Trino:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
## Uso de la autenticación LDAP con Hue
Puede acceder a la interfaz de usuario de Hue a través de un túnel SSH que cree en el clúster, o bien puede configurar un servidor proxy para que transmita públicamente la conexión a Hue. Como Hue no se ejecuta en modo HTTPS de forma predeterminada, le recomendamos que utilice una capa de cifrado adicional para garantizar que la comunicación entre los clientes y la interfaz de usuario de Hue esté cifrada con HTTPS. Esto reduce la posibilidad de que exponga accidentalmente las credenciales de usuario en texto sin formato.
Para usar la interfaz de usuario de Hue, abra la interfaz de usuario de Hue en su navegador e ingrese la contraseña y su nombre de usuario del LDAP para iniciar sesión. Si las credenciales son correctas, Hue inicia sesión y usa su identidad para que pueda autenticarse en todas las aplicaciones compatibles.
## Uso de SSH para la autenticación por contraseña y tickets de Kerberos para otras aplicaciones
**importante**
No le recomendamos autenticarse por contraseña para conectarse vía SSH a un clúster de EMR.
Puede usar sus credenciales del LDAP para conectarse vía SSH a un clúster de EMR. Para ello, establezca la configuración `EnableSSHLogin` en `true` en la configuración de seguridad de Amazon EMR que utilice para iniciar el clúster. Cuando se lance el clúster, use el siguiente comando para conectarse vía SSH en el clúster:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Tras ejecutar este comando, ingrese la contraseña de LDAP cuando se solicite.
Amazon EMR incluye un script en el clúster que permite a los usuarios generar un archivo keytab y un ticket de Kerberos para usarlos con aplicaciones compatibles que no aceptan credenciales del LDAP directamente. Algunas de estas aplicaciones incluyen `spark-submit` Spark SQL y. PySpark
Ejecute `ldap-kinit` y siga las instrucciones. Si la autenticación se realiza correctamente, el archivo keytab de Kerberos aparecerá en su directorio principal con un ticket de Kerberos válido. Utilice el ticket de Kerberos para ejecutar aplicaciones como lo haría en cualquier entorno kerberizado.
# Integre Amazon EMR con AWS IAM Identity Center
Con las versiones 6.15.0 y posteriores de Amazon EMR, puede utilizar las identidades de AWS IAM Identity Center para autenticarse con un clúster de Amazon EMR. En las siguientes páginas, se proporciona información general conceptual, los requisitos previos y los pasos para lanzar un clúster de EMR con la integración de Identity Center.
**Topics**
+ [Descripción general de](#emr-idc-overview)
+ [Características y ventajas](#emr-idc-features)
+ [Primeros pasos con AWS IAM Identity Center Amazon EMR](emr-idc-start.md)
+ [Sesiones de usuario en segundo plano](user-background-sessions.md)
+ [Consideraciones y limitaciones de Amazon EMR con la integración de Identity Center](emr-idc-considerations.md)
## Descripción general de
[Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) es el enfoque recomendado para la autenticación y autorización de los empleados en organizaciones de cualquier AWS tamaño y tipo. Con Identity Center, puede crear y administrar identidades de usuario o conectar su fuente de identidad existente, que incluye Microsoft Active Directory, Okta, Ping Identity JumpCloud, Google Workspace y Microsoft Entra ID (anteriormente Azure AD). AWS
[La propagación de identidades fiable](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html) es una AWS IAM Identity Center función que los administradores de Connected Servicios de AWS pueden utilizar para conceder y auditar el acceso a los datos del servicio. El acceso a estos datos se basa en los atributos del usuario, como las asociaciones de grupo. La configuración de una propagación de identidad fiable requiere la colaboración entre los administradores de Connected Servicios de AWS y los administradores del IAM Identity Center. Para obtener más información, consulte [Requisitos previos y consideraciones](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html).
## Características y ventajas
La integración de Amazon EMR con IAM Identity Center ofrece los siguientes beneficios:
+ Amazon EMR proporciona credenciales para transmitir una identidad de Identity Center a un clúster de EMR.
+ Amazon EMR configura todas las aplicaciones compatibles para que se autentiquen con las credenciales del clúster.
+ Amazon EMR configura y mantiene la seguridad de las aplicaciones compatibles con el protocolo de Kerberos, por lo que no se necesitan comandos ni scripts.
+ La capacidad de aplicar la autorización a nivel de prefijo de Amazon S3 con las identidades de Identity Center en los prefijos de S3 administrados por S3 Access Grants.
+ La capacidad de hacer cumplir la autorización a nivel de tabla con las identidades de Identity Center en las tablas AWS Lake Formation AWS Glue gestionadas.
# Primeros pasos con AWS IAM Identity Center Amazon EMR
Esta sección le ayuda a configurar Amazon EMR para que se integre con. AWS IAM Identity Center
**Topics**
+ [Creación de una instancia de Identity Center](#emr-idc-start-instance)
+ [Creación de un rol de IAM para Identity Center](#emr-idc-start-role)
+ [Agregue permisos para los servicios que no están integrados con IAM Identity Center](#emr-idc-start-securityconfig-nonidc)
+ [Creación de una configuración de seguridad habilitada por Identity Center](#emr-idc-start-securityconfig)
+ [Creación y lanzamiento de un clúster habilitado por Identity Center](#emr-idc-cluster)
+ [Configuración de Lake Formation para un clúster de EMR habilitado por IAM Identity Center](emr-idc-lf.md)
+ [Cómo trabajar con S3 Access Grants en un clúster de EMR habilitado por IAM Identity Center](emr-idc-s3ag.md)
**nota**
Para utilizar la integración de Identity Center con EMR, Lake Formation o Concesiones de acceso a S3 deben estar habilitados. También puede usar ambos. Si ninguna de las dos está habilitada, no se admite la integración de Identity Center.
## Creación de una instancia de Identity Center
Si aún no tiene una instancia de Identity Center, cree una en la Región de AWS en la que desea lanzar el clúster de EMR. Una instancia de Identity Center solo puede existir en una sola región para una Cuenta de AWS.
Use el siguiente AWS CLI comando para crear una nueva instancia con el nombre`MyInstance`:
```
aws sso-admin create-instance --name MyInstance
```
## Creación de un rol de IAM para Identity Center
Para integrar Amazon EMR con AWS IAM Identity Center, cree un rol de IAM que se autentique con Identity Center desde el clúster de EMR. Amazon EMR también utiliza credenciales SigV4 para transmitir la identidad de Identity Center a servicios posteriores, como AWS Lake Formation. El rol también debe tener los permisos correspondientes para invocar los servicios posteriores.
Al crear el rol, utilice la siguiente política de permisos:
```
{
"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": "*"
}
]
}
```
La política de confianza de este rol permite que el rol InstanceProfile deje asumir el rol.
```
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678912:role/EMR_EC2_DefaultRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetContext"
]
}
```
Si el rol no tiene credenciales de confianza y accede a una tabla protegida por Lake Formation, Amazon EMR establece automáticamente el `principalId` del rol asumido en `userID-untrusted`. El siguiente es un fragmento de un evento que muestra el. CloudTrail `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"
...
```
## Agregue permisos para los servicios que no están integrados con IAM Identity Center
AWS credenciales que utilizan Trusted Identity Propagation: las políticas de IAM definidas en la función de IAM para cualquier llamada realizada a servicios que no estén integrados con el IAM Identity Center. Esto incluye, por ejemplo, el. AWS Key Management Service Su rol también debe definir los permisos de IAM para cualquiera de estos servicios a los que intente acceder, por ejemplo, AWS Key Management Service. Los servicios integrados del IAM Identity Center actualmente compatibles incluyen AWS Lake Formation y Concesiones de acceso a Amazon S3.
Para obtener más información sobre la propagación de identidades de confianza, consulte [Trusted Identity Propagation across applications](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation.html).
## Creación de una configuración de seguridad habilitada por Identity Center
Para lanzar un clúster de EMR con la integración de IAM Identity Center, utilice el siguiente comando de ejemplo para crear una configuración de seguridad de Amazon EMR que tenga Identity Center habilitado. A continuación, se explica cada configuración.
```
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`**: (obligatorio) habilita la integración de Identity Center.
+ **`IdentityCenterInstanceARN`**: (obligatorio). El ARN de la instancia del Identity Center. Si no se incluye, se busca el ARN de la instancia del IAM Identity Center existente como parte del paso de configuración.
+ **`IAMRoleForEMRIdentityCenterApplicationARN`**: (obligatorio) el rol de IAM que obtiene los tokens de Identity Center del clúster.
+ **`IdentityCenterApplicationAssignmentRequired `**: (booleano) determina si será necesaria una asignación para utilizar la aplicación de Identity Center. Este campo es opcional. Si no se proporciona un valor, se utiliza el valor predeterminado `false`.
+ **`AuthorizationConfiguration` / `LakeFormationConfiguration`**: si lo desea, configure la autenticación:
+ **`IAMConfiguration`**: habilita la característica de roles de tiempo de ejecución de EMR además de su identidad TIP. Si habilita esta configuración, usted (o el AWS servicio que llama) deberán especificar un rol de tiempo de ejecución de IAM en cada llamada a EMR Steps o EMR. `GetClusterSessionCredentials` APIs Si el clúster de EMR se usa con SageMaker Unified Studio, esta opción es necesaria si la propagación de identidad confiable también está habilitada.
+ **`EnableLakeFormation`**: habilita la autorización de Lake Formation en el clúster.
Para habilitar la integración de Identity Center con Amazon EMR, debe especificar `EncryptionConfiguration` y `IntransitEncryptionConfiguration`.
## Creación y lanzamiento de un clúster habilitado por Identity Center
Ahora que configuró el rol de IAM que se autentica con Identity Center y creó una configuración de seguridad de Amazon EMR que tiene Identity Center habilitado, puede crear y lanzar un clúster con reconocimiento de identidad. Para ver los pasos para lanzar el clúster con la configuración de seguridad requerida, consulte [Especificar una configuración de seguridad para un clúster de Amazon EMR](emr-specify-security-configuration.md).
En las siguientes secciones, se describe cómo configurar el clúster habilitado por Identity Center con las opciones de seguridad compatibles con Amazon EMR:
+ [Cómo trabajar con S3 Access Grants en un clúster de EMR habilitado por IAM Identity Center](emr-idc-s3ag.md)
+ [Configuración de Lake Formation para un clúster de EMR habilitado por IAM Identity Center](emr-idc-lf.md)
# Configuración de Lake Formation para un clúster de EMR habilitado por IAM Identity Center
Puede integrarlo [AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/)con su clúster de EMR AWS IAM Identity Center habilitado.
En primer lugar, asegúrese de tener una instancia de Identity Center configurada en la misma región que el clúster. Para obtener más información, consulte [Creación de una instancia de Identity Center](emr-idc-start.md#emr-idc-start-instance). Puede encontrar el ARN de la instancia en la consola de IAM Identity Center en los detalles de la instancia o utilizar el siguiente comando para ver los detalles de todas las instancias desde la CLI:
```
aws sso-admin list-instances
```
A continuación, utilice el ARN y el ID de su AWS cuenta con el siguiente comando para configurar Lake Formation para que sea compatible con 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"
}
```
Ahora, llame a `put-data-lake-settings` y habilite `AllowFullTableExternalDataAccess` con 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 último, conceda permisos de tabla completos al ARN de identidad para el usuario que accede al clúster de EMR. El ARN contiene el ID de usuario de Identity Center. Vaya a Identity Center en la consola, seleccione **Usuarios** y, a continuación, seleccione el usuario para ver su configuración de **Información general**.
Copie el ID de usuario y péguelo en el siguiente ARN para `user-id`:
```
arn:aws:identitystore:::user/user-id
```
**nota**
Las consultas en el clúster de EMR solo funcionan si la identidad de IAM Identity Center tiene acceso total a la tabla protegida de Lake Formation. Si la identidad no tiene acceso total a la tabla, la consulta fallará.
Utilice el siguiente comando para conceder al usuario acceso total a la tabla:
```
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"
]
}
```
## Cómo agregar el ARN de la aplicación en IDC para la integración con Lake Formation
Para consultar recursos habilitados con Lake Formation, debe agregar el ARN de la aplicación de IDC. Para ello, sigue estos pasos:
1. En la consola, seleccione **AWS Lake Formation**.
1. Elija **Integración con IAM Identity Center** e **Integración de Lake Formation con la aplicación**, y relacione el ARN de la aplicación. El ARN aparecerá en la lista **ID de la aplicación**.
# Cómo trabajar con S3 Access Grants en un clúster de EMR habilitado por IAM Identity Center
Puede integrar [S3 Access Grants](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-grants.html) con su clúster de EMR AWS IAM Identity Center habilitado.
Utilice S3 Access Grants para autorizar el acceso a los conjuntos de datos desde los clústeres que utilizan Identity Center. Cree concesiones para aumentar los permisos que configura para usuarios, grupos o roles de IAM o para un directorio corporativo. Para obtener más información, consulte [Uso de S3 Access Grants con Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-access-grants.html).
**Topics**
+ [Cómo crear una instancia y una ubicación de S3 Access Grants](#emr-idc-s3ag-instance)
+ [Creación de concesiones para las identidades de Identity Center](#emr-idc-s3ag-identities)
## Cómo crear una instancia y una ubicación de S3 Access Grants
Si aún no tiene una instancia de S3 Access Grants, cree una en la Región de AWS en la que desea lanzar el clúster de EMR.
Use el siguiente AWS CLI comando para crear una nueva instancia con el nombre`MyInstance`:
```
aws s3control-access-grants create-access-grants-instance \
--account-id 12345678912 \
--identity-center-arn "identity-center-instance-arn" \
```
A continuación, cree una ubicación de S3 Access Grants y reemplace los valores en color rojo por los suyos:
```
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 el parámetro `iam-role-arn` como ARN de `accessGrantRole`.
## Creación de concesiones para las identidades de Identity Center
Por último, cree las concesiones para las identidades que tienen acceso al clúster:
```
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"
```
Ejemplo de salida:
```
{
"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/*"
}
```
# Sesiones de usuario en segundo plano
Las sesiones de usuario en segundo plano permiten que las cargas de trabajo de análisis y machine learning de larga duración continúen incluso después de que el usuario haya cerrado sesión en la interfaz de su cuaderno. A partir de EMR en la versión 7.11 de EC2, esta capacidad está disponible a través de la función confiable de propagación de identidades de EMR-EC2. En las siguientes secciones se explican las opciones de configuración y los comportamientos de las sesiones en segundo plano de los usuarios.
**nota**
La configuración de la sesión en segundo plano del usuario solo afecta a las cargas de trabajo de Spark lanzadas a través de SageMaker Unified Studio. Los cambios en esta configuración se aplican a las nuevas sesiones de Livy; las sesiones activas existentes no se ven afectadas.
## Configuración de sesiones de usuario en segundo plano
Las sesiones de usuario en segundo plano deben estar habilitadas en dos niveles para que funcionen correctamente:
1. **Nivel de instancia del IAM Identity Center** (configurado por los administradores de iDC)
1. **Nivel de clúster de EMR** (configurado por los administradores de clústeres de EMR)
### Habilitar sesiones de usuario en segundo plano para Amazon EMR
Para habilitar las sesiones de usuario en segundo plano, debe establecer el `userBackgroundSessionsEnabled` parámetro `true` en la configuración de seguridad `identityCenterConfiguration` al crear EMR.
**Requisitos previos**:
+ El rol de IAM utilizado para crear o actualizar la configuración de seguridad de EMR requiere `sso:PutApplicationSessionConfiguration` el permiso. Este permiso habilita las sesiones de usuario en segundo plano para la aplicación IAM Identity Center gestionada por Amazon EMR.
+ Cree un rol de IAM para el Centro de Identidad de IAM
+ Para integrar Amazon EMR con el Centro de identidades de IAM, cree un rol de IAM que se autentique con el Centro de identidades de IAM desde el clúster de EMR. Amazon EMR utiliza las credenciales SiGv4 para transmitir la identidad del centro de identidad de IAM a los servicios descendentes, como. AWS Lake Formation Su función también debe tener los permisos necesarios para invocar los servicios descendentes.
+ [Configure Lake Formation para un clúster de EMR habilitado para el IAM Identity Center](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html). Para obtener los permisos de rol necesarios, consulte: [Crear un rol de IAM para](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-start.html#emr-idc-start-role) Identity Center.
+ Inicie su clúster de EMR con la versión 7.11 o posterior y habilite la propagación de identidades confiables.
**Paso 1: Crear una configuración de seguridad EMR UserBackgroundSession habilitada para Identity Center**
Los usuarios deben configurar el `EnableUserBackgroundSession` **indicador** en`true`, lo que permitirá que el servicio de EMR se habilite en el nivel de aplicación de IDC gestionada por UserBackgourndSession EMR. Si este indicador está establecido `false` o no, EMR deshabilitará IDC UserBackgroundSession de forma predeterminada.
**Ejemplo de uso de: 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"
}
}
}
}'
```
**Paso 2: Crear y lanzar un clúster habilitado para Identity Center**
Ahora que configuró el rol de IAM que se autentica con Identity Center y creó una configuración de seguridad de Amazon EMR que tiene Identity Center habilitado, puede crear y lanzar un clúster con reconocimiento de identidad. Para ver los pasos para lanzar el clúster con la configuración de seguridad requerida, consulte Especificar una configuración de seguridad para un clúster de Amazon EMR.
### Matriz de configuración
El comportamiento de la sesión en segundo plano del usuario depende tanto de la configuración de EMR-EC2 como de la configuración a nivel de instancia de IAM Identity Center:
**Matriz de configuración de sesiones de usuario en segundo plano**
| Centro userBackgroundSession de identidad de IAM activado | Amazon EMR activado userBackgroundSessions | Comportamiento |
| --- | --- | --- |
| Sí | TRUE | Sesión de usuario en segundo plano habilitada |
| Sí | FALSO | La sesión caduca al cerrar sesión del usuario |
| No | TRUE | La sesión caduca al cerrar sesión del usuario |
| No | FALSO | La sesión caduca al cerrar sesión del usuario |
### Duración predeterminada de la sesión de usuario en segundo plano
De forma predeterminada, todas las sesiones de usuario en segundo plano tienen un límite de duración de 7 días en IAM Identity Center. Los administradores pueden modificar esta duración en la consola de IAM Identity Center. Esta configuración se aplica a la instancia de IAM Identity Center y afecta a todas las aplicaciones de IAM Identity Center dentro de dicha instancia.
+ La duración se puede establecer en cualquier valor, desde 15 minutos hasta 90 días.
+ Este ajuste se configura en la consola del IAM Identity Center, en **Ajustes** → **Autenticación** → **Configurar** (consulte la sección Trabajos no interactivos)
### Impacto de la deshabilitación de las sesiones en segundo plano de los usuarios
Cuando las sesiones de usuario en segundo plano están deshabilitadas en el IAM Identity Center:
Sesiones de Livy existentes
+ Continúan ejecutándose sin interrupción si se iniciaron con las sesiones de usuario en segundo plano habilitadas. Estas sesiones seguirán utilizando sus identificadores de sesión en segundo plano hasta que finalicen de forma natural o se detengan explícitamente.
Nuevas sesiones de Livy
+ Utilizará el flujo de propagación de identidad confiable estándar y finalizará cuando el usuario cierre la sesión o caduque su sesión interactiva (por ejemplo, al cerrar un JupyterLab bloc de notas de Amazon SageMaker Unified Studio).
### Cambio de la duración de las sesiones en segundo plano de los usuarios
Cuando se modifica la configuración de duración de las sesiones en segundo plano de los usuarios en IAM Identity Center:
Sesiones de Livy existentes
+ Continúe ejecutándose con la misma duración de sesión en segundo plano con la que se iniciaron.
Nuevas sesiones de Livy
+ Utilizará la nueva duración de la sesión para las sesiones en segundo plano.
### Consideraciones
#### Disponibilidad de características
Las sesiones de usuario en segundo plano para Amazon EMR están disponibles para:
+ Solo el motor Spark (no se admite el motor Hive)
+ Solo sesiones interactivas de Livy (no se admiten los trabajos por lotes ni los trabajos de streaming)
+ Amazon EMR lanza etiquetas 7.11 y versiones posteriores. Con la versión 7.11 de EMR, debe instalar un script de acciones de arranque para habilitar las sesiones en segundo plano del usuario al crear un clúster. Póngase en contacto con AWS Support para obtener más información.
**nota**
Si utiliza un clúster aprovisionado de SageMaker Unified Studio, no necesita el script de acciones de arranque para utilizar esta función.
#### Implicaciones de costos
+ Los trabajos seguirán ejecutándose hasta completarse incluso después de que los usuarios finalicen su JupyterLab sesión de Amazon SageMaker Unified Studio y se cobrarán durante toda la ejecución.
+ Supervise sus sesiones en segundo plano activas para evitar costes innecesarios derivados de sesiones olvidadas o abandonadas.
#### Condiciones de finalización de la sesión de Livy
Cuando se utilizan sesiones de usuario en segundo plano, las sesiones de Livy seguirán ejecutándose hasta que se produzca una de las siguientes situaciones:
+ La sesión en segundo plano del usuario caduca (según la configuración de iDC, hasta 90 días).
+ Un administrador revoca manualmente la sesión del usuario en segundo plano.
+ La sesión de Livy alcanza su tiempo de espera de inactividad (predeterminado: 8 horas después de la última sentencia ejecutada).
+ El usuario detiene o reinicia el núcleo del portátil de forma explícita.
# Consideraciones y limitaciones de Amazon EMR con la integración de Identity Center
Tenga en cuenta los siguientes puntos cuando utilice IAM Identity Center con Amazon EMR:
+ La propagación de identidades de confianza a través de Identity Center es compatible con Amazon EMR 6.15.0 y versiones posteriores, y solo con Apache Spark. Además, la propagación de identidades de confianza a través de Identity Center con la característica de roles de tiempo de ejecución de EMR está disponible a partir de Amazon EMR 7.8.0 y solo funciona con Apache Spark.
+ Para habilitar los clústeres de EMR con propagación de identidades de confianza, debe usar AWS CLI para crear una configuración de seguridad que tenga habilitada la propagación de identidades de confianza y usar esa configuración de seguridad al lanzar el clúster. Para obtener más información, consulte [Creación de una configuración de seguridad habilitada por Identity Center](emr-idc-start.md#emr-idc-start-securityconfig).
+ Los controles de acceso detallados AWS Lake Formation que utilizan la propagación de identidad confiable están disponibles para los clústeres de Amazon EMR en la versión 7.2.0 y versiones posteriores de EMR. Entre las versiones 6.15.0 y 7.1.0 de EMR, solo está disponible el control de acceso a nivel de mesa, basado en Lake Formation. AWS
+ Con los clústeres de Amazon EMR que utilizan la propagación de identidades de confianza, las operaciones que admiten el control de acceso basado en Lake Formation con Apache Spark incluyen SELECT, ALTER TABLE, INSERT INTO y DROP TABLE.
+ Los controles de acceso detallados AWS Lake Formation que utilizan Trusted Identity Propagation deberán actualizar la configuración del Lake Formation Identity Center añadiendo el arn de la aplicación de identidad de IAM gestionada por EMR como objetivo autorizado. Puede encontrar el ARN de la aplicación administrada por IAM para Amazon EMR mediante la API de EMR `describe-security-configure` y buscar el campo `IdCApplicationARN`. Para más detalles sobre cómo configurar Lake Formation con IAM Identity Center, consulte [Actualización de la integración de IAM Identity Center](https://docs.aws.amazon.com/lake-formation/latest/dg/update-lf-identity-center-connection.html).
+ Para utilizar controles de acceso detallados AWS Lake Formation que utilicen Trusted Identity Propagation, los usuarios de IAM Identity deben tener permisos de Lake Formation en la base de datos predeterminada. Para más información, consulte [Configure Lake Formation for an IAM Identity Center enabled EMR cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-idc-lf.html).
+ La propagación de identidad confiable con Amazon EMR se admite en los siguientes casos: Regiones de AWS
+ `af-south-1`: África (Ciudad del Cabo)
+ `ap-east-1`: Asia-Pacífico (Hong Kong)
+ `ap-northeast-1`: Asia Pacífico (Tokio)
+ `ap-northeast-2`: Asia-Pacífico (Seúl)
+ `ap-northeast-3`: Asia-Pacífico (Osaka)
+ `ap-south-1`: Asia-Pacífico (Mumbai)
+ `ap-south-2`: Asia-Pacífico (Hyderabad)
+ `ap-southeast-1`: Asia Pacífico (Singapur)
+ `ap-southeast-2`: Asia Pacífico (Sídney)
+ `ap-southeast-3`: Asia-Pacífico (Yakarta)
+ `ap-southeast-4`: Asia-Pacífico (Melbourne)
+ `ca-central-1`: Canadá (centro)
+ `eu-central-1`: Europa (Fráncfort)
+ `eu-central-2`: Europa (Zúrich)
+ `eu-north-1`: Europa (Estocolmo)
+ `eu-south-1`: Europa (Milán)
+ `eu-south-2`: Europa (España)
+ `eu-west-1`: Europa (Irlanda)
+ `eu-west-2`: Europa (Londres)
+ `eu-west-3`: Europa (París)
+ `il-central-1`: Israel (Tel Aviv)
+ `me-central-1`: Oriente-Medio (EAU)
+ `me-south-1`: Medio Oriente (Baréin)
+ `sa-east-1`: América del Sur (São Paulo)
+ `us-east-1`: Este de EE. UU. (Norte de Virginia)
+ `us-east-2`: Este de EE. UU. (Ohio)
+ `us-west-1`: Oeste de EE. UU. (Norte de California)
+ `us-west-2`: Oeste de EE. UU. (Oregón)
+ Si el rol de IAM del rol del centro de identidad se elimina y se vuelve a crear accidentalmente, el principal tendrá un identificador principal diferente. Por ejemplo, *NewRole* tendría un identificador principal *456* que no coincidiría con el identificador principal registrado. *123* La única forma de resolver este problema en este momento es volver a establecer el principal en las políticas de recursos descendentes de cada cuenta descendente.
# Integre Amazon EMR con AWS Lake Formation
AWS Lake Formation es un servicio gestionado que le ayuda a descubrir, catalogar, limpiar y proteger los datos de un lago de datos de Amazon Simple Storage Service (S3). Lake Formation proporciona un acceso detallado a nivel de columna, fila o celda a las bases de datos y tablas del catálogo de datos de AWS Glue. Para obtener más información, consulte [¿Qué es AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
Con las versiones 6.7.0 y posteriores de Amazon EMR, puede aplicar un control de acceso basado en Lake Formation a los trabajos de Spark, Hive y Presto que envíe a los clústeres de Amazon EMR. Para integrar con Lake Formation, debe crear un clúster de EMR con un *rol en tiempo de ejecución*. Un rol en tiempo de ejecución es un rol de AWS Identity and Access Management (IAM) que se asocia a los trabajos o consultas de Amazon EMR. A continuación, Amazon EMR utiliza esta función para acceder AWS a los recursos. Para obtener más información, consulte [Roles en tiempo de ejecución para los pasos de Amazon EMR](emr-steps-runtime-roles.md).
## Cómo funciona Amazon EMR con Lake Formation
Tras integrar Amazon EMR con Lake Formation, puede ejecutar consultas a los clústeres de Amazon EMR con la [`Step`API o con AI Studio](https://docs.aws.amazon.com/emr/latest/APIReference/API_Step.html). SageMaker Luego, Lake Formation proporciona acceso a los datos a través de credenciales temporales para Amazon EMR. Este proceso se denomina “expedición de credenciales”. Para obtener más información, consulte [¿Qué es AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
A continuación, se ofrece una descripción general de alto nivel sobre cómo Amazon EMR obtiene acceso a los datos protegidos por las políticas de seguridad de Lake Formation.
![\[Cómo accede Amazon EMR a los datos protegidos por las políticas de seguridad de Lake Formation\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/lf-emr-security.png)
1. Un usuario envía una solicitud de datos de Amazon EMR en Lake Formation.
1. Amazon EMR solicita credenciales temporales a Lake Formation para permitir que el usuario acceda a los datos.
1. Lake Formation devuelve credenciales temporales.
1. Amazon EMR envía la solicitud de consulta para obtener datos de Amazon S3.
1. Amazon EMR recibe los datos de Amazon S3, los filtra y devuelve los resultados en función de los permisos de usuario que el usuario definió en Lake Formation.
Para obtener más información sobre cómo agregar usuarios y grupos a las políticas de Lake Formation, consulte [Concesión de permisos para el catálogo de datos](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
## Requisitos previos
Si desea integrar Amazon EMR y Lake Formation, debe cumplir los siguientes requisitos:
+ Active la autorización de roles en tiempo de ejecución en el clúster de Amazon EMR.
+ Utilice el catálogo de datos de AWS Glue como almacén de metadatos.
+ Defina y gestione los permisos en Lake Formation para acceder a las bases de datos, tablas y columnas de AWS Glue Data Catalog. Para obtener más información, consulte [¿Qué es AWS Lake Formation?](https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html)
# Acceso detallado con Lake Formation
Las versiones 6.15.0 y posteriores de Amazon EMR incluyen soporte para un control de acceso detallado a nivel de fila, columna o celda basado en Lake Formation. AWS Los temas de esta sección explican cómo acceder a tablas protegidas del Catálogo de datos de Glue desde trabajos de Spark en EMR o sesiones interactivas con controles de acceso detallados.
# Habilitación de Lake Formation con Amazon EMR
Con Amazon EMR 6.15.0 y versiones posteriores, cuando ejecuta trabajos de Spark en Amazon EMR en clústeres de EC2 que acceden a los datos del catálogo de datos de AWS Glue, puede utilizarlos AWS Lake Formation para aplicar permisos a nivel de tabla, fila, columna y celda en tablas basadas en Hudi, Iceberg o Delta Lake.
En esta sección, explicamos cómo crear una configuración de seguridad y cómo configurar Lake Formation para que funcione con Amazon EMR. También explicamos cómo lanzar un clúster con la configuración de seguridad que creó para Lake Formation.
## Paso 1: configuración de un rol en tiempo de ejecución para el clúster de EMR
Para usar un rol en tiempo de ejecución para el clúster de EMR, debe crear una configuración de seguridad. Con una configuración de seguridad, puede aplicar opciones consistentes de seguridad, autorización y autenticación en todos sus clústeres.
1. Cree un archivo denominado `lf-runtime-roles-sec-cfg.json` con la siguiente configuración de seguridad.
```
{
"AuthorizationConfiguration": {
"IAMConfiguration": {
"EnableApplicationScopedIAMRole": true,
"ApplicationScopedIAMRoleConfiguration": {
"PropagateSourceIdentity": true
}
},
"LakeFormationConfiguration": {
"AuthorizedSessionTagValue": "Amazon EMR"
}
},
"EncryptionConfiguration": {
"EnableAtRestEncryption": false,
"EnableInTransitEncryption": true,
"InTransitEncryptionConfiguration": {
"TLSCertificateConfiguration": {}
}
}
}
```
El siguiente ejemplo muestra cómo usar un archivo ZIP con certificados en Amazon S3 para la configuración de certificados:
+ Un archivo ZIP con certificados en Amazon S3 actúa como proveedor de claves. (Consulte [Proporcionar certificados para el cifrado de datos en tránsito con el cifrado de Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) para ver los requisitos de certificados).
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "PEM",
"S3Object": "s3://MyConfigStore/artifacts/MyCerts.zip"
}
```
El ejemplo siguiente muestra cómo usar un proveedor de claves personalizado para la configuración de certificados:
+ Se usa un proveedor de claves personalizado. (Consulte [Proporcionar certificados para el cifrado de datos en tránsito con el cifrado de Amazon EMR](emr-encryption-enable.md#emr-encryption-certificates) para ver los requisitos de certificados).
```
"TLSCertificateConfiguration": {
"CertificateProviderType": "Custom",
"S3Object": "s3://MyConfig/artifacts/MyCerts.jar",
"CertificateProviderClass": "com.mycompany.MyCertProvider"
}
```
1. A continuación, para asegurarse de que la etiqueta de sesión puede autorizar Lake Formation, establezca la propiedad `LakeFormationConfiguration/AuthorizedSessionTagValue` en `Amazon EMR`.
1. Use el siguiente comando para crear la configuración de seguridad de Amazon EMR.
```
aws emr create-security-configuration \
--name 'iamconfig-with-iam-lf' \
--security-configuration file://lf-runtime-roles-sec-cfg.json
```
Como alternativa, puede utilizar la [consola de Amazon EMR](https://console.aws.amazon.com//emr) para crear una configuración de seguridad con ajustes personalizados.
## Paso 2: lanzar un clúster de Amazon EMR
Ahora tiene todo listo para lanzar un clúster de EMR con la configuración de seguridad que creó en el paso anterior. Para obtener más información sobre las configuraciones de seguridad, consulte [Uso de configuraciones de seguridad para configurar la seguridad del clúster de Amazon EMR](emr-security-configurations.md) y [Roles en tiempo de ejecución para los pasos de Amazon EMR](emr-steps-runtime-roles.md).
## Paso 3: configurar permisos a nivel de columna, fila o celda basados en Lake Formation con los roles de tiempo de ejecución de Amazon EMR
Para aplicar control de acceso detallado a nivel de columna, fila o celda con Lake Formation, el administrador del data lake debe definir `Amazon EMR` como valor de la configuración de etiqueta de sesión, `AuthorizedSessionTagValue`. Lake Formation usa esta etiqueta de sesión para autorizar a los intermediarios y proporcionar acceso al lago de datos. Puede definir esta etiqueta de sesión en la sección **Configuración de integración de aplicaciones** de la consola de Lake Formation. *123456789012*Sustitúyalo por su propio identificador. Cuenta de AWS
## Paso 4: Configurar las subvenciones de AWS Glue and Lake Formation para las funciones de tiempo de ejecución de Amazon EMR
Para continuar con la configuración del control de acceso basado en Lake Formation con las funciones de tiempo de ejecución de Amazon EMR, debe configurar las concesiones de AWS Glue and Lake Formation para las funciones de ejecución de Amazon EMR. Para permitir que sus roles en tiempo de ejecución de IAM interactúen con Lake Formation, debe concederles acceso con `lakeformation:GetDataAccess` y`glue:Get*`.
Los permisos de Lake Formation controlan el acceso a los recursos del catálogo de datos de AWS Glue, a las ubicaciones de Amazon S3 y a los datos subyacentes en esas ubicaciones. Los permisos de la IAM controlan el acceso a Lake Formation and AWS Glue APIs y a los recursos. Aunque es posible que tenga el permiso de Lake Formation para acceder a una tabla del catálogo de datos (SELECT), la operación fallará si no tiene el permiso de IAM en la API `glue:Get*`. Para obtener más información sobre el control de acceso de Lake Formation, consulte [Información general sobre el control de acceso de Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/lf-permissions-overview.html).
1. Cree el archivo `emr-runtime-roles-lake-formation-policy.json` con el siguiente contenido.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "LakeFormationManagedAccess",
"Effect": "Allow",
"Action": [
"lakeformation:GetDataAccess",
"glue:Get*",
"glue:Create*",
"glue:Update*"
],
"Resource": [
"*"
]
}
]
}
```
------
1. Cree la política de IAM relacionada.
```
aws iam create-policy \
--policy-name emr-runtime-roles-lake-formation-policy \
--policy-document file://emr-runtime-roles-lake-formation-policy.json
```
1. Para asignar esta política a sus roles en tiempo de ejecución de IAM, siga los pasos que se indican en [Administración de permisos de AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html).
Ahora puede usar roles en tiempo de ejecución y Lake Formation para aplicar permisos de tabla y columna. También puede utilizar una identidad de origen para controlar las acciones y supervisar las AWS CloudTrail operaciones.
Para cada rol de IAM que vaya a utilizar como rol en tiempo de ejecución, defina la siguiente política de confianza y sustituya `EMR_EC2_DefaultRole` por el rol de perfil de instancia. Para modificar la política de confianza de un rol de IAM, consulte [Modificación de una política de confianza de rol](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 ver un end-to-end ejemplo detallado, consulte [Introducción a las funciones de tiempo de ejecución para los pasos de 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 obtener información sobre cómo integrarse con Iceberg y AWS Glue Data Catalog para una jerarquía de varios catálogos, consulte [Configurar Spark para acceder a una jerarquía de varios catálogos en AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html#emr-lakehouse-using-spark-access).
# Compatibilidad con el formato de tabla abierta
Las versiones 6.15.0 y posteriores de Amazon EMR incluyen compatibilidad AWS Lake Formation con un control de acceso detallado basado en tablas de Hive, Apache Iceberg, Apache Hudi y Delta Lake al leer y escribir datos con Spark SQL. Amazon EMR es compatible con el control de acceso a nivel de tabla, fila, columna y celda con Apache Hudi. Las versiones de Amazon EMR 6.15.0 y posteriores incluyen compatibilidad con el control de acceso detallado a nivel de fila, columna o celda mediante AWS Lake Formation. A partir de EMR 7.12, las operaciones de DML y DDL que modifican los datos de las tablas son compatibles con las tablas de Apache Hive, Apache Iceberg y Delta Lake que utilizan las credenciales vendidas de Lake Formation.
Los temas de esta sección tratan sobre cómo puede acceder a las tablas registradas de Lake Formation en formatos de tablas abiertas desde trabajos de EMR Spark o sesiones interactivas con un control de acceso detallado.
## Requisitos del permiso
### Las tablas no están registradas AWS Lake Formation
En el caso de las tablas no registradas AWS Lake Formation, el rol de tiempo de ejecución del trabajo accede tanto al catálogo de datos de AWS Glue como a los datos de la tabla subyacente en Amazon S3. Esto requiere que el rol de tiempo de ejecución del trabajo tenga los permisos de IAM adecuados para las operaciones de AWS Glue y Amazon S3.
### Tablas registradas en AWS Lake Formation
En el caso de las tablas registradas con AWS Lake Formation, el rol de ejecución del trabajo accede a los metadatos del catálogo de datos de AWS Glue, mientras que las credenciales temporales que vende Lake Formation acceden a los datos de la tabla subyacente en Amazon S3. Los permisos de Lake Formation necesarios para ejecutar una operación dependen del catálogo de datos de AWS Glue y de las llamadas a la API de Amazon S3 que inicie el trabajo de Spark y se pueden resumir de la siguiente manera:
+ El permiso **DESCRIBE** permite al rol de ejecución leer los metadatos de una tabla o base de datos en el catálogo de datos
+ El permiso **ALTER** permite al rol de ejecución modificar los metadatos de una tabla o base de datos en el catálogo de datos
+ El permiso **DROP** permite al rol de ejecución eliminar metadatos de tablas o bases de datos del catálogo de datos
+ El permiso **SELECT** permite al rol de ejecución leer datos de tablas de Amazon S3
+ El permiso **INSERT** permite al rol de ejecución escribir datos de tablas en Amazon S3
+ El permiso **DELETE** permite al rol de ejecución eliminar los datos de la tabla de Amazon S3
**nota**
Lake Formation evalúa los permisos de forma perezosa cuando un trabajo de Spark llama a AWS Glue para recuperar los metadatos de la tabla y a Amazon S3 para recuperar los datos de la tabla. Los trabajos que utilizan un rol en tiempo de ejecución con permisos insuficientes no fallarán hasta que Spark realice una llamada a AWS Glue o Amazon S3 que requiera el permiso faltante.
**nota**
En la siguiente matriz de tablas compatibles:
Las operaciones marcadas como **compatibles** utilizan exclusivamente las credenciales de Lake Formation para acceder a los datos de las tablas registradas en Lake Formation. Si los permisos de Lake Formation son insuficientes, la operación no recurrirá a las credenciales del rol en tiempo de ejecución. En el caso de las tablas no registradas en Lake Formation, las credenciales del rol de ejecución del trabajo acceden a los datos de la tabla.
Las operaciones marcadas como **compatibles con los permisos de IAM en la ubicación de Amazon S3** no utilizan las credenciales de Lake Formation para acceder a los datos de las tablas subyacentes en Amazon S3. Para ejecutar estas operaciones, el rol de ejecución del trabajo debe tener los permisos de IAM de Amazon S3 necesarios para acceder a los datos de la tabla, independientemente de si la tabla está registrada en Lake Formation.
------
#### [ Hive ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-lf-fgac1.html)
------
#### [ Iceberg ]
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuración de Spark para Iceberg:** si desea utilizar el formato Iceberg, establezca las siguientes configuraciones. Reemplace `DB_LOCATION` por la ruta de Amazon S3 en la que se encuentran las tablas de Iceberg y reemplace los marcadores de posición de región e ID de cuenta por sus propios 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
```
Si desea usar el formato Iceberg en versiones anteriores de EMR, use el siguiente 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
```
**Ejemplos**:
Estos son algunos ejemplos de cómo trabajar con tablas 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/es_es/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuración de Spark para Hudi:**
Para iniciar el shell de Spark en EMR 7.10 o superior, use el siguiente comando:
```
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 el shell de Spark en versiones anteriores de EMR, en cambio, use el siguiente comando:
```
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
```
**Ejemplos**:
Estos son algunos ejemplos de cómo trabajar con tablas 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 la última instantánea de copy-on-write las tablas:
```
SELECT * FROM my_hudi_cow_table
```
```
spark.read.table("my_hudi_cow_table")
```
Para conocer los datos compactados más recientes de las tablas `MOR`, puede consultar la tabla optimizada para lectura que tiene el sufijo `_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/es_es/emr/latest/ManagementGuide/emr-lf-fgac1.html)
**Configuración de Spark para Delta Lake:**
Para usar Delta Lake con Lake Formation en EMR 7.10 y versiones posteriores, ejecute el siguiente 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 Delta Lake con Lake Formation en EMR 6.15 a 7.9, ejecute lo siguiente:
```
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
```
Si quiere que Lake Formation utilice el servidor de registros para administrar su catálogo de Spark, establezca `spark.sql.catalog..lf.managed` en verdadero.
**Ejemplos**:
Estos son algunos ejemplos de cómo trabajar con tablas de 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 *;
```
**Creación de una tabla de Delta Lake en AWS Glue Data Catalog**
Amazon EMR with Lake Formation no admite los comandos DDL ni la creación de tablas Delta en las versiones de EMR anteriores a la 7.12. Siga estos pasos para crear tablas en el catálogo de datos de AWS Glue.
1. Cree una tabla Delta con el siguiente ejemplo. Asegúrese de que su ubicación de 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 los detalles de la tabla, vaya a [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. En el menú de navegación de la izquierda, expanda el **Catálogo de datos**, elija **Tablas** y, a continuación, elija la tabla que ha creado. En **Esquema**, deberías ver que la tabla Delta que creaste con Spark almacena todas las columnas en un tipo de datos llamado `array` in AWS Glue.
1. Para definir filtros a nivel de columna y celda en Lake Formation, elimine la columna `col` del esquema y, a continuación, agregue las columnas que están en el esquema de la tabla. En este ejemplo, añada las columnas `x`, `y` y `z`.
------
Con esta función, puedes ejecutar consultas de instantáneas en copy-on-write las tablas para consultar la última instantánea de la tabla en un instante de confirmación o compactación determinado. Actualmente, un clúster de Amazon EMR habilitado para Lake Formation debe recuperar la columna de tiempo de confirmación de Hudi para realizar consultas incrementales y consultas de viajes en el tiempo. No es compatible con la sintaxis `timestamp as of` de Spark ni con la función `Spark.read()`. La sintaxis correcta es `select * from table where _hoodie_commit_time <= point_in_time`. Para obtener más información, consulte la tabla [Consultas sobre viajes en el tiempo puntuales en Hudi](https://cwiki.apache.org/confluence/display/HUDI/RFC+-+07+%3A+Point+in+time+Time-Travel+queries+on+Hudi+table).
**nota**
El rendimiento de las lecturas en los clústeres de Lake Formation puede ser más lento debido a las optimizaciones que no se admiten. Estas características incluyen la lista de archivos basada en los metadatos de Hudi y la omisión de datos. Recomendamos probar el rendimiento de su aplicación para asegurarse de que cumple con los requisitos.
# Trabajo con las vistas del Catálogo de datos de Glue en Amazon EMR
**nota**
La creación y administración de vistas del catálogo de datos de AWS Glue para su uso con EMR en EC2 está disponible con Amazon [EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-7100-release.html) versión 7.10.0 y versiones posteriores.
Puede crear y gestionar vistas en el catálogo de datos de AWS Glue para utilizarlas con EMR en EC2. Estas se conocen comúnmente como vistas del catálogo de datos de AWS Glue. Estas vistas son útiles porque admiten varios motores de consultas SQL, por lo que puede acceder a la misma vista en distintos AWS servicios, como EMR en EC2 y Amazon Amazon Athena Redshift.
Al crear una vista en el catálogo de datos, puede utilizar las concesiones de recursos y los controles de acceso basados en etiquetas AWS Lake Formation para conceder el acceso a ella. Con este método de control de acceso, no tiene que configurar el acceso adicional a las tablas a las que hizo referencia en el momento de crear la vista. Este método de concesión de permisos se denomina semántica del definidor y estas vistas se denominan vistas del definidor. Para obtener más información sobre el control de acceso en Lake Formation, consulte [Concesión y revocación de permisos sobre los recursos del catálogo de datos](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html) en la Guía para desarrolladores de AWS Lake Formation.
Las vistas del Catálogo de datos son útiles para los siguientes casos de uso:
+ **Control de acceso detallado**: puede crear una vista que restrinja el acceso a los datos en función de los permisos que necesite el usuario. Por ejemplo, puede usar las vistas del catálogo de datos para evitar que el personal que no trabaje en el departamento de Recursos Humanos (RR.HH.) vea información de identificación personal (PII).
+ **Definición de vista completa**: aplicar determinados filtros a la vista del Catálogo de datos garantiza que los registros de datos disponibles en una vista del Catálogo de datos estén siempre completos.
+ **Seguridad mejorada**: la definición de consulta utilizada para crear la vista debe estar completa. Esta ventaja significa que las vistas del Catálogo de datos son menos susceptibles a los comandos SQL de actores malintencionados.
+ **Compartir datos de forma sencilla**: comparta datos con otras AWS cuentas sin moverlos. Para obtener más información, consulte [Uso compartido entre cuentas en Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html).
## Creación de una vista del catálogo de datos
Existen diferentes formas de crear una vista del Catálogo de datos. Estas incluyen el uso de Spark SQL AWS CLI o Spark. A continuación, se muestran algunos ejemplos.
------
#### [ Using SQL ]
A continuación, se muestra la sintaxis para crear una vista del Catálogo de datos. Anote el tipo de vista `MULTI DIALECT`. Esto distingue la vista del Catálogo de datos de otras vistas. El predicado `SECURITY` se especifica como `DEFINER`. Esto indica una vista del Catálogo de datos con 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;
```
El siguiente es un ejemplo de declaración `CREATE` según la sintaxis:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY order_date
```
También puede crear una vista en modo de ejecución de prueba mediante SQL para probar la creación de la vista sin crear realmente el recurso. El uso de esta opción da como resultado una «ejecución en seco» que valida la entrada y, si la validación se realiza correctamente, devuelve el JSON del objeto de tabla AWS Glue que representará la vista. En este caso, no se crea la vista real.
```
CREATE [ OR REPLACE ] PROTECTED MULTI DIALECT VIEW view_name
SECURITY DEFINER
[ SHOW VIEW JSON ]
AS view-sql
```
------
#### [ Using the AWS CLI ]
**nota**
Cuando se utiliza el comando CLI, el SQL utilizado para crear la vista no se analiza. Esto puede provocar que se cree la vista, pero que las consultas no se realicen de manera correcta. Asegúrese de probar la sintaxis de SQL antes de crear la vista.
Puede utilizar los siguientes comandos CLI para crear una vista:
```
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"
}
]
}
}
}'
```
------
## Operaciones de vista admitidas
Los siguientes fragmentos de comandos muestran varias formas de trabajar con las vistas del Catálogo de datos:
+ **CREATE VIEW**
Crea una vista del Catálogo de datos. El siguiente es un ejemplo que muestra cómo crear una vista a partir de una tabla existente:
```
CREATE PROTECTED MULTI DIALECT VIEW catalog_view
SECURITY DEFINER AS SELECT * FROM my_catalog.my_database.source_table
```
+ **ALTER VIEW**
Sintaxis disponible:
+ `ALTER VIEW view_name [FORCE] ADD DIALECT AS query`
+ `ALTER VIEW view_name [FORCE] UPDATE DIALECT AS query`
+ `ALTER VIEW view_name DROP DIALECT`
Puede utilizar la opción `FORCE ADD DIALECT` para forzar la actualización del esquema y los subobjetos según el nuevo dialecto del motor. Tenga en cuenta que hacer esto puede provocar errores de consulta si no utiliza también `FORCE` para actualizar otros dialectos del motor. A continuación se muestra un ejemplo:
```
ALTER VIEW catalog_view FORCE ADD DIALECT
AS
SELECT order_date, sum(totalprice) AS price
FROM source_table
GROUP BY orderdate;
```
A continuación se muestra cómo modificar una vista para actualizar el dialecto:
```
ALTER VIEW catalog_view UPDATE DIALECT AS
SELECT count(*) FROM my_catalog.my_database.source_table;
```
+ **DESCRIBE VIEW**
Sintaxis disponible para describir una vista:
+ `SHOW COLUMNS {FROM|IN} view_name [{FROM|IN} database_name]`— Si el usuario tiene los permisos de AWS Glue and Lake Formation necesarios para describir la vista, puede enumerar las columnas. A continuación se muestran un par de comandos de ejemplo para mostrar columnas:
```
SHOW COLUMNS FROM my_database.source_table;
SHOW COLUMNS IN my_database.source_table;
```
+ `DESCRIBE view_name`— Si el usuario tiene los permisos de AWS Glue and Lake Formation necesarios para describir la vista, puede enumerar las columnas de la vista junto con sus metadatos.
+ **DROP VIEW**
Sintaxis disponible:
+ `DROP VIEW [ IF EXISTS ] view_name`
El siguiente ejemplo muestra una instrucción `DROP` que comprueba si existe una vista antes de eliminarla:
```
DROP VIEW IF EXISTS catalog_view;
```
+ **MOSTRAR, CREAR VISTA**
+ `SHOW CREATE VIEW view_name`: Muestra la instrucción SQL que crea la vista especificada. El siguiente es un ejemplo que muestra cómo crear una vista en el catálogo de datos:
```
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**
Liste todas las vistas en el catálogo, como vistas regulares, vistas multidialecto (MDV) y MDV sin dialecto de Spark. La sintaxis disponible es la siguiente:
+ `SHOW VIEWS [{ FROM | IN } database_name] [LIKE regex_pattern]`:
A continuación se muestra un comando de ejemplo para mostrar vistas:
```
SHOW VIEWS IN marketing_analytics LIKE 'catalog_view*';
```
Para obtener más información sobre la creación y configuración de vistas de catálogos de datos, consulte [Building AWS Glue Data Catalog views](https://docs.aws.amazon.com/lake-formation/latest/dg/working-with-views.html) en la Guía para AWS Lake Formation desarrolladores.
## Consulta de la vista del Catálogo de datos
Tras crear una vista del catálogo de datos, puede consultarla mediante un trabajo de Amazon EMR Spark que tenga activado el control de AWS Lake Formation acceso detallado. El rol de tiempo de ejecución del trabajo debe contar con el permiso de `SELECT` Lake Formation en la vista del Catálogo de datos. No es necesario conceder acceso a las tablas subyacentes a las que se hace referencia en la vista.
Una vez que haya configurado todo, podrá consultar la vista. Por ejemplo, después de crear una aplicación de Amazon EMR en EMR Studio, puede ejecutar la siguiente consulta para acceder a una vista.
```
SELECT * from my_database.catalog_view LIMIT 10;
```
Una función útil es `invoker_principal`. Proporciona el identificador único del rol de tiempo de ejecución del trabajo de EMRS. Esto se puede usar para controlar el resultado de la vista según la entidad principal que lo invoca. Se puede usar para agregar una condición a la vista que mejore los resultados de la consulta según el rol de llamada. Para utilizar este rol, el rol de tiempo de ejecución del trabajo debe tener permiso para realizar la acción de IAM `LakeFormation:GetDataLakePrincipal`.
```
select invoker_principal();
```
Puede agregar esta función a una cláusula `WHERE`, por ejemplo, para mejorar los resultados de la consulta.
## Consideraciones y limitaciones
Tenga en cuenta lo siguiente cuando cree vistas del Catálogo de datos:
+ Solo puede crear vistas del Catálogo de datos con Amazon EMR 7.10 o superior.
+ El creador de la vista en el Catálogo de datos debe tener acceso a `SELECT` a las tablas base subyacentes a las que accede la vista. La creación de la vista en el Catálogo de datos falla si una tabla base específica tiene filtros de Lake Formation impuestos al rol del creador.
+ Las tablas base no deben tener el permiso de lago de datos `IAMAllowedPrincipals` en Lake Formation. Si está presente, se produce el error Las *vistas en varios dialectos solo pueden hacer referencia a tablas* sin los permisos del director. IAMAllowed
+ La ubicación de Amazon S3 de la tabla debe estar registrada como ubicación de lago de datos de Lake Formation. Si la tabla no está registrada, se produce el error *Las vistas de múltiples dialectos solo pueden hacer referencia a tablas administradas por Lake Formation*. Para obtener información sobre cómo registrar ubicaciones de Amazon S3 en Lake Formation, consulte [Registrar una ubicación de Amazon S3](https://docs.aws.amazon.com/lake-formation/latest/dg/register-location.html) en la Guía para AWS Lake Formation desarrolladores.
+ Solo puede crear vistas del catálogo de datos `PROTECTED`. No se admiten las vistas `UNPROTECTED`.
+ No puede hacer referencia a las tablas de otra AWS cuenta en una definición de vista del catálogo de datos. Tampoco se puede hacer referencia a una tabla de la misma cuenta que esté en una región distinta.
+ Para compartir datos entre cuentas o regiones, toda la vista debe compartirse entre cuentas y regiones, mediante los enlaces de recursos de Lake Formation.
+ No se admiten las funciones definidas por el usuario (UDFs).
+ Puede utilizar vistas basadas en tablas de Iceberg. También se admiten los formatos de tabla abierta de Apache Hudi y Delta Lake.
+ No puede hacer referencia a otras vistas en las vistas del catálogo de datos.
+ Un esquema de vista del catálogo de datos de AWS Glue siempre se almacena en minúsculas. Por ejemplo, si utiliza una instrucción DDL para crear una vista del Catálogo de datos de Glue con una columna denominada `Castle`, la columna creada en el Catálogo de datos de Glue aparecerá en minúsculas en `castle`. Si luego especifica el nombre de columna en una consulta DML como `Castle` o `CASTLE`, EMR Spark usará minúsculas en el nombre para que ejecute la consulta. Sin embargo, el encabezado de la columna se mostrará de la forma en que lo haya especificado en la consulta.
Si desea que una consulta tire error si el nombre de una columna especificado en la consulta DML no coincide con el nombre de la columna del Catálogo de datos de Glue, puede configurar `spark.sql.caseSensitive=true`.
# Consideraciones sobre Amazon EMR con Lake Formation
Amazon EMR con Lake Formation está disponible en todas las [regiones disponibles](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-region.html).
## Consideraciones para Amazon EMR con Lake Formation en la versión 7.9 y anteriores
Tenga en cuenta lo siguiente cuando lo utilice AWS Lake Formation en EMR 7.9 y versiones anteriores.
+ El [control de acceso detallado](emr-lf-enable.md#emr-lf-fgac-perms) a nivel de fila, columna y celda está disponible en los clústeres con las versiones 6.15 y posteriores de Amazon EMR.
+ Los usuarios con acceso a una tabla pueden acceder a todas las propiedades de esa tabla. Si tiene un control de acceso basado en Lake Formation en una tabla, revísela para asegurarse de que las propiedades no contengan ningún dato o información confidencial.
+ Los clústeres de Amazon EMR con Lake Formation no admiten el uso alternativo de HDFS cuando Spark recopile estadísticas de tablas. Por lo general, esto ayuda a optimizar el rendimiento de las consultas.
+ Las operaciones compatibles con los controles de acceso basados en Lake Formation con tablas no gobernadas de Apache Spark incluyen `INSERT INTO` y `INSERT OVERWRITE`.
+ Las operaciones que admiten los controles de acceso basados en Lake Formation con Apache Spark y Apache Hive incluyen `SELECT`, `DESCRIBE`,`SHOW DATABASE`, `SHOW TABLE`, `SHOW COLUMN` y `SHOW PARTITION`.
+ Amazon EMR no es compatible con el control de acceso a las siguientes operaciones basadas en Lake Formation:
+ Escribe en tablas gobernadas
+ Amazon EMR no es compatible con `CREATE TABLE`. Amazon EMR 6.10.0 y versiones posteriores es compatible con `ALTER TABLE`.
+ Instrucciones DML distintas de los comandos `INSERT`.
+ Existen diferencias de rendimiento entre la misma consulta con y sin control de acceso basado en Lake Formation.
+ Solo puede utilizar Amazon EMR con Lake Formation para trabajos de Spark.
+ La propagación de identidades de confianza no funciona con jerarquías de múltiples catálogos en Catálogo de datos de Glue. Para obtener más información, consulte [Trabajar con una jerarquía de varios catálogos en AWS Glue Data Catalog](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Consideraciones para Amazon EMR con Lake Formation en la versión 7.10 y posteriores
Tenga en cuenta lo siguiente cuando utilice Amazon EMR con AWS Lake Formation EMR 7.10 y versiones posteriores.
+ Amazon EMR admite controles de acceso detallados mediante Lake Formation únicamente para tablas de Apache Hive, Apache Iceberg, Apache Delta y Apache Hudi. Los formatos de Apache Hive incluyen Parquet, ORC y xSV CSV.
+ En aplicaciones habilitadas para Lake Formation, Spark escribe los registros en Amazon S3 en dos grupos: registros de espacio del sistema y registros de espacio de usuario. Los registros de espacio del sistema pueden incluir información sensible, como el esquema completo de la tabla. Para proteger estos datos, Amazon EMR guarda los registros de espacio del sistema en una ubicación distinta de los registros de espacio de usuario. Se recomienda enfáticamente que los administradores de la cuenta no otorguen acceso a los registros de espacio del sistema.
+ Cuando registra la ubicación de una tabla en Lake Formation, los permisos del rol usado para registrar la tabla controlan por completo el acceso a los datos, en lugar del rol de tiempo de ejecución del trabajo de Amazon EMR. Si el rol de registro está configurado de forma incorrecta, los trabajos que intenten acceder a la tabla fallarán.
+ No puede desactivar `DynamicResourceAllocation` para los trabajos de Lake Formation.
+ Solo puede utilizar Lake Formation con trabajos de Spark.
+ Amazon EMR con Lake Formation admite únicamente una sesión de Spark durante todo el trabajo.
+ Amazon EMR con Lake Formation solo admite consultas de tablas entre cuentas compartidas a través de enlaces de recursos.
+ Lo siguiente no es compatible:
+ Conjuntos de datos distribuidos resilientes (RDD)
+ Streaming de Spark
+ Lectura con permisos concedidos de Lake Formation
+ Control de acceso para columnas anidadas
+ Amazon EMR bloquea las funcionalidades que podrían socavar el aislamiento total del controlador del sistema, incluidas las siguientes:
+ UDTs, Hive UDFs y cualquier función definida por el usuario que incluya clases personalizadas
+ Orígenes de datos personalizados
+ Suministro de archivos jar adicionales para la extensión, el conector o el metaalmacén de Spark
+ `ANALYZE TABLE` command
+ Para hacer cumplir los controles de acceso, `EXPLAIN PLAN` y las operaciones de DDL, como `DESCRIBE TABLE`, no exponen información restringida.
+ Amazon EMR restringe el acceso a los registros de Spark del controlador del sistema en las aplicaciones habilitadas para Lake Formation. Dado que el controlador del sistema se ejecuta permisos elevados, los eventos y registros que genera el controlador del sistema pueden incluir información confidencial. Para impedir que usuarios no autorizados o código no autorizado accedan a esta información confidencial, Amazon EMR deshabilita el acceso a los registros del controlador del sistema.
Los registros de los perfiles del sistema siempre se conservan en el almacenamiento administrado; esta es una configuración obligatoria que no se puede deshabilitar. Estos registros se almacenan de forma segura y se cifran mediante una clave de KMS gestionada por el cliente o una clave de KMS AWS gestionada.
Si su aplicación de Amazon EMR se encuentra en una subred privada con puntos de enlace de VPC para Amazon S3 y adjunta una política de puntos de enlace para controlar el acceso, antes de que sus trabajos puedan enviar datos de registro a AWS Amazon S3 gestionado, debe incluir los permisos detallados en [Almacenamiento gestionado](logging.html#jobs-log-storage-managed-storage) en su política de VPC al punto de enlace de puerta de enlace de S3. Para solicitudes de solución de problemas, póngase en contacto con el soporte. AWS
+ Si ha registrado una ubicación de tabla en Lake Formation, la ruta de acceso a los datos pasa por las credenciales almacenadas de Lake Formation, independientemente del permiso de IAM para el rol de tiempo de ejecución de trabajos de Amazon EMR. Si configura incorrectamente el rol registrado con la ubicación de la tabla, los trabajos enviados que usen el rol con permisos de IAM de S3 para la ubicación de la tabla fallarán.
+ Para escribir en una tabla de Lake Formation se utiliza el permiso de IAM en lugar de los permisos concedidos por Lake Formation. Si el rol de tiempo de ejecución de su trabajo tiene los permisos de S3 necesarios, puede usarlo para ejecutar operaciones de escritura.
A continuación, se indican las consideraciones y limitaciones cuando se utiliza Apache Iceberg:
+ Solo puede usar Apache Iceberg con el catálogo de sesiones y no con catálogos con nombres arbitrarios.
+ Las tablas de Iceberg que están registradas en Lake Formation solo admiten las tablas de metadatos `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` y `refs`. Amazon EMR oculta las columnas que pueden contener datos confidenciales, como `partitions`, `path` y `summaries`. Esta limitación no se aplica a las tablas de Iceberg que no estén registradas en Lake Formation.
+ Las tablas que no se registran en Lake Formation admiten todos los procedimientos almacenados de Iceberg. Los procedimientos `register_table` y `migrate` no son compatibles con ninguna tabla.
+ Le recomendamos que utilice Iceberg DataFrameWriter V2 en lugar de V1.
## Consideraciones sobre Amazon EMR con Lake Formation para la versión 7.12 y versiones posteriores
### General
Revise las siguientes limitaciones al utilizar Lake Formation con Amazon EMR.
+ No puede desactivar `DynamicResourceAllocation` para los trabajos de Lake Formation.
+ Solo puede utilizar Lake Formation con trabajos de Spark.
+ Amazon EMR con Lake Formation admite únicamente una sesión de Spark durante todo el trabajo.
+ Amazon EMR con Lake Formation solo admite consultas de tablas entre cuentas compartidas a través de enlaces de recursos.
+ Lo siguiente no es compatible:
+ Conjuntos de datos distribuidos resilientes (RDD)
+ Streaming de Spark
+ Control de acceso para columnas anidadas
+ Amazon EMR bloquea las funcionalidades que podrían socavar el aislamiento total del controlador del sistema, incluidas las siguientes:
+ UDTs, Hive UDFs y cualquier función definida por el usuario que incluya clases personalizadas
+ Orígenes de datos personalizados
+ Suministro de archivos jar adicionales para la extensión, el conector o el metaalmacén de Spark
+ `ANALYZE TABLE` command
+ Si su aplicación de Amazon EMR se encuentra en una subred privada con puntos de enlace de VPC para Amazon S3 y adjunta una política de puntos de enlace para controlar el acceso, antes de que sus trabajos puedan enviar datos de registro a AWS Amazon S3 gestionado, debe incluir los permisos detallados en [Almacenamiento gestionado](logging.html#jobs-log-storage-managed-storage) en su política de VPC al punto de enlace de puerta de enlace de S3. Para solicitudes de solución de problemas, póngase en contacto con el soporte. AWS
+ A partir de Amazon EMR 7.9.0, el FGAC de Spark es compatible con el AFile sistema S3 cuando se utiliza con el esquema s3a://.
+ Amazon EMR 7.11 admite la creación de tablas administradas mediante CTAS.
+ Amazon EMR 7.12 admite la creación de tablas administradas y externas mediante CTAS.
## Permisos
+ Para hacer cumplir los controles de acceso, las operaciones EXPLAIN, PLAN y DDL, como DESCRIBE TABLE, no exponen información restringida.
+ Al registrar la ubicación de una tabla en Lake Formation, el acceso a los datos utiliza las credenciales almacenadas de Lake Formation en lugar de los permisos de IAM del rol de ejecución de tareas EMR Serverless. Los trabajos fallarán si el rol registrado para la ubicación de la tabla está mal configurado, incluso cuando el rol en tiempo de ejecución tenga permisos de IAM de S3 para esa ubicación.
+ A partir de Amazon EMR 7.12, puede escribir en las tablas Hive e Iceberg existentes utilizando DataFrameWriter (V2) con las credenciales de Lake Formation en modo de adición. Para las operaciones de sobrescritura o al crear nuevas tablas, EMR utiliza las credenciales del rol en tiempo de ejecución para modificar los datos de la tabla.
+ Se aplican las siguientes limitaciones cuando se utilizan vistas o tablas en caché como datos de origen (estas limitaciones no se aplican a las vistas del catálogo de datos de AWS Glue):
+ Para las operaciones de FUSIÓN, ELIMINACIÓN y ACTUALIZACIÓN
+ Compatible: uso de vistas y tablas almacenadas en caché como tablas de origen.
+ No se admite: usar vistas y tablas almacenadas en caché en las cláusulas de asignación y condición.
+ Para las operaciones CREATE OR REPLACE y REPLACE TABLE AS SELECT:
+ No se admite: usar vistas y tablas almacenadas en caché como tablas de origen.
+ Las tablas de Delta Lake con UDFs datos de origen admiten las operaciones MERGE, DELETE y UPDATE solo cuando el vector de eliminación está activado.
## Registros y depuración
+ Amazon EMR restringe el acceso a los registros de Spark del controlador del sistema en las aplicaciones habilitadas para Lake Formation. Dado que el controlador del sistema se ejecuta permisos elevados, los eventos y registros que genera el controlador del sistema pueden incluir información confidencial. Para impedir que usuarios no autorizados o código no autorizado accedan a esta información confidencial, Amazon EMR deshabilita el acceso a los registros del controlador del sistema.
Los registros de los perfiles del sistema siempre se conservan en el almacenamiento administrado; esta es una configuración obligatoria que no se puede deshabilitar. Estos registros se almacenan de forma segura y se cifran mediante una clave de KMS gestionada por el cliente o una clave de KMS AWS gestionada.
## Iceberg
Tenga en cuenta las siguientes consideraciones al utilizar Apache Iceberg:
+ Solo puede usar Apache Iceberg con el catálogo de sesiones y no con catálogos con nombres arbitrarios.
+ Las tablas de Iceberg que están registradas en Lake Formation solo admiten las tablas de metadatos `history`, `metadata_log_entries`, `snapshots`, `files`, `manifests` y `refs`. Amazon EMR oculta las columnas que pueden contener datos confidenciales, como `partitions`, `path` y `summaries`. Esta limitación no se aplica a las tablas de Iceberg que no estén registradas en Lake Formation.
+ Las tablas que no están registradas en Lake Formation admiten todos los procedimientos almacenados por Iceberg. Los procedimientos `register_table` y `migrate` no son compatibles con ninguna tabla.
+ Le sugerimos que utilice Iceberg DataFrameWriter V2 en lugar de V1.
# API de control de acceso nativa y detallada de Spark, incluida en la lista de permisos PySpark
Para mantener la seguridad y los controles de acceso a los datos, el control de acceso detallado (FGAC) de Spark restringe determinadas funciones. PySpark Estas restricciones se aplican mediante:
+ Bloqueo explícito que impide la ejecución de funciones
+ Incompatibilidades de arquitectura que hacen que las funciones no funcionen
+ Funciones que pueden generar errores, devolver mensajes de acceso denegado o no hacer nada al ser llamadas
El FGAC de Spark no admite las siguientes PySpark funciones:
+ Operaciones de RDD (bloqueadas con la excepción de Spark) RDDUnsupported
+ Spark Connect (no compatible)
+ Spark Streaming (no compatible)
Si bien hemos probado las funciones enumeradas en un entorno FGAC nativo de Spark y hemos confirmado que funcionan según lo esperado, nuestras pruebas suelen cubrir solo el uso básico de cada API. Las funciones con varios tipos de entrada o rutas lógicas complejas pueden tener escenarios no probados.
Para cualquier función que no figure aquí y que no forme parte claramente de las categorías no admitidas anteriores, recomendamos:
+ Pruébelas primero en un entorno gamma o en una implementación a pequeña escala
+ Verificar su comportamiento antes de usarlos en producción
**nota**
Si ves un método de clase en la lista pero no su clase base, el método debería seguir funcionando; solo significa que no hemos verificado explícitamente el constructor de la clase base.
La PySpark API está organizada en módulos. El soporte general para los métodos de cada módulo se detalla en la siguiente tabla.
| Nombre del módulo | Status | Notas |
| --- | --- | --- |
| pyspark\$1core | compatible | Este módulo contiene las principales clases de RDD y, en su mayoría, estas funciones no son compatibles. |
| pyspark\$1sql | compatible | |
| pyspark\$1testing | compatible | |
| pyspark\$1resource | compatible | |
| pyspark\$1streaming | Blocked | El uso del streaming está bloqueado en Spark FGAC. |
| pyspark\$1mllib | Experimental | Este módulo contiene operaciones de aprendizaje automático basadas en RDD y, en su mayoría, estas funciones no son compatibles. Este módulo no se ha probado exhaustivamente. |
| pyspark\$1ml | Experimental | Este módulo contiene operaciones de aprendizaje automático DataFrame basadas en el aprendizaje automático, y estas funciones son compatibles en su mayoría. Este módulo no se ha probado exhaustivamente. |
| pyspark\$1pandas | compatible | |
| pyspark\$1pandas\$1slow | compatible | |
| pyspark\$1connect | Blocked | El uso de Spark Connect está bloqueado en Spark FGAC. |
| pyspark\$1pandas\$1connect | Blocked | El uso de Spark Connect está bloqueado en Spark FGAC. |
| pyspark\$1pandas\$1slow\$1connect | Blocked | El uso de Spark Connect está bloqueado en Spark FGAC. |
| pyspark\$1errors | Experimental | Este módulo no se ha probado exhaustivamente. No se pueden utilizar clases de error personalizadas. |
**Lista de API permitidas**
Para obtener una lista descargable y más fácil de buscar, hay disponible un archivo con los módulos y las clases en las [funciones de Python permitidas en el FGAC nativo](samples/Python functions allowed in Native FGAC.zip).
# Acceso completo a la tabla de Lake Formation para Amazon EMR en EC2
Con las versiones 7.8.0 y posteriores de Amazon EMR, puede aprovechar AWS Lake Formation con Glue Data Catalog, donde el rol de ejecución de tareas tiene permisos de tabla completos sin las limitaciones de un control de acceso detallado. Esta capacidad le permite leer y escribir en tablas protegidas por Lake Formation desde sus trabajos por lotes e interactivos de Amazon EMR en EC2 Spark. Consulte las siguientes secciones para obtener más información sobre Lake Formation y cómo utilizarla con Amazon EMR en EC2.
## Uso de Lake Formation con acceso completo a las tablas
Puede acceder a las tablas del catálogo Glue Data protegidas por AWS Lake Formation desde Amazon EMR en trabajos de EC2 Spark o en sesiones interactivas en las que el rol de tiempo de ejecución del trabajo tiene acceso completo a las tablas. No es necesario activar AWS Lake Formation en la aplicación Amazon EMR on EC2. Cuando un trabajo de Spark está configurado para el acceso total a la tabla (FTA), las credenciales de AWS Lake Formation se utilizan para los datos de read/write S3 de las tablas registradas de AWS Lake Formation, mientras que las credenciales del rol de tiempo de ejecución del trabajo se utilizan para read/write las tablas no registradas en AWS Lake Formation.
**importante**
No habilite AWS Lake Formation para un control de acceso detallado. Un trabajo no puede utilizar simultáneamente el acceso completo a las tablas (FTA) y el control de acceso detallado (FGAC) en el mismo clúster o la misma aplicación de EMR.
### Paso 1: habilitación del acceso completo a las tablas en Lake Formation
Para utilizar el modo Full Table Access (FTA), debe permitir que los motores de consulta de terceros accedan a los datos sin la validación de etiquetas de sesión de IAM en AWS Lake Formation. Para habilitarlo, siga los pasos descritos en [Integración de aplicaciones para acceso completo a la tabla ](https://docs.aws.amazon.com/lake-formation/latest/dg/full-table-credential-vending.html).
**nota**
Cuando se accede a tablas entre cuentas, se debe habilitar el acceso completo a las tablas tanto en las cuentas de productores como en las de consumidores. Del mismo modo, cuando se accede a las tablas entre regiones, esta configuración debe estar habilitada tanto en las regiones de productores como en las de consumidores.
### Paso 2: configuración de los permisos de IAM para el rol en tiempo de ejecución del trabajo
Para acceder a los datos subyacentes, ya sea para lectura o escritura, además de los permisos de Lake Formation, el rol de tiempo de ejecución del trabajo necesita el permiso de IAM `lakeformation:GetDataAccess`. Con este permiso, Lake Formation concede la solicitud de credenciales temporales para acceder a los datos.
El siguiente es un ejemplo de política sobre cómo proporcionar permisos de IAM para acceder a un script en Amazon S3, cargar registros en S3, permisos de la API de AWS Glue y permiso para acceder a Lake Formation.
#### Paso 2.1: configuración de los permisos de Lake Formation
+ Los trabajos de Spark que leen datos desde S3 requieren el permiso SELECCIONAR de Lake Formation.
+ Los trabajos de Spark write/delete cuyos datos en S3 requieren el permiso de Lake Formation ALL (SUPER).
+ Los trabajos de Spark que interactúan con el Catálogo de datos de Glue requieren los permisos DESCRIBIR, MODIFICAR o DESCARTAR, según corresponda.
Para obtener más información, consulte [Granting permissions on Data Catalog resources](https://docs.aws.amazon.com/lake-formation/latest/dg/granting-catalog-permissions.html).
### Paso 3: inicialización de una sesión de Spark para el acceso completo a la tabla mediante Lake Formation
#### Requisitos previos
AWS El catálogo de datos de Glue debe configurarse como un metaalmacén para acceder a las tablas de Lake Formation.
Para configurar el catálogo de Glue como repositorio de metadatos, establezca la siguiente configuración:
```
--conf spark.sql.catalogImplementation=hive
--conf spark.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory
```
Para obtener más información sobre cómo habilitar el catálogo de datos para Amazon EMR en EC2, consulte [Configuración de Metastore para Amazon EMR](metastore-config.html) en EC2.
Para acceder a las tablas registradas en AWS Lake Formation, se deben establecer las siguientes configuraciones durante la inicialización de Spark para configurar Spark para que use las credenciales de AWS Lake Formation.
------
#### [ 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 el sistema de archivos EMR (EMRFS) o el EMR S3A para usar las credenciales S3 de Lake Formation para las tablas registradas de AWS Lake Formation. Si la tabla no está registrada, utilice las credenciales del rol en tiempo de ejecución del trabajo.
+ `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` y `spark.hadoop.fs.s3.folderObject.autoAction.disabled=true`: configure EMRFS para que utilice el encabezado de tipo de contenido application/x-directory en lugar del sufijo \$1folder\$1 al crear carpetas en S3. Esto es necesario para leer las tablas de Lake Formation, ya que las credenciales de Lake Formation no permiten leer carpetas de tablas que utilicen el sufijo \$1folder\$1.
+ `spark.sql.catalog.skipLocationValidationOnCreateTable.enabled=true`: configure Spark para omitir la validación de que la ubicación de la tabla esté vacía antes de crearla. Esto es necesario para las tablas registradas en Lake Formation, ya que las credenciales de Lake Formation necesarias para verificar que la ubicación esté vacía solo se encuentran disponibles después de crear la tabla de Catálogo de datos de Glue. Sin esta configuración, las credenciales del rol en tiempo de ejecución del trabajo validarán si la ubicación de la tabla está vacía.
+ `spark.sql.catalog.createDirectoryAfterTable.enabled=true`: configure Spark para crear la carpeta en Amazon S3 después de crear la tabla en el repositorio de metadatos de Hive. Esto es necesario para tablas registradas en Lake Formation, ya que las credenciales de Lake Formation necesarias para crear la carpeta en S3 solo se encuentran disponibles después de crear la tabla de Catálogo de datos de Glue.
+ `spark.sql.catalog.dropDirectoryBeforeTable.enabled=true`: configure Spark para descartar la carpeta en S3 antes de eliminar la tabla del repositorio de metadatos de Hive. Esto es necesario para las tablas registradas en Lake Formation, ya que las credenciales de Lake Formation para descartar la carpeta de S3 no están disponibles después de eliminar la tabla del Catálogo de datos de Glue.
+ `spark.sql.catalog..glue.lakeformation-enabled=true`: Configure el catálogo de Iceberg para usar las credenciales S3 de AWS Lake Formation para las tablas registradas de Lake Formation. Si la tabla no está registrada, utilice las credenciales predeterminadas del entorno.
#### Configure el modo de acceso completo a las tablas en SageMaker Unified Studio
Para acceder a las tablas registradas de Lake Formation desde las sesiones interactivas de Spark en JupyterLab cuadernos, usa el modo de permiso de compatibilidad. Use el comando mágico %%configure para configurar Spark. Elija la configuración según el tipo de tabla:
------
#### [ 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"
}
}
```
------
Reemplace los marcadores de posición:
+ `S3_DATA_LOCATION`: la ruta de su bucket de S3
+ `REGION`: AWS región (por ejemplo, us-east-1)
+ `ACCOUNT_ID`: El ID de tu cuenta AWS
**nota**
Debe establecer estas configuraciones antes de ejecutar cualquier operación de Spark en el bloc de notas.
#### Operaciones admitidas
Estas operaciones utilizarán las credenciales de AWS Lake Formation para acceder a los datos de la tabla.
+ CREATE TABLE
+ ALTER TABLE
+ INSERT INTO
+ INSERT OVERWRITE
+ UPDATE
+ MERGE INTO
+ DELETE FROM
+ ANALIZAR TABLA
+ REPARAR TABLA
+ DROP TABLE
+ Consultas de orígenes de datos de Spark
+ Escrituras de orígenes de datos de Spark
**nota**
Las operaciones no mencionadas anteriormente aún usan permisos de IAM para acceder a los datos de las tablas.
#### Consideraciones
+ Si una tabla de Hive se crea mediante un trabajo que no tiene habilitado el acceso completo a la tabla y no se insertan registros, las lecturas o escrituras posteriores desde un trabajo con acceso completo a la tabla fallarán. Esto se debe a que, cuando no tiene habilitado el acceso completo a la tabla, EMR Spark agrega el sufijo `$folder$` al nombre de la carpeta de la tabla. Para resolver esto, puede optar por una de las siguientes acciones:
+ Insertar al menos una fila en la tabla desde un trabajo que no tenga FTA habilitado.
+ Configure el trabajo que no tiene FTA habilitado para evitar el uso del sufijo `$folder$` en el nombre de la carpeta en S3. Esto se logra al configurar `spark.hadoop.fs.s3.useDirectoryHeaderAsFolderObject=true` en Spark.
+ Cree una carpeta S3 en la ubicación de la tabla `s3://path/to/table/table_name` mediante la consola AWS S3 o la CLI de AWS S3.
+ El acceso completo a las tablas es compatible con el sistema de archivos EMR (EMRFS) a partir de la versión 7.8.0 de Amazon EMR y con el sistema de archivos S3A a partir de la versión 7.10.0 de Amazon EMR.
+ Las tablas Hive, Iceberg, Delta y Hudi admiten el acceso completo a la tabla.
+ **Consideraciones sobre Hudi FTA Write Support:**
+ Las escrituras Hudi FTA deben usarse para la venta de credenciales HoodieCredentialedHadoopStorage durante la ejecución del trabajo. Establezca la siguiente configuración al ejecutar los trabajos de Hudi: `hoodie.storage.class=org.apache.spark.sql.hudi.storage.HoodieCredentialedHadoopStorage`
+ El soporte de escritura Full Table Access (FTA) para Hudi está disponible a partir de la versión 7.12 de Amazon EMR.
+ Actualmente, la compatibilidad con la escritura Hudi FTA solo funciona con las configuraciones de Hudi predeterminadas. Los ajustes de Hudi personalizados o no predeterminados podrían no ser totalmente compatibles y podrían causar un comportamiento inesperado.
+ En este momento, no se admite la agrupación en clústeres para tablas Hudi Merge-On-Read (MOR) en el modo de escritura FTA.
+ Los trabajos que hagan referencia a tablas con reglas de control de acceso detallado (FGAC) de Lake Formation o con vistas del Catálogo de datos de Glue generarán errores. Para consultar una tabla con reglas de FGAC o una vista del Catálogo de datos de Glue, debe usar el modo FGAC. Puede activar el modo FGAC siguiendo los pasos descritos en la AWS documentación: Uso de [Amazon EMR en EC2 con Lake AWS Formation](emr-serverless-lf-enable.html) para un control de acceso detallado.
+ El acceso completo a tablas no ofrece compatibilidad con Spark Streaming.
+ Al DataFrame escribir Spark en una tabla de Lake Formation, solo se admite el modo APPEND para las tablas Hive e Iceberg: `df.write.mode("append").saveAsTable(table_name)`
+ La creación de tablas externas requiere permisos de IAM.
+ Como Lake Formation almacena temporalmente en caché las credenciales de un trabajo de Spark, es posible que los trabajos por lotes o las sesiones interactivas de Spark que se estén ejecutando no reflejen los cambios de permisos.
+ Debe utilizar un rol definido por el usuario, no uno vinculado a un servicio: [Requisitos de Lake Formation en relación con los roles](https://docs.aws.amazon.com/lake-formation/latest/dg/registration-role.html).
#### Hudi FTA Write Support: operaciones compatibles
La siguiente tabla muestra las operaciones de escritura compatibles con las tablas Hudi Copy-On-Write (COW) y Merge-On-Read (MOR) en el modo de acceso completo a la tabla:
**Operaciones de escritura compatibles con Hudi FTA**
| Tipo de tabla | Operación | Comando de escritura SQL | Status |
| --- | --- | --- | --- |
| VACA | INSERT | INSERT INTO TABLE | compatible |
| VACA | INSERT | INSERTAR EN LA TABLA: PARTICIÓN (estática, dinámica) | compatible |
| VACA | INSERT | INSERT OVERWRITE | compatible |
| VACA | INSERT | INSERTAR SOBRESCRITURA: PARTICIÓN (estática, dinámica) | compatible |
| UPDATE | UPDATE | UPDATE TABLE | compatible |
| VACA | UPDATE | TABLA DE ACTUALIZACIÓN: cambiar partición | No es compatible |
| DELETE | DELETE | DELETE FROM TABLE | compatible |
| ALTER | ALTER | MODIFICAR TABLA: CAMBIAR EL NOMBRE A | No es compatible |
| VACA | ALTER | ALTERAR UNA TABLA: ESTABLECER LAS PROPIEDADES DE LA TABLA | compatible |
| VACA | ALTER | ALTER TABLE - DESCONFIGURAR TBLPROPERTIES | compatible |
| VACA | ALTER | ALTERAR TABLA - ALTERAR COLUMNA | compatible |
| VACA | ALTER | MODIFICAR TABLA: AGREGAR COLUMNAS | compatible |
| VACA | ALTER | ALTERAR TABLA: AGREGAR PARTICIÓN | compatible |
| VACA | ALTER | ALTERAR TABLA - ELIMINAR PARTICIÓN | compatible |
| VACA | ALTER | ALTERAR TABLA: RECUPERAR PARTICIONES | compatible |
| VACA | ALTER | REPARAR PARTICIONES DE SINCRONIZACIÓN DE TABLAS | compatible |
| DROP | DROP | DROP TABLE | compatible |
| VACA | DROP | TABLA DESPLEGABLE - PURGAR | compatible |
| CREATE | CREATE | CREAR TABLA: gestionado | compatible |
| VACA | CREATE | CREAR TABLA: PARTICIONAR POR | compatible |
| VACA | CREATE | CREAR TABLA SI NO EXISTE | compatible |
| VACA | CREATE | CREATE TABLE LIKE | compatible |
| VACA | CREATE | CREATE TABLE AS SELECT | compatible |
| CREATE | CREATE | CREAR TABLA CON UBICACIÓN - Tabla externa | No es compatible |
| MARCO DE DATOS (INSERTAR) | MARCO DE DATOS (INSERTAR) | saveAsTable.Sobrescribir | compatible |
| VACA | MARCO DE DATOS (INSERTAR) | saveAsTable.Anexar | No es compatible |
| VACA | MARCO DE DATOS (INSERTAR) | saveAsTable.Ignorar | compatible |
| VACA | MARCO DE DATOS (INSERTAR) | saveAsTable.ErrorIfExists | compatible |
| VACA | MARCO DE DATOS (INSERTAR) | saveAsTable - Tabla externa (ruta) | No es compatible |
| VACA | MARCO DE DATOS (INSERTAR) | guardar (ruta) - DF v1 | No es compatible |
| MÁS | INSERT | INSERT INTO TABLE | compatible |
| MÁS | INSERT | INSERTAR EN LA TABLA: PARTICIÓN (estática, dinámica) | compatible |
| MÁS | INSERT | INSERT OVERWRITE | compatible |
| MÁS | INSERT | INSERTAR SOBRESCRITURA: PARTICIÓN (estática, dinámica) | compatible |
| UPDATE | UPDATE | UPDATE TABLE | compatible |
| MÁS | UPDATE | TABLA DE ACTUALIZACIÓN: cambiar partición | No es compatible |
| DELETE | DELETE | DELETE FROM TABLE | compatible |
| ALTER | ALTER | MODIFICAR TABLA: CAMBIAR EL NOMBRE A | No es compatible |
| MÁS | ALTER | MODIFICAR UNA TABLA: ESTABLECER LAS PROPIEDADES DE LA TABLA | compatible |
| MÁS | ALTER | MODIFICAR TABLA - DESCONFIGURAR TBLPROPERTIES | compatible |
| MÁS | ALTER | ALTERAR TABLA - ALTERAR COLUMNA | compatible |
| MÁS | ALTER | MODIFICAR TABLA: AGREGAR COLUMNAS | compatible |
| MÁS | ALTER | ALTERAR TABLA: AGREGAR PARTICIÓN | compatible |
| MÁS | ALTER | ALTERAR UNA TABLA: ELIMINAR UNA PARTICIÓN | compatible |
| MÁS | ALTER | ALTERAR UNA TABLA: RECUPERAR PARTICIONES | compatible |
| MÁS | ALTER | REPARAR PARTICIONES DE SINCRONIZACIÓN DE TABLAS | compatible |
| DROP | DROP | DROP TABLE | compatible |
| MÁS | DROP | TABLA DESPLEGABLE - PURGAR | compatible |
| CREATE | CREATE | CREAR TABLA: gestionado | compatible |
| MÁS | CREATE | CREAR TABLA: PARTICIONAR POR | compatible |
| MÁS | CREATE | CREAR TABLA SI NO EXISTE | compatible |
| MÁS | CREATE | CREATE TABLE LIKE | compatible |
| MÁS | CREATE | CREATE TABLE AS SELECT | compatible |
| CREATE | CREATE | CREAR TABLA con UBICACIÓN - Tabla externa | No es compatible |
| MARCO DE DATOS (ALTERADO) | MARCO DE DATOS (ALTERADO) | saveAsTable.Sobrescribir | compatible |
| MÁS | MARCO DE DATOS (ALTERADO) | saveAsTable.Anexar | No es compatible |
| MÁS | MARCO DE DATOS (ALTERADO) | saveAsTable.Ignorar | compatible |
| MÁS | MARCO DE DATOS (ALTERADO) | saveAsTable.ErrorIfExists | compatible |
| MÁS | MARCO DE DATOS (ALTERADO) | saveAsTable - Tabla externa (ruta) | No es compatible |
| • MÁS | MARCO DE DATOS (ALTERADO) | guardar (ruta) - DF v1 | No es compatible |
| MARCO DE DATOS (ELIMINAR) | MARCO DE DATOS (ELIMINAR) | saveAsTable.Anexar | No es compatible |
| MÁS | MARCO DE DATOS (ELIMINAR) | saveAsTable - Tabla externa (ruta) | No es compatible |
| • MÁS | MARCO DE DATOS (ELIMINAR) | guardar (ruta) - DF v1 | No es compatible |
| MARCO DE DATOS (BULK\$1INSERT) | MARCO DE DATOS (BULK\$1INSERT) | saveAsTable.Sobrescribir | compatible |
| MÁS | MARCO DE DATOS (BULK\$1INSERT) | saveAsTable.Anexar | No es compatible |
| MÁS | MARCO DE DATOS (BULK\$1INSERT) | saveAsTable.Ignorar | compatible |
| MÁS | MARCO DE DATOS (BULK\$1INSERT) | saveAsTable.ErrorIfExists | compatible |
| MÁS | MARCO DE DATOS (BULK\$1INSERT) | saveAsTable - Tabla externa (ruta) | No es compatible |
| • MÁS | MARCO DE DATOS (BULK\$1INSERT) | guardar (ruta) - DF v1 | No es compatible |
# Integración de Amazon EMR con Apache Ranger
A partir de Amazon EMR 5.32.0, puede iniciar un clúster que se integre de forma nativa con Apache Ranger. Apache Ranger es un marco de código abierto para habilitar, supervisar y administrar la seguridad integral de los datos en toda la plataforma Hadoop. Para obtener más información, consulte [Apache Ranger](https://ranger.apache.org/). Con la integración nativa, puede utilizar su propio Apache Ranger para aplicar un control de acceso a los datos detallado en Amazon EMR.
Esta sección proporciona información general sobre la integración de Amazon EMR con Apache Ranger. También incluye los requisitos previos y los pasos necesarios para lanzar un clúster de Amazon EMR integrado con Apache Ranger.
La integración nativa de Amazon EMR con Apache Ranger ofrece los siguientes beneficios clave:
+ Control de acceso detallado a las bases de datos y tablas del metaalmacén de Hive, que le permite definir políticas de filtrado de datos en bases de datos, tablas y columnas para las aplicaciones Apache Spark y Apache Hive. Las aplicaciones de Hive admiten el filtrado de filas y el enmascaramiento de datos.
+ La posibilidad de utilizar sus políticas de Hive existentes directamente con las aplicaciones de Amazon EMR para Hive.
+ Control de acceso a los datos de prefijos y objetos de Amazon S3, lo que le permite definir políticas de filtrado de datos para acceder a los datos de S3 mediante el sistema de archivos de EMR.
+ La capacidad de utilizar CloudWatch los registros para una auditoría centralizada.
+ Amazon EMR instala y administra los complementos de Apache Ranger en su nombre.
**importante**
Amazon EMR no admite la integración de Apache Ranger a partir de la versión 7.4 de Amazon EMR. Para obtener más información, consulte [Amazon EMR versión](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-740-release.html) 7.4.0.
# Apache Ranger con Amazon EMR
Apache Ranger es un marco para habilitar, supervisar y administrar la seguridad integral de los datos en toda la plataforma Hadoop.
Apache Ranger tiene las siguientes características:
+ Administración de seguridad centralizada para gestionar todas las tareas relacionadas con la seguridad en una interfaz de usuario central o mediante REST. APIs
+ Autorización detallada para realizar una acción u operación específica con un componente o herramienta de Hadoop, administrada a través de una herramienta de administración central.
+ Un método de autorización estandarizado para todos los componentes de Hadoop.
+ Compatibilidad mejorada para varios métodos de autorización.
+ Auditoría centralizada del acceso de los usuarios y de las acciones administrativas (relacionadas con la seguridad) en todos los componentes de Hadoop.
Apache Ranger utiliza dos componentes clave para la autorización:
+ **Servidor de administración de políticas de Apache Ranger**: este servidor le permite definir las políticas de autorización para las aplicaciones de Hadoop. Al llevar a cabo la integración con Amazon EMR, podrá definir y aplicar políticas para que Apache Spark y Hive accedan al metaalmacén de Hive, así como para acceder al [Sistema de archivos de EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-fs) de datos de Amazon S3. Puede configurar un servidor de administración de políticas de Apache Ranger nuevo o utilizar uno existente para integrarlo con Amazon EMR.
+ **Complemento de Apache Ranger**: este complemento valida el acceso de un usuario según las políticas de autorización definidas en el servidor de administración de políticas de Apache Ranger. Amazon EMR instala y configura el complemento Apache Ranger automáticamente para cada aplicación de Hadoop seleccionada en la configuración de Apache Ranger.
**Topics**
+ [Arquitectura de la integración de Amazon EMR con Apache Ranger](emr-ranger-architecture.md)
+ [Componentes de Amazon EMR para su uso con Apache Ranger](emr-ranger-components.md)
# Arquitectura de la integración de Amazon EMR con Apache Ranger
![\[Diagrama de arquitectura de Amazon EMR y Apache Ranger.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/emr-ranger-architecture.png)
# Componentes de Amazon EMR para su uso con Apache Ranger
Amazon EMR permite obtener un control integral del acceso con Apache Ranger mediante los siguientes componentes. Consulte el [diagrama de arquitectura](emr-ranger-architecture.md) para ver una representación visual de estos componentes de Amazon EMR con los complementos de Apache Ranger.
**Agente secreto**: el agente secreto almacena secretos de forma segura y los distribuye a otros componentes o aplicaciones de Amazon EMR. Los secretos pueden incluir credenciales de usuario temporales, claves de cifrado o tickets de Kerberos. El agente secreto se ejecuta en todos los nodos del clúster e intercepta las llamadas al servicio de metadatos de la instancia. Para las solicitudes de credenciales del rol del perfil de instancia, el agente secreto vende las credenciales en función del usuario solicitante y de los recursos solicitados tras autorizar la solicitud con el complemento S3 Ranger de EMRFS. El agente secreto se ejecuta como el *`emrsecretagent`*usuario y escribe los registros en el emr/secretagent/log directorio/. El proceso recurre a un conjunto específico de reglas `iptables` para funcionar. Es importante asegurarse de que `iptables` no esté deshabilitado. Si personaliza la configuración de `iptables`, las reglas de la tabla NAT deben conservarse y no modificarse.
**Servidor de registros de EMR**: el servidor de registros recibe las solicitudes de Spark para acceder a los datos. A continuación, autoriza las solicitudes reenviando los recursos solicitados al complemento Spark Ranger para Amazon EMR. El servidor de registros lee los datos de Amazon S3 y devuelve los datos filtrados a los que el usuario está autorizado a acceder según la política de Ranger. El servidor de registros se ejecuta en todos los nodos del clúster como usuario emr\$1record\$1server y escribe los registros en el directorio/-record-server. var/log/emr
# Consideraciones sobre cómo usar Amazon EMR con Apache Ranger
## Aplicaciones compatibles para Amazon EMR con Apache Ranger
La integración entre Amazon EMR y Apache Ranger, en la que EMR instala los complementos de Ranger, actualmente admite las siguientes aplicaciones:
+ Apache Spark (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Apache Hive (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Acceso a S3 a través de EMRFS (disponible con EMR 5.32\$1 y EMR 6.3\$1)
Las siguientes aplicaciones se pueden instalar en un clúster de EMR y es posible que deban configurarse para satisfacer sus necesidades de seguridad:
+ Apache Hadoop (disponible con EMR 5.32\$1 y EMR 6.3\$1, incluidos YARN y HDFS)
+ Apache Livy (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Apache Zeppelin (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Apache Hue (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Ganglia (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ HCatalog (Disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Mahout (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ MXNet (Disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ TensorFlow (Disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Tez (disponible con EMR 5.32\$1 y EMR 6.3\$1)
+ Trino (disponible con EMR 6.7\$1)
+ ZooKeeper (Disponible con EMR 5.32\$1 y EMR 6.3\$1)
**importante**
Las aplicaciones enumeradas anteriormente son las únicas aplicaciones compatibles actualmente. Para garantizar la seguridad del clúster, se le permite crear un clúster de EMR solo con las aplicaciones de la lista anterior cuando Apache Ranger esté habilitado.
Actualmente no se admiten otras aplicaciones. Para garantizar la seguridad de su clúster, este se rechazará si intenta instalar otras aplicaciones.
AWS No se admiten los formatos Glue Data Catalog y Open table, como Apache Hudi, Delta Lake y Apache Iceberg.
**Características compatibles de Amazon EMR con Apache Range**
Las siguientes características de Amazon EMR son compatibles cuando usa Amazon EMR con Apache Ranger:
+ Cifrado en reposo y en tránsito
+ Autenticación de Kerberos (obligatoria)
+ Grupos de instancias, flotas de instancias e instancias de spot
+ Reconfiguración de aplicaciones en un clúster en ejecución
+ Cifrado del servidor (SSE) de EMRFS
**nota**
La configuración de cifrado de Amazon EMR rige el SSE. Para obtener más información, consulte [Opciones de cifrado](emr-data-encryption-options.md).
## Limitaciones de la aplicación
Hay varias limitaciones que se deben tener en cuenta al integrar Amazon EMR y Apache Ranger:
+ Actualmente, no puede utilizar la consola para crear una configuración de seguridad que especifique la opción de integración con AWS Ranger en. AWS GovCloud (US) Region La configuración de seguridad se puede llevar a cabo con la CLI.
+ Kerberos tiene que estar instalado en el clúster.
+ Las aplicaciones UIs (interfaces de usuario), como la interfaz de usuario del administrador de recursos de YARN, la interfaz de usuario de HDFS y la NameNode interfaz de usuario de Livy, no están configuradas con la autenticación de forma predeterminada.
+ Los permisos predeterminados de HDFS `umask` están configurados de forma que los objetos creados tengan el valor `world wide readable` de forma predeterminada.
+ Amazon EMR no admite el modo de alta disponibilidad (varias entidades principales) con Apache Ranger.
+ Para ver otras limitaciones, consulte las limitaciones de cada aplicación.
**nota**
La configuración de cifrado de Amazon EMR rige el SSE. Para obtener más información, consulte [Opciones de cifrado](emr-data-encryption-options.md).
## Limitaciones del complemento
Cada complemento tiene limitaciones específicas. Para ver las limitaciones del complemento Apache Hive, consulte [Apache Hive plugin limitations](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-hive.html#emr-ranger-hive-limitations). Para ver las limitaciones del complemento Apache Spark, consulte [Apache Spark plugin limitations](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-spark.html#emr-ranger-spark-limitations). Para ver las limitaciones del complemento EMRFS S3, consulte [EMRFS S3 plugin limitations](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-emrfs.html#emr-ranger-emrfs-limitations).
# Configuración de Amazon EMR para Apache Ranger
Antes de instalar Apache Ranger, revise la información de esta sección para asegurarse de que Amazon EMR esté correctamente configurado.
**Topics**
+ [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md)
+ [Roles de IAM para la integración nativa con Apache Ranger](emr-ranger-iam.md)
+ [Creación de la configuración de seguridad de EMR](emr-ranger-security-config.md)
+ [Guarde los certificados TLS en AWS Secrets Manager](emr-ranger-tls-certificates.md)
+ [Inicio de un clúster de EMR con Apache Ranger](emr-ranger-start-emr-cluster.md)
+ [Configuración de Zeppelin para clústeres de Amazon EMR habilitados para Apache Ranger](emr-ranger-configure-zeppelin.md)
+ [Problemas conocidos para la integración de Amazon EMR](emr-ranger-security-considerations.md)
# Configure un servidor Ranger Admin para integrarlo con Amazon EMR
Para la integración de Amazon EMR, los complementos de la aplicación Apache Ranger deben comunicarse con el servidor de administración mediante TLS/SSL.
**Requisito previo: habilitación del protocolo SSL del servidor de Ranger Admin**
Apache Ranger en Amazon EMR requiere una comunicación SSL bidireccional entre los complementos y el servidor de Ranger Admin. Para garantizar que los complementos se comuniquen con el servidor Apache Ranger a través de SSL, habilite el siguiente atributo dentro de ranger-admin-site .xml en el servidor de administración de Ranger.
```
ranger.service.https.attrib.ssl.enabled
true
```
Además, se requieren las siguientes configuraciones:
```
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 la integración de Apache Ranger con Amazon EMR
La integración de Apache Ranger con Amazon EMR requiere que el tráfico desde los nodos de Amazon EMR al servidor de Ranger Admin esté cifrado mediante TLS y que los complementos de Ranger se autentiquen en el servidor de Apache Ranger mediante una autenticación TLS mutua bidireccional. El servicio Amazon EMR necesita el certificado público de su servidor de Ranger Admin (especificado en el ejemplo anterior) y el certificado privado.
**Certificados del complemento Apache Ranger**
El servidor de Apache Ranger Admin debe poder acceder a los certificados TLS públicos del complemento Apache Ranger para validarlos cuando se conecten los complementos. Hay tres métodos diferentes para hacerlo.
**Método 1: configuración de un almacén de confianza en el servidor de Apache Ranger Admin**
Rellene las siguientes configuraciones en ranger-admin-site .xml para configurar un almacén de confianza.
```
ranger.truststore.file
ranger.truststore.password
```
**Método 2: carga del certificado en el almacén de confianza de certificados CA (cacerts) de Java**
Si el servidor de Ranger Admin no especifica un almacén de confianza en sus opciones de JVM, puede colocar los certificados públicos del complemento en el almacén de cacerts predeterminado.
**Método 3: creación de un almacén de confianza y configuración como parte de las opciones de JVM**
En `{RANGER_HOME_DIRECTORY}/ews/ranger-admin-services.sh`, modifique `JAVA_OPTS` para que incluya `"-Djavax.net.ssl.trustStore="` y `"-Djavax.net.ssl.trustStorePassword="`. Por ejemplo, agregue la siguiente línea después de la variable JAVA\$1OPTS existente.
```
JAVA_OPTS=" ${JAVA_OPTS} -Djavax.net.ssl.trustStore=${RANGER_HOME}/truststore/truststore.jck -Djavax.net.ssl.trustStorePassword=changeit"
```
**nota**
Esta especificación puede exponer la contraseña del almacén de confianza si algún usuario puede iniciar sesión en el servidor de Apache Ranger Admin y ver los procesos en ejecución, por ejemplo, cuando utiliza el comando `ps`.
**Uso de certificados autofirmados**
Los certificados autofirmados no se recomiendan como certificados. Los certificados autofirmados no se pueden revocar y los certificados autofirmados pueden no cumplir con los requisitos de seguridad internos.
# Instalación de definición de servicio para la integración de Ranger con Amazon EMR
El servidor de Ranger Admin utiliza una definición de servicio para describir los atributos de las políticas de una aplicación. Luego, las políticas se almacenan en un repositorio de políticas para que los clientes las descarguen.
Para poder configurar las definiciones de servicio, las llamadas REST se deben realizar al servidor de Ranger Admin. Consulte [Apache Ranger Public APIsv2](https://ranger.apache.org/apidocs/resource_PublicAPIsv2.html#resource_PublicAPIsv2_createServiceDef_POST) para ver si es APIs obligatorio en la siguiente sección.
**Instalación de la definición de servicio de Apache Spark**
Para instalar la definición de servicio de Apache Spark, consulte [Complemento de Apache Spark para la integración de Ranger con Amazon EMR](emr-ranger-spark.md).
**Instalación de la definición de servicio de EMRFS**
Para instalar la definición de servicio de S3 para Amazon EMR, consulte [Complemento EMRFS S3 para la integración de Ranger con Amazon EMR](emr-ranger-emrfs.md).
**Uso de la definición de servicio de Hive**
Apache Hive puede usar la definición de servicio de Ranger existente que se incluye con Apache Ranger 2.0 y versiones posteriores. Para obtener más información, consulte [Complemento de Apache Hive para la integración de Ranger con Amazon EMR](emr-ranger-hive.md).
# Reglas de tráfico de red para la integración con Amazon EMR
Cuando Apache Ranger se integra con su clúster de EMR, el clúster debe comunicarse con servidores adicionales y AWS.
Todos los nodos de Amazon EMR, incluidos los nodos principales y de tareas, deben poder comunicarse con los servidores de Apache Ranger Admin para descargar las políticas. Si su servidor de Apache Ranger Admin se ejecuta en Amazon EC2, debe actualizar el grupo de seguridad para poder captar el tráfico del clúster de EMR.
Además de comunicarse con el servidor Ranger Admin, todos los nodos deben poder comunicarse con los siguientes servicios: AWS
+ Amazon S3
+ AWS KMS (si usa EMRFS SSE-KMS)
+ Amazon CloudWatch
+ AWS STS
Si planea ejecutar su clúster de EMR en una subred privada, configure la VPC para que pueda comunicarse con estos servicios mediante [AWS PrivateLink y puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) en la *Guía del usuario de Amazon VPC* o mediante una [instancia de traducción de direcciones de red (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) de la *Guía del usuario de Amazon VPC*.
# Roles de IAM para la integración nativa con Apache Ranger
La integración entre Amazon EMR y Apache Ranger se basa en tres roles clave que debe crear antes de lanzar el clúster:
+ Un perfil de instancia de Amazon EC2 personalizado para Amazon EMR
+ Un rol de IAM para los motores de Apache Ranger
+ Una función de IAM para otros servicios AWS
Esta sección proporciona información general sobre estos roles y las políticas que debe incluir en cada rol de IAM. Para obtener más información sobre la creación de estos roles, consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md).
# Perfil de instancia de EC2 para Amazon EMR
Amazon EMR utiliza un rol de servicio de IAM para realizar acciones en su nombre para aprovisionar y administrar clústeres. El rol de servicio para instancias de EC2 de clúster, también conocido como el perfil de instancia de EC2 para Amazon EMR, es un tipo especial de rol de servicio asignado a cada instancia de EC2 de un clúster en el momento del lanzamiento.
Para definir los permisos para la interacción del clúster de EMR con los datos de Amazon S3 y con el metaalmacén de Hive protegido por Apache Ranger y otros AWS servicios, defina un perfil de instancia EC2 personalizado para usarlo en lugar del que se utiliza al lanzar el `EMR_EC2_DefaultRole` clúster.
Para obtener más información, consulte [Rol de servicio para instancias de EC2 del clúster (perfil de instancia de EC2)](emr-iam-role-for-ec2.md) y [Personalización de roles de IAM con Amazon EMR](emr-iam-roles-custom.md).
Debe añadir las siguientes instrucciones al perfil de instancia EC2 predeterminado de Amazon EMR para poder etiquetar las sesiones y acceder al que almacena AWS Secrets Manager los 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 los permisos de Secrets Manager, no olvide el comodín (“\$1”) que aparece al final del nombre del secreto o sus solicitudes fallarán. El comodín es para las versiones de los secretos.
**nota**
Limite el alcance de la AWS Secrets Manager política a solo los certificados necesarios para el aprovisionamiento.
# Rol de IAM para Apache Ranger
Este rol proporciona credenciales para que los motores de ejecución de confianza, como Apache Hive y Servidor de registros de Amazon EMR, puedan acceder a los datos de Amazon S3. Utilice únicamente este rol para acceder a los datos de Amazon S3, incluidas las claves de KMS, si utiliza S3 SSE-KMS.
Este rol debe crearse con la política mínima que se indica en el siguiente ejemplo.
------
#### [ 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**
Se debe incluir el asterisco «\$1» al final del recurso de CloudWatch registro para permitir escribir en los flujos de registro.
**nota**
Si utiliza la visión de consistencia de EMRFS o el cifrado S3-SSE, agregue permisos a las tablas de DynamoDB y a las claves de KMS para que los motores de ejecución puedan interactuar con esos motores.
El rol de IAM de Apache Ranger lo asume el rol de perfil de instancia de EC2. Utilice el siguiente ejemplo para crear una política de confianza que permita que el rol de perfil de instancia de EC2 asuma el rol de IAM de Apache Ranger.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Función de IAM para otros AWS servicios de integración de Amazon EMR
Esta función proporciona a los usuarios que no son motores de ejecución de confianza credenciales para interactuar con los AWS servicios, si las necesitan. No utilice este rol de IAM para permitir el acceso a los datos de Amazon S3, a menos que se trate de datos a los que deberían poder acceder todos los usuarios.
Este rol lo asumirá el rol de perfil de instancia de EC2. Utilice el siguiente ejemplo para crear una política de confianza que permita que el rol de perfil de instancia de EC2 asuma el rol de IAM de Apache Ranger.
```
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
```
# Valide sus permisos para la integración de Amazon EMR con Apache Ranger
Consulte [Solución de problemas con Apache Ranger](emr-ranger-troubleshooting.md) para obtener instrucciones sobre cómo validar los permisos.
# Creación de la configuración de seguridad de EMR
**Creación de una configuración de seguridad de Amazon EMR para Apache Ranger**
Antes de lanzar un clúster de Amazon EMR integrado con Apache Ranger, cree una configuración de seguridad.
------
#### [ Console ]
**Para crear una configuración de seguridad que especifique la opción de integración con AWS Ranger**
1. En la consola de Amazon EMR, seleccione **Configuraciones de seguridad** y, a continuación, **Crear**.
1. Escriba un nombre para la configuración de seguridad en el campo **Name (Nombre)**. Este nombre se utiliza para especificar la configuración de seguridad cuando crea un clúster.
1. En **Integración con AWS Ranger**, seleccione **Habilitar un control de acceso detallado administrado por Apache Ranger**.
1. Seleccione un **rol de IAM para que Apache Ranger** lo aplique. Para obtener más información, consulte [Roles de IAM para la integración nativa con Apache Ranger](emr-ranger-iam.md).
1. Seleccione un **rol de IAM para que otros servicios de AWS ** lo apliquen.
1. Configure los complementos para que se conecten al servidor Ranger Admin introduciendo el ARN de Secrets Manager del servidor de Admin y la dirección.
1. Seleccione las aplicaciones para configurar los complementos de Ranger. Introduzca el ARN de Secrets Manager que contiene el certificado TLS privado del complemento.
Si no configura Apache Spark ni Apache Hive y los selecciona como aplicaciones para su clúster, la solicitud fallará.
1. Defina otras opciones de configuración de seguridad según corresponda y elija **Create (Crear)**. Debe habilitar la autenticación de Kerberos mediante el KDC dedicado del clúster o un KDC externo.
**nota**
Actualmente, no puede utilizar la consola para crear una configuración de seguridad que especifique la opción de integración con AWS Ranger en el. AWS GovCloud (US) Region La configuración de seguridad se puede llevar a cabo con la CLI.
------
#### [ CLI ]
**Para crear una configuración de seguridad para la integración de Apache Ranger**
1. ``Sustitúyala por tu ID AWS de cuenta.
1. Sustituya `` por la región en la que se encuentra el recurso.
1. Especifique un valor para `TicketLifetimeInHours` para determinar el periodo para el que un vale de Kerberos generado por el KDC es válido.
1. Especifique la dirección del servidor de Ranger Admin de `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:__"
}
}
}
}
}
}
```
Estos PolicyRespositoryNames son los nombres de los servicios que se especifican en su administrador de Apache Ranger.
Cree una configuración de seguridad de Amazon EMR con el siguiente contenido. Sustituya la configuración de seguridad por el nombre de su elección. Seleccione esta configuración por el nombre al crear el clúster.
```
aws emr create-security-configuration \
--security-configuration file://./security-configuration.json \
--name security-configuration
```
------
**Configuración de características de seguridad adicionales**
Para integrar Amazon EMR de forma segura con Apache Range, configure las siguientes características de seguridad de EMR:
+ Habilite la autenticación de Kerberos mediante el KDC dedicado del clúster o un KDC externo. Para obtener instrucciones, consulte [Uso de Kerberos para la autenticación con Amazon EMR](emr-kerberos.md).
+ (Opcional) Habilite el cifrado en tránsito o en reposo. Para obtener más información, consulte [Opciones de cifrado para Amazon EMR](emr-data-encryption-options.md).
Para obtener más información, consulte [Seguridad en Amazon EMR](emr-security.md).
# Guarde los certificados TLS en AWS Secrets Manager
Los complementos de Ranger instalados en un clúster de Amazon EMR y el servidor de Ranger Admin deben comunicarse a través del protocolo TLS para garantizar que los datos de la política y otra información enviada no se puedan leer si se interceptan. EMR también exige que los complementos se autentiquen en el servidor de Ranger Admin proporcionando su propio certificado TLS y que realicen una autenticación TLS bidireccional. Esta configuración requería la creación de cuatro certificados: dos pares de certificados TLS públicos y privados. Para obtener instrucciones sobre cómo instalar el certificado en su servidor de Ranger Admin, consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md). Para completar la configuración, los complementos de Ranger instalados en el clúster de EMR necesitan dos certificados: el certificado TLS público de su servidor de administración y el certificado privado que el complemento utilizará para autenticarse en el servidor de Ranger Admin. Para proporcionar estos certificados TLS, deben estar en una configuración de seguridad de EMR AWS Secrets Manager y proporcionarse en ella.
**nota**
Se recomienda encarecidamente, pero no es obligatorio, crear un par de certificados para cada una de sus aplicaciones a fin de limitar el impacto en caso de que uno de los certificados del complemento se vea comprometido.
**nota**
Debe realizar un seguimiento de los certificados y rotarlos antes de su fecha de vencimiento.
## Formato del certificado
La importación de los certificados a la AWS Secrets Manager es la misma, independientemente de si se trata del certificado de complemento privado o del certificado de administrador de Ranger público. Antes de importar los certificados TLS, los certificados deben estar en formato PEM 509x.
Un ejemplo de certificado público tiene el siguiente formato:
```
-----BEGIN CERTIFICATE-----
...Certificate Body...
-----END CERTIFICATE-----
```
Un ejemplo de certificado privado tiene el siguiente formato:
```
-----BEGIN PRIVATE KEY-----
...Private Certificate Body...
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...Trust Certificate Body...
-----END CERTIFICATE-----
```
El certificado privado también debe contener un certificado de confianza.
Si desea obtener un certificado, debe ejecutar el siguiente comando:
```
openssl x509 -in -text
```
## Importación de un certificado al AWS Secrets Manager
Al crear su secreto en Secrets Manager, seleccione **Otro tipo de secretos** en **Tipo de secreto** y pegue su certificado cifrado en PEM en el campo **Texto no cifrado**.
![\[Importación de un certificado a AWS Secrets Manager.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-tls-cert-import.png)
# Inicio de un clúster de EMR con Apache Ranger
Antes de lanzar un clúster de Amazon EMR con Apache Ranger, asegúrese de que cada componente cumpla los siguientes requisitos mínimos de versión:
+ Amazon EMR 5.32.0 o posterior, o 6.3.0 o posterior. Le recomendamos que utilice la última versión de Amazon EMR.
+ Servidor de Apache Ranger Admin 2.x.
Siga estos pasos:
+ Instale Apache Ranger si aún no lo ha hecho. Para obtener más información acerca de la instalación, consulte [Apache Ranger 0.5.0 installation](https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+0.5.0+Installation).
+ Asegúrese de que haya conectividad de red entre el clúster de Amazon EMR y el servidor de Apache Ranger Admin. Consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md)
+ Cree los roles de IAM necesarios. Consulte [Roles de IAM para la integración nativa con Apache Ranger](emr-ranger-iam.md).
+ Cree una configuración de seguridad de EMR para la instalación de Apache Ranger. Para obtener más información, consulte [Creación de la configuración de seguridad de EMR](emr-ranger-security-config.md).
# Configuración de Zeppelin para clústeres de Amazon EMR habilitados para Apache Ranger
El tema trata sobre cómo configurar [Apache Zeppelin](https://zeppelin.apache.org/) para un clúster de Amazon EMR compatible con Apache Ranger, de modo que pueda utilizar Zeppelin como cuaderno para navegar por los datos de forma interactiva. Zeppelin se incluye en las versiones de 5.0.0 de Amazon EMR y posteriores. Las versiones anteriores incluyen Zeppelin como una aplicación de entorno aislado. Para obtener más información, consulte [Versiones de lanzamiento de Amazon EMR 4.x](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-4x.html) en la *Guía de publicación de Amazon EMR*.
De forma predeterminada, Zeppelin está configurado con una contraseña y un nombre de usuario predeterminados, lo que no es seguro en un entorno multiusuario.
Para configurar Zeppelin, siga los pasos que se describen a continuación:
1. **Modifique el mecanismo de autenticación**.
Modifique el archivo `shiro.ini` para implementar el mecanismo de autenticación que prefiera. Zeppelin admite Active Directory, LDAP, PAM y Knox SSO. Consulte [Apache Shiro authentication for Apache Zeppelin](https://zeppelin.apache.org/docs/0.8.2/setup/security/shiro_authentication.html) para obtener más información.
1. **Configure Zeppelin para suplantar al usuario final**
Si permite que Zeppelin suplante al usuario final, los trabajos enviados por Zeppelin se pueden ejecutar como ese usuario final. Agregue la siguiente configuración a `core-site.xml`:
```
[
{
"Classification": "core-site",
"Properties": {
"hadoop.proxyuser.zeppelin.hosts": "*",
"hadoop.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
A continuación, agregue la siguiente configuración a `hadoop-kms-site.xml`, que se encuentra en `/etc/hadoop/conf`:
```
[
{
"Classification": "hadoop-kms-site",
"Properties": {
"hadoop.kms.proxyuser.zeppelin.hosts": "*",
"hadoop.kms.proxyuser.zeppelin.groups": "*"
},
"Configurations": [
]
}
]
```
También puede agregar estas configuraciones a su clúster de Amazon EMR mediante la consola siguiendo los pasos que se indican en [Reconfiguración de un grupo de instancias en la consola](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html#emr-configure-apps-running-cluster-console).
1. **Permita que Zeppelin utilice el comando sudo como usuario final**
Cree un archivo `/etc/sudoers.d/90-zeppelin-user` que contenga lo siguiente:
```
zeppelin ALL=(ALL) NOPASSWD:ALL
```
1. **Modifique la configuración de los intérpretes para ejecutar las tareas de los usuarios en sus propios procesos**.
Configure todos los intérpretes para que creen instancias de los intérpretes “por usuario” en procesos “aislados”.
![\[Diagrama de arquitectura de Amazon EMR y Apache Ranger.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/per_user.png)
1. **Modifique `zeppelin-env.sh`**
Agregue lo siguiente a `zeppelin-env.sh` para que Zeppelin comience a lanzar los intérpretes como usuario final:
```
ZEPPELIN_IMPERSONATE_USER=`echo ${ZEPPELIN_IMPERSONATE_USER} | cut -d @ -f1`
export ZEPPELIN_IMPERSONATE_CMD='sudo -H -u ${ZEPPELIN_IMPERSONATE_USER} bash -c'
```
Agregue lo siguiente a `zeppelin-env.sh` para cambiar los permisos predeterminados del cuaderno a solo lectura únicamente para el creador:
```
export ZEPPELIN_NOTEBOOK_PUBLIC="false"
```
Por último, añada lo siguiente `zeppelin-env.sh` para incluir la ruta de la RecordServer clase EMR después de la primera `CLASSPATH` sentencia:
```
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. **Reinicie Zeppelin.**
Ejecute el siguiente comando para reiniciar Zeppelin:
```
sudo systemctl restart zeppelin
```
# Problemas conocidos para la integración de Amazon EMR
**Problemas conocidos**
Existe un problema conocido en la versión 5.32 de Amazon EMR en el que se modificaron los permisos de `hive-site.xml` para que solo los usuarios con privilegios pudieran leerlo, ya que es posible que haya credenciales almacenadas en él. Esto podría impedir que Hue leyera `hive-site.xml` y provocar que las páginas web se recargaran continuamente. Si experimenta este problema, agregue la siguiente configuración para solucionarlo:
```
[
{
"Classification": "hue-ini",
"Properties": {},
"Configurations": [
{
"Classification": "desktop",
"Properties": {
"server_group":"hive_site_reader"
},
"Configurations":[
]
}
]
}
]
```
Existe un problema conocido que hace que el complemento EMRFS S3 para Apache Ranger no sea compatible actualmente con la característica Zona de seguridad de Apache Ranger. Las restricciones de control de acceso definidas mediante la característica Zona de seguridad no se aplican a los clústeres de Amazon EMR.
**Aplicación UIs**
De forma predeterminada, las IU de las aplicaciones no realizan la autenticación. Esto incluye la ResourceManager interfaz de usuario, la interfaz de NodeManager usuario y la interfaz de usuario de Livy, entre otras. Además, cualquier usuario que tenga la posibilidad de acceder al UIs puede ver información sobre los trabajos de todos los demás usuarios.
Si no desea este comportamiento, debe asegurarse de que se utilice un grupo de seguridad para restringir el acceso de los usuarios a UIs la aplicación.
**Permisos predeterminados de HDFS**
De forma predeterminada, los objetos que los usuarios crean en HDFS reciben permisos legibles en todo el mundo. Esto puede provocar que los usuarios que no deberían tener acceder a los datos puedan leerlos. Para cambiar este comportamiento de forma que los permisos de archivo predeterminados sean de lectura y escritura únicamente para el creador del trabajo, lleve a cabo estos pasos.
Al crear el clúster de EMR, proporcione la siguiente configuración:
```
[
{
"Classification": "hdfs-site",
"Properties": {
"dfs.namenode.acls.enabled": "true",
"fs.permissions.umask-mode": "077",
"dfs.permissions.superusergroup": "hdfsadmingroup"
}
}
]
```
Además, ejecute la siguiente acción de arranque:
```
--bootstrap-actions Name='HDFS UMask Setup',Path=s3://elasticmapreduce/hdfs/umask/umask-main.sh
```
# Complementos Apache Ranger para escenarios de integración de Amazon EMR
Los complementos de Apache Ranger validan el acceso de un usuario según las políticas de autorización definidas en el servidor de administración de políticas de Apache Ranger.
**Topics**
+ [Complemento de Apache Hive para la integración de Ranger con Amazon EMR](emr-ranger-hive.md)
+ [Complemento de Apache Spark para la integración de Ranger con Amazon EMR](emr-ranger-spark.md)
+ [Complemento EMRFS S3 para la integración de Ranger con Amazon EMR](emr-ranger-emrfs.md)
+ [Complemento Trino para la integración de Ranger con Amazon EMR](emr-ranger-trino.md)
# Complemento de Apache Hive para la integración de Ranger con Amazon EMR
Apache Hive es un popular motor de ejecución dentro del ecosistema Hadoop. Amazon EMR proporciona un complemento de Apache Ranger para poder proporcionar controles de acceso detallados para Hive. El complemento es compatible con la versión 2.0 y posteriores del servidor de Apache Ranger Admin de código abierto.
**Topics**
+ [Características admitidas](#emr-ranger-supported-features)
+ [Instalación de la configuración del servicio](#emr-ranger-hive-service-config)
+ [Consideraciones](#emr-ranger-hive-considerations)
+ [Limitaciones](#emr-ranger-hive-limitations)
## Características admitidas
El complemento Apache Ranger para Hive en EMR admite todas las funciones del complemento de código abierto, que incluye controles de acceso a bases de datos, tablas y columnas, así como el filtrado de filas y el enmascaramiento de datos. Para ver una tabla de comandos de Hive y los permisos de Ranger asociados, consulte [Hive commands to Ranger permission mapping](https://cwiki.apache.org/confluence/display/RANGER/Hive+Commands+to+Ranger+Permission+Mapping).
## Instalación de la configuración del servicio
El complemento Apache Hive es compatible con la definición de servicio de Hive existente en Apache Hive Hadoop SQL.
![\[Definición de servicio de Apache Hive para Hadoop SQL.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger_service_mgr.png)
Si no tiene una instancia del servicio en Hadoop SQL, como se muestra arriba, puede crear una. Haga clic en el signo **\$1** situado junto a Hadoop SQL.
1. **Nombre del servicio (si se muestra)**: ingrese el nombre del servicio. El valor sugerido es **amazonemrhive**. Anote el nombre de este servicio: es necesario al crear una configuración de seguridad de EMR.
1. **Nombre público**: ingrese el nombre que se mostrará para el servicio. El valor sugerido es **amazonemrhive**.
![\[Detalles del servicio Apache Hive para Hadoop SQL.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger_create_service.png)
Las propiedades de Apache Hive Config se utilizan para establecer una conexión con su servidor Apache Ranger Admin con un HiveServer 2 para implementar el autocompletado al crear políticas. No es necesario que las siguientes propiedades sean precisas si no tiene un proceso persistente de HiveServer 2 y se pueden rellenar con cualquier información.
+ **Nombre de usuario**: introduzca un nombre de usuario para la conexión JDBC a una instancia de HiveServer 2 instancias.
+ **Contraseña**: ingrese la contraseña del nombre de usuario anterior.
+ **jdbc.driver. ClassName**: Introduzca el nombre de la clase JDBC para la conectividad con Apache Hive. Puede utilizar el valor predeterminado.
+ **jdbc.url**: Introduzca la cadena de conexión JDBC que se utilizará al conectarse a 2. HiveServer
+ **Nombre común del certificado:** el campo CN (Nombre común) del certificado que se utiliza para conectarse al servidor de administración desde un complemento cliente. Este valor debe coincidir con el campo CN del certificado TLS que se creó para el complemento.
![\[Propiedades de configuración del servicio Apache Hive.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger_config_props.png)
El botón **Probar conexión** comprueba si los valores anteriores se pueden utilizar para conectarse correctamente a la instancia 2. HiveServer Una vez que el servicio se haya creado correctamente, el administrador de servicios debería tener el siguiente aspecto:
![\[Conectado a la instancia HiveServer 2\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger_config_connected.png)
## Consideraciones
**Servidor de metadatos de Hive**
Solo motores fiables, específicamente Hive y `emr_record_server`, pueden acceder al servidor de metadatos de Hive para proteger al usuario del acceso no autorizado. Todos los nodos del clúster también acceden al servidor de metadatos de Hive. El puerto 9083 requerido proporciona a todos los nodos acceso al nodo principal.
**Autenticación**
De forma predeterminada, Apache Hive está configurado para autenticarse mediante Kerberos tal como se configuró en la configuración de seguridad de EMR. HiveServer2 también se puede configurar para autenticar a los usuarios mediante 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 obtener más información.
## Limitaciones
Las siguientes son las limitaciones actuales del complemento Apache Hive en Amazon EMR 5.x:
+ No se admiten roles de Hive de momento. No se admiten las instrucciones Grant ni Revoke.
+ No se admite Hive CLI. JDBC/Beeline es la única forma autorizada de conectar Hive.
+ `hive.server2.builtin.udf.blacklist`la configuración debe rellenarse con lo UDFs que considere inseguro.
# Complemento de Apache Spark para la integración de Ranger con Amazon EMR
Amazon EMR ha integrado el EMR RecordServer para proporcionar un control de acceso detallado para SparkSQL. El EMR es un proceso privilegiado que RecordServer se ejecuta en todos los nodos de un clúster habilitado para Apache Ranger. Cuando un controlador o ejecutor de Spark ejecuta una sentencia de SparkSQL, todas las solicitudes de metadatos y datos pasan por. RecordServer Para obtener más información sobre EMR RecordServer, consulte la [Componentes de Amazon EMR para su uso con Apache Ranger](emr-ranger-components.md) página.
**Topics**
+ [Características admitidas](#emr-ranger-spark-supported-features)
+ [Reimplementación de la definición de servicio para usar las instrucciones INSERT, ALTER o DDL](#emr-ranger-spark-redeploy-service-definition)
+ [Instalación de la definición de servicio](#emr-ranger-spark-install-servicedef)
+ [Creación de políticas de Spark SQL](#emr-ranger-spark-create-sparksql)
+ [Consideraciones](#emr-ranger-spark-considerations)
+ [Limitaciones](#emr-ranger-spark-limitations)
## Características admitidas
| Acción SQL statement/Ranger | STATUS | Versión de EMR compatible |
| --- | --- | --- |
| SELECT | compatible | A partir de la 5.32 |
| SHOW DATABASES | compatible | A partir de la 5.32 |
| SHOW COLUMNS | compatible | A partir de la 5.32 |
| SHOW TABLES | compatible | A partir de la 5.32 |
| MOSTRAR LAS PROPIEDADES DE LA TABLA | compatible | A partir de la 5.32 |
| DESCRIBE TABLE | compatible | A partir de la 5.32 |
| INSERT OVERWRITE | compatible | A partir de las 5.34 y 6.4 |
| INSERT INTO | compatible | A partir de las 5.34 y 6.4 |
| ALTER TABLE | compatible | A partir de la 6.4 |
| CREATE TABLE | compatible | A partir de las 5.35 y 6.7 |
| CREATE DATABASE | compatible | A partir de las 5.35 y 6.7 |
| DROP TABLE | compatible | A partir de las 5.35 y 6.7 |
| DROP DATABASE | compatible | A partir de las 5.35 y 6.7 |
| DROP VIEW | compatible | A partir de las 5.35 y 6.7 |
| CREATE VIEW | No es compatible | |
Se admiten las siguientes características al usar Spark SQL:
+ Control de acceso detallado a las tablas del metaalmacén de Hive, y las políticas se pueden crear para bases de datos, tablas y columnas.
+ Las políticas de Apache Ranger pueden incluir políticas de concesión y de denegación a usuarios y grupos.
+ Los eventos de auditoría se envían a CloudWatch los registros.
## Reimplementación de la definición de servicio para usar las instrucciones INSERT, ALTER o DDL
**nota**
A partir de Amazon EMR 6.4, puede usar Spark SQL con las instrucciones: INSERT INTO, INSERT OVERWRITE o ALTER TABLE. A partir de Amazon EMR 6.7, puede usar Spark SQL para crear o eliminar bases de datos y tablas. Si ya tiene una instalación en el servidor de Apache Ranger con las definiciones de servicio de Apache Spark implementadas, utilice el siguiente código para volver a implementar las definiciones de servicio.
```
# 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/'
```
## Instalación de la definición de servicio
La instalación de la definición de servicio Apache Spark de EMR requiere la configuración del servidor de Ranger Admin. Consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md).
Siga estos pasos para instalar la definición de servicio de Apache Spark:
**Paso 1: inicie sesión mediante SSH en el servidor de Apache Ranger Admin**
Por ejemplo:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Paso 2: descargue la definición de servicio y el complemento del servidor de Apache Ranger Admin**
En un directorio temporal, descargue la definición de servicio. Esta definición de servicio es compatible con las versiones 2.x de Ranger.
```
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
```
**Paso 3: instale el complemento 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
```
**Paso 4: registre la definición de servicio de 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'
```
Si este comando se ejecuta correctamente, verá un nuevo servicio en la IU de Ranger Admin denominado “AMAZON-EMR-SPARK”, como se muestra en la siguiente imagen (se muestra la versión 2.0 de Ranger).
![\[“AMAZON-EMR-SPARK” registrado en Ranger Admin.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark.png)
**Paso 5: Crear una instancia de la AMAZON-EMR-SPARK aplicación**
**Nombre del servicio (si se muestra):** el nombre del servicio que se utilizará. El valor sugerido es **amazonemrspark**. Anote el nombre de este servicio, ya que será necesario al crear una configuración de seguridad de EMR.
**Nombre público:** el nombre que se mostrará para esta instancia. El valor sugerido es **amazonemrspark**.
**Nombre común del certificado:** el campo CN (Nombre común) del certificado que se utiliza para conectarse al servidor de administración desde un complemento cliente. Este valor debe coincidir con el campo CN del certificado TLS que se creó para el complemento.
![\[Servicio de creación de Ranger Admin.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-service.png)
**nota**
El certificado TLS de este complemento debería haberse registrado en el almacén de confianza del servidor Ranger Admin. Consulte [Certificados TLS para la integración de Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md) para obtener más detalles.
## Creación de políticas de Spark SQL
Al crear una nueva política, los campos que hay que rellenar son:
**Nombre de la política**: el nombre de la política.
**Etiqueta de la política**: una etiqueta que puede poner en esta política.
**Base de datos**: la base de datos a la que se aplica esta política. El comodín “\$1” representa todas las bases de datos.
**Tabla**: las tablas a las que se aplica esta política. El comodín “\$1” representa todas las tablas.
**Columna de EMR Spark**: las columnas a las que se aplica esta política. El comodín “\$1” representa todas las columnas.
**Descripción**: una descripción de esta política.
![\[Ranger Admin crea los detalles de la política de Spark SQL.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-policy-details.png)
Para especificar los usuarios y grupos, ingrese los usuarios y grupos que aparecen a continuación para conceder los permisos. También puede especificar exclusiones para las condiciones de **autorización** y **denegación**.
![\[Los detalles de la política de Spark SQL de Ranger Admin permiten condiciones.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions.png)
Tras especificar las condiciones de autorización y denegación, haga clic en **Guardar**.
## Consideraciones
Cada nodo del clúster de EMR debe poder conectarse al nodo principal en el puerto 9083.
## Limitaciones
Las siguientes son las limitaciones actuales del complemento Apache Spark:
+ Servidor de registros siempre se conectará al HMS que se ejecute en un clúster de Amazon EMR. Configure el HMS para que se conecte al modo remoto, si es necesario. No debe incluir valores de configuración en el archivo de configuración Hive-site.xml de Apache Spark.
+ Las tablas creadas con fuentes de datos de Spark en CSV o Avro no se pueden leer con EMR. RecordServer Use Hive para crear y escribir datos, y lea con Record.
+ Las tablas de Delta Lake, Hudi e Iceberg no son compatibles.
+ Los usuarios tienen que tener acceso a la base de datos predeterminada. Este es un requisito para el uso de Apache Spark.
+ El servidor de Ranger Admin no admite la característica de autocompletar.
+ El complemento SparkSQL para Amazon EMR no admite filtros de filas ni enmascaramiento de datos.
+ Al utilizar ALTER TABLE con Spark SQL, la ubicación de una partición debe ser el directorio secundario de la ubicación de una tabla. No se admite la inserción de datos en una partición cuya ubicación sea diferente de la ubicación de la tabla.
# Complemento EMRFS S3 para la integración de Ranger con Amazon EMR
Para facilitar los controles de acceso a los objetos de S3 en un clúster multiusuario, el complemento EMRFS S3 proporciona controles de acceso a los datos de S3 cuando se accede a ellos a través de EMRFS. Puede permitir el acceso a los recursos de usuarios y grupos de S3.
Para ello, cuando su aplicación intente acceder a los datos de S3, EMRFS envía una solicitud de credenciales al proceso del agente secreto, donde la solicitud se autentica y autoriza mediante un complemento de Apache Ranger. Si la solicitud se autoriza, el agente secreto asume el rol de IAM para los motores Apache Ranger con una política restringida para generar credenciales que solo tienen acceso a la política de Ranger que permitió el acceso. A continuación, las credenciales se devuelven a EMRFS para acceder a S3.
**Topics**
+ [Características admitidas](#emr-ranger-emrfs-features)
+ [Instalación de la configuración del servicio](#emr-ranger-emrfs-service-config)
+ [Creación de políticas de EMRFS S3](#emr-ranger-emrfs-create-policies)
+ [Notas de uso de las políticas de EMRFS S3](#emr-ranger-emrfs-considerations)
+ [Limitaciones](#emr-ranger-emrfs-limitations)
## Características admitidas
El complemento EMRFS S3 proporciona autorización de almacenamiento. Se pueden crear políticas para proporcionar acceso a los usuarios y grupos a los buckets y prefijos de S3. La autorización se realiza únicamente para EMRFS.
## Instalación de la configuración del servicio
Para instalar la definición del servicio EMRFS, debe configurar el servidor Ranger Admin. Para configurar el servidor, consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md).
Siga estos pasos para instalar la definición de servicio de EMRFS.
**Paso 1: inicie sesión mediante SSH en el servidor de Apache Ranger Admin**.
Por ejemplo:
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
**Paso 2: descargue la definición del servicio de EMRFS**.
En un directorio temporal, descargue la definición de servicio de Amazon EMR. Esta definición de servicio es compatible con las versiones 2.x de Ranger.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-emrfs.json
```
**Paso 3: registre la definición de servicio de EMRFS S3**.
```
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'
```
Si este comando se ejecuta correctamente, verá un nuevo servicio en la IU de Ranger Admin denominado “AMAZON-EMR-S3”, como se muestra en la siguiente imagen (se muestra la versión 2.0 de Ranger).
![\[Ranger Admin crea el servicio EMRFS S3.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-service-EMRFS.png)
**Paso 4: Crea una instancia** de la aplicación. AMAZON-EMR-EMRFS
Cree una instancia de la definición de servicio.
+ Haga clic en el **signo \$1** situado junto a AMAZON-EMR-EMRFS.
Rellene los siguientes campos:
**Nombre del servicio (si se muestra)**: el valor sugerido es **amazonemrs3**. Anote el nombre de este servicio, ya que será necesario al crear una configuración de seguridad de EMR.
**Nombre público**: el nombre que se muestra para este servicio. El valor sugerido es **amazonemrs3**.
**Nombre común del certificado:** el campo CN (Nombre común) del certificado que se utiliza para conectarse al servidor de administración desde un complemento cliente. Este valor debe coincidir con el campo CN del certificado TLS que se creó para el complemento.
![\[Ranger Admin edita el servicio EMRFS S3.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-edit-service-EMRFS.png)
**nota**
El certificado TLS de este complemento debería haberse registrado en el almacén de confianza del servidor Ranger Admin. Consulte [Certificados TLS para la integración de Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md) para obtener más detalles.
Cuando se crea el servicio, el administrador de servicios incluye “AMAZON-EMR-EMRFS”, como se muestra en la siguiente imagen.
![\[Ranger Admin muestra el nuevo servicio EMRFS S3.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-new-service-EMRFS.png)
## Creación de políticas de EMRFS S3
Para crear una nueva política en la página **Crear política** del administrador de servicios, rellene los siguientes campos.
**Nombre de la política**: el nombre de la política.
**Etiqueta de la política**: una etiqueta que puede poner en esta política.
**Recurso de S3**: un recurso que comienza con el bucket y el prefijo opcional. Consulte [Notas de uso de las políticas de EMRFS S3](#emr-ranger-emrfs-considerations) para obtener más información sobre las prácticas recomendadas. Los recursos del servidor Ranger Admin no deben contener **s3://**, **s3a://** ni **s3n://**.
![\[Ranger Admin muestra Crear política para el servicio EMRFS S3.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-policy-EMRFS.png)
Puede especificar los usuarios y grupos a los que conceder permisos. También puede especificar exclusiones para las condiciones de **autorización** y **denegación**.
![\[El administrador de Ranger muestra user/group los permisos para la política de EMRFS S3.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-permissions-EMRFS.png)
**nota**
Se permite un máximo de tres recursos para cada política. Agregar más de tres recursos puede provocar un error cuando se usa esta política en un clúster de EMR. Al agregar más de tres políticas, se muestra un recordatorio sobre el límite de la política.
## Notas de uso de las políticas de EMRFS S3
Al crear políticas de S3 en Apache Ranger, hay que tener en cuenta algunas consideraciones de uso.
### Permisos para varios objetos de S3
Puede utilizar políticas recursivas y expresiones comodín para conceder permisos a varios objetos de S3 con prefijos comunes. Las políticas recursivas otorgan permisos a todos los objetos con un prefijo común. Las expresiones comodín seleccionan varios prefijos. En conjunto, otorgan permisos a todos los objetos con varios prefijos comunes, como se muestra en los ejemplos siguientes.
**Example Uso de una política recursiva**
Supongamos que desea obtener permisos para enumerar todos los archivos Parquet de un bucket de S3 organizados de la siguiente manera.
```
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
```
En primer lugar, considere los archivos Parquet con el prefijo `s3://sales-reports/americas/year=2000`. Puede conceder GetObject permisos a todos ellos de dos maneras:
**Uso de políticas no recursivas**: una opción es utilizar dos políticas no recursivas independientes, una para el directorio y otra para los archivos.
La primera política concede permiso al prefijo `s3://sales-reports/americas/year=2020` (no hay ningún `/` final).
```
- S3 resource = "sales-reports/americas/year=2000"
- permission = "GetObject"
- user = "analyst"
```
La segunda política utiliza una expresión comodín para conceder permisos a todos los archivos con prefijo `sales-reports/americas/year=2020/` (tenga en cuenta el `/` final).
```
- S3 resource = "sales-reports/americas/year=2020/*"
- permission = "GetObject"
- user = "analyst"
```
**Uso de una política recursiva**: una alternativa más práctica consiste en utilizar una única política recursiva y conceder permisos recursivos al prefijo.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
Hasta ahora, solo se han incluido los archivos Parquet con el prefijo `s3://sales-reports/americas/year=2000`. Ahora también puede incluir los archivos Parquet con un prefijo diferente, `s3://sales-reports/americas/year=2020`, en la misma política recursiva introduciendo una expresión comodín como la siguiente.
```
- S3 resource = "sales-reports/americas/year=20?0"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Políticas PutObject y DeleteObject permisos
La redacción de políticas `PutObject` y `DeleteObject` permisos para los archivos en EMRFS requiere un cuidado especial porque, a diferencia de GetObject los permisos, requieren la concesión de permisos recursivos adicionales al prefijo.
**Example Políticas y permisos PutObject DeleteObject**
Por ejemplo, para eliminar el archivo no solo se `annual-summary.parquet` requiere un DeleteObject permiso para acceder al archivo real.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "DeleteObject"
- user = "analyst"
```
También requiere una política que conceda permisos `PutObject` y `GetObject` recursivos a su prefijo.
Del mismo modo, modificar el archivo `annual-summary.parquet` no solo requiere un permiso `PutObject` para ese archivo concreto.
```
- S3 resource = "sales-reports/americas/year=2020/annual-summary.parquet"
- permission = "PutObject"
- user = "analyst"
```
También requiere una política que conceda permisos `GetObject` recursivos a su prefijo.
```
- S3 resource = "sales-reports/americas/year=2020"
- permission = "GetObject"
- user = "analyst"
- is recursive = "True"
```
### Comodines en las políticas
Hay dos áreas en las que se pueden especificar los caracteres comodín. Al especificar un recurso de S3, los caracteres “\$1” y “?” se puede utilizar. El asterisco “\$1” sustituye una ruta de S3 y coincide con todo lo que aparece después del prefijo. Tome la siguiente política como ejemplo:
```
S3 resource = "sales-reports/americas/*"
```
Esto coincide con las siguientes rutas de S3.
```
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
```
El comodín “?” coincide con cualquier carácter individual. Tome la siguiente política como ejemplo:
```
S3 resource = "sales-reports/americas/year=201?/"
```
Esto coincide con las siguientes rutas de S3.
```
sales-reports/americas/year=2019/
sales-reports/americas/year=2018/
sales-reports/americas/year=2017/
```
### Comodines en los usuarios
Hay dos caracteres comodín integrados al asignar usuarios para proporcionar acceso a los usuarios. El primero es el comodín “\$1USER\$1”, que proporciona acceso a todos los usuarios. El segundo comodín es “\$1OWNER\$1”, que proporciona acceso al propietario de un objeto concreto o directamente. Sin embargo, actualmente no se admite el comodín “\$1USER\$1”.
## Limitaciones
Las siguientes son las limitaciones actuales del complemento EMRFS S3:
+ Las políticas de Apache Ranger pueden tener como máximo tres políticas.
+ El acceso a S3 debe realizarse a través de EMRFS y se puede utilizar con aplicaciones relacionadas con Hadoop. No se admite lo siguiente:
― Bibliotecas Boto3
- AWS SDK y CLI de AWK
― Conector de código abierto S3A
+ No se admiten las políticas de denegación de Apache Ranger.
+ Actualmente, no se admiten las operaciones en S3 con claves con cifrado CSE-KMS.
+ No se admite la compatibilidad entre regiones.
+ La característica Zona de seguridad de Apache Ranger no es compatible. Las restricciones de control de acceso definidas mediante la característica Zona de seguridad no se aplican a los clústeres de Amazon EMR.
+ El usuario de Hadoop no genera ningún evento de auditoría, ya que Hadoop siempre accede al perfil de instancia de EC2.
+ Se recomienda deshabilitar la visión de consistencia de Amazon EMR. S3 de tiene un alto grado de consistencia, por lo que ya no es necesario. Consulte [Amazon S3 strong consistency](https://aws.amazon.com/s3/consistency/) para obtener más información.
+ El complemento EMRFS S3 realiza numerosas llamadas STS. Se recomienda realizar pruebas de carga en una cuenta de desarrollo y supervisar el volumen de llamadas STS. También se recomienda realizar una solicitud de STS para aumentar los límites del AssumeRole servicio.
+ El servidor Ranger Admin no admite la característica de autocompletar.
# Complemento Trino para la integración de Ranger con Amazon EMR
Trino (anteriormente PrestoSQL) es un motor de consultas SQL que puede utilizar para ejecutar consultas en orígenes de datos como HDFS, almacenamiento de objetos, bases de datos relacionales y bases de datos NoSQL. Elimina la necesidad de migrar los datos a una ubicación central y permite consultar estos datos desde cualquier lugar donde estén. Amazon EMR proporciona un complemento de Apache Ranger para proporcionar controles de acceso detallados para Trino. El complemento es compatible con la versión 2.0 y posteriores del servidor de Apache Ranger Admin de código abierto.
**Topics**
+ [Características admitidas](#emr-ranger-trino-features)
+ [Instalación de la configuración del servicio](#emr-ranger-trino-service-config)
+ [Creación de políticas de Trino](#emr-ranger-trino-create-policies)
+ [Consideraciones](#emr-ranger-trino-considerations)
+ [Limitaciones](#emr-ranger-trino-limitations)
## Características admitidas
El complemento Apache Ranger para Trino en Amazon EMR admite todas las funciones del motor de consultas de Trino, que están protegidas por un control de acceso detallado. Esto incluye controles de acceso a bases de datos, tablas y columnas, así como el filtrado de filas y el enmascaramiento de datos. Las políticas de Apache Ranger pueden incluir políticas de concesión y de denegación a usuarios y grupos. Los eventos de auditoría también se envían a CloudWatch los registros.
## Instalación de la configuración del servicio
La instalación de la definición de servicio de Trino requiere la configuración del servidor de Ranger Admin. Para configurar el servidor de Ranger Admin, consulte [Configure un servidor Ranger Admin para integrarlo con Amazon EMR](emr-ranger-admin.md).
Siga estos pasos para instalar la definición de servicio de Trino.
1. Inicie sesión mediante SSH en el servidor de Apache Ranger Admin.
```
ssh ec2-user@ip-xxx-xxx-xxx-xxx.ec2.internal
```
1. Desinstale el complemento del servidor Presto, si existe. Ejecute el comando siguiente. Si se produce un error “Servicio no encontrado”, significa que el complemento del servidor Presto no estaba instalado en su servidor. Continúe con el siguiente paso.
```
curl -f -u **:*_<_**_password_ **_for_** _ranger admin user_**_>_* -X DELETE -k 'https://**:6182/service/public/v2/api/servicedef/name/presto'
```
1. Descargue la definición de servicio y el complemento del servidor de Apache Ranger Admin. En un directorio temporal, descargue la definición de servicio. Esta definición de servicio es compatible con las versiones 2.x de Ranger.
```
wget https://s3.amazonaws.com/elasticmapreduce/ranger/service-definitions/version-2.0/ranger-servicedef-amazon-emr-trino.json
```
1. Registre la definición de servicio de Apache Trino para 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'
```
Si este comando se ejecuta correctamente, verá un nuevo servicio en la IU de Ranger Admin denominado `TRINO`, como se muestra en la siguiente imagen.
![\[Servicio de creación de Ranger Admin.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-service-trino.png)
1. Cree una instancia de la aplicación `TRINO` e ingrese la siguiente información.
**Nombre del servicio**: el nombre del servicio que utilizará. El valor sugerido es `amazonemrtrino`. Anote el nombre de este servicio, ya que será necesario al crear una configuración de seguridad de Amazon EMR.
**Nombre público:** el nombre que se mostrará para esta instancia. El valor sugerido es `amazonemrtrino`.
![\[Nombre público de Ranger Admin.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-display-name-trino.png)
**jdbc.driver. ClassName**: El nombre de clase de la clase JDBC para la conectividad Trino. Puede utilizar el valor predeterminado.
**jdbc.url:** la cadena de conexión JDBC que se utilizará al conectarse al coordinador de Trino.
**Nombre común del certificado:** el campo CN (Nombre común) del certificado que se utiliza para conectarse al servidor de administración desde un complemento cliente. Este valor debe coincidir con el campo CN del certificado TLS que se creó para el complemento.
![\[Nombre común de Ranger Admin.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-common-name-trino.png)
Tenga en cuenta que el certificado TLS de este complemento debería haberse registrado en el almacén de confianza del servidor de Ranger Admin. Para obtener más información, consulte [Certificados TLS](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-admin-tls.html).
## Creación de políticas de Trino
Cuando cree una nueva política, rellena los siguientes campos.
**Nombre de la política**: el nombre de la política.
**Etiqueta de la política**: una etiqueta que puede poner en esta política.
**Catálogo**: el catálogo al que se aplica esta política. El comodín “\$1” representa todos los catálogos.
**Esquema**: los esquemas a los que se aplica esta política. El comodín “\$1” representa todos los esquemas.
**Tabla**: las tablas a las que se aplica esta política. El comodín “\$1” representa todas las tablas.
**Columna**: las columnas a las que se aplica esta política. El comodín “\$1” representa todas las columnas.
**Descripción**: una descripción de esta política.
Existen otros tipos de políticas para **Usuario de Trino** (para el acceso suplantando al usuario), **Propiedad del sistema o sesión de Trino** (para modificar las propiedades del sistema o la sesión del motor), **Funciones/Procedimientos** (para permitir las llamadas a funciones o procedimientos) y **URL** (para conceder acceso de lectura/escritura al motor en las ubicaciones de los datos).
![\[Ranger Admin crea los detalles de la política.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-policy-details-trino.png)
Para conceder permisos a usuarios y grupos específicos, ingrese los usuarios y grupos. También puede especificar exclusiones para las condiciones de **autorización** y **denegación**.
![\[Los detalles de la política de Ranger Admin permiten condiciones de denegación.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-create-policy-allow-conditions-trino.png)
Tras especificar las condiciones de autorización y denegación, elija **Guardar**.
## Consideraciones
Al crear políticas de Trino en Apache Ranger, hay que tener en cuenta algunas consideraciones de uso.
**Servidor de metadatos de Hive**
Solo motores fiables, específicamente el motor Trino, pueden acceder al servidor de metadatos de Hive para proteger al usuario del acceso no autorizado. Todos los nodos del clúster también acceden al servidor de metadatos de Hive. El puerto 9083 requerido proporciona a todos los nodos acceso al nodo principal.
**Autenticación**
De forma predeterminada, Trino está configurado para autenticarse mediante Kerberos, tal y como se indicó en la configuración de seguridad de Amazon EMR.
**Cifrado en tránsito obligatorio**
El complemento Trino requiere que tenga activado el cifrado en tránsito en la configuración de seguridad de Amazon EMR. Para habilitar el cifrado, consulte [Cifrado en tránsito](emr-data-encryption-options.md#emr-encryption-intransit).
## Limitaciones
Las siguientes son las limitaciones actuales del complemento Trino:
+ El servidor de Ranger Admin no admite la característica de autocompletar.
# Solución de problemas con Apache Ranger
Estos son algunos de los problemas que se diagnostican con frecuencia relacionados con el uso de Apache Ranger.
## Recomendaciones
+ **Haga pruebas con un único clúster de nodo principal:** los clústeres maestros de un solo nodo se aprovisionan más rápido que un clúster de varios nodos, lo que puede reducir el tiempo de cada iteración de prueba.
+ **Configure el modo de desarrollo del clúster.** Al iniciar el clúster de EMR, establezca el parámetro `--additional-info"` en:
`'{"clusterType":"development"}'`
Este parámetro solo se puede configurar mediante la AWS CLI o el AWS SDK y no está disponible a través de la consola Amazon EMR. Cuando se activa este indicador y el clúster maestro no lo aprovisiona, el servicio Amazon EMR mantiene activo el clúster durante algún tiempo antes de retirarlo del servicio. Este tiempo es muy útil para sondear varios archivos de registro antes de que finalice el clúster.
# El clúster de EMR no se pudo aprovisionar
Existen varios motivos por los que un clúster de Amazon EMR puede no iniciarse. Las siguientes son algunas formas de diagnosticar el problema.
**Compruebe los registros de aprovisionamiento de EMR**
Amazon EMR usa Puppet para instalar y configurar aplicaciones en un clúster. Si consulta los registros, obtendrá detalles sobre si se ha producido algún error durante la fase de aprovisionamiento de un clúster. Se puede acceder a los registros en el clúster o en S3 si los registros están configurados para enviarse a S3.
Los registros se almacenan en `/var/log/provision-node/apps-phase/0/{UUID}/puppet.log` en el disco y `s3:////node//provision-node/apps-phase/0/{UUID}/puppet.log.gz.`
**Mensajes de error comunes**
| Mensaje de error | Causa |
| --- | --- |
| Marioneta (error): ¡Error al iniciar el sistema\$1 emr-record-server log de journalctl para: emr-record-server | No se pudo iniciar Servidor de registros de EMR. Consulte los registros de Servidor de registros de EMR a continuación. |
| Marioneta (error): ¡Error al iniciar el sistema\$1 emr-record-server Registro journalctl para emrsecretagent: | Agente secreto de EMR no se pudo iniciar. Consulte Revisión de los registros de Agente secreto a continuación. |
| /Stage [main] /Ranger\$1Plugins: :Ranger\$1hive\$1 (aviso): 140408606197664:error:0906D06C:PEM Rutines:PEM\$1READ\$1BIO:Sin línea de inicio:PEM\$1LIB.C:707:En esperaplugin/Ranger\$1plugins::Prepare\$1two\$1way\$1tls[configure 2-way TLS in Hive plugin]/Exec[create keystore and truststore for Ranger Hive plugin]/returns: cualquier clave privada | El certificado TLS privado de Secrets Manager para el certificado del complemento Apache Ranger no tiene el formato correcto o no es un certificado privado. Consulte [Certificados TLS para la integración de Apache Ranger con Amazon EMR](emr-ranger-admin-tls.md) para obtener más información sobre los formatos de los certificados. |
| /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 -XXXXXXXXXX no está autorizado a actuar: secretsmanager: GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:xxxxxxxxxx:secret: -XXXXX AdminServer | El rol del perfil de instancia de EC2 no tiene los permisos correctos para recuperar los certificados TLS del agente secreto. |
** SecretAgent Compruebe los registros**
Los registros de Agente secreto se encuentran en `/emr/secretagent/log/` en un nodo de EMR o en el directorio `s3:////node//daemons/secretagent/` de S3.
**Mensajes de error comunes**
| Mensaje de error | Causa |
| --- | --- |
| Excepción en el hilo «principal» com.amazonaws.services.securitytoken.model. AWSSecurityTokenServiceException: Usuario: arn:aws:sts: :xxxxxxxxxxxx:Assumed- role/EMR\$1EC2\$1DefaultRole/i -XXXXXXXXXXXXXXX no está autorizado a realizar: sts: AssumeRole on resource: arn:aws:iam: RangerPluginDataAccessRole :xxxxxxxxxxxx:role/\$1 (Servicio:; Código de estado: 403; Código de error:; ID de solicitud: XXXXXXXX-XXXXXX-XXXXXXXXXXXXXX AWSSecurityTokenService; Proxy: null) AccessDenied | La excepción anterior significa que el rol del perfil de instancia EC2 de EMR no tiene permisos para asumir el rol. **RangerPluginDataAccessRole** Consulte [Roles de IAM para la integración nativa con Apache Ranger](emr-ranger-iam.md). |
| ERROR qtp54617902-149: Web App Exception Occurred javax.ws.rs. NotAllowedException: El método HTTP 405 no está permitido | Estos errores se pueden ignorar. |
**Compruebe los registros de Servidor de registros (para Spark SQL)**
Los registros del servidor de registros EMR están disponibles en/var/log/emr-record-server/ en un nodo EMR, o se encuentran en el directorio s3:////node/ /daemons//de S3. emr-record-server
**Mensajes de error comunes**
| Mensaje de error | Causa |
| --- | --- |
| InstanceMetadataServiceResourceFetcherLos registros del servidor de registros EMR están disponibles en/-record-server/ en un nodo EMR, o se encuentran en el directorio s3:///node/ /daemons//de S3. ----sep----:105 - [] No se pudo recuperar el token com.amazonaws. SdkClientException: No se pudo conectar al punto final del servicio | El EMR SecretAgent no apareció o está teniendo un problema. Inspeccione los SecretAgent registros para ver si hay errores y el script de la marioneta para determinar si hubo algún error de aprovisionamiento. |
# Las consultas fallan inesperadamente para la integración de Ranger con Amazon EMR
**Compruebe los registros del complemento Apache Ranger (registros de Apache Hive, EMRRecordServer, SecretAgent EMR, etc.)**
Esta sección es común a todas las aplicaciones que se integran con el complemento Ranger, como Apache Hive, EMR Record Server y EMR. SecretAgent
**Mensajes de error comunes**
| Mensaje de error | Causa |
| --- | --- |
| ERROR:272 PolicyRefresher - [] (PolicyRefresherserviceName=policy-repository): no se pudo encontrar el servicio. Will clean up local cache of policies (-1) | Este mensaje de error significa que el nombre del servicio que proporcionó en la configuración de seguridad de EMR no coincide con un repositorio de políticas de servicio del servidor de Ranger Admin. |
Si en el servidor Ranger Admin su AMAZON-EMR-SPARK servicio tiene el siguiente aspecto, debe ingresarlo como nombre del servicio. **amazonemrspark**
![\[El servidor Ranger Admin muestra AMAZON-EMR-SPARK la solución de problemas.\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/images/ranger-amazon-emr-spark-troubleshooting.png)
# Control del tráfico de red con grupos de seguridad para su clúster de Amazon EMR
Los grupos de seguridad funcionan como firewalls virtuales para que las instancias de EC2 del clúster controlen el tráfico entrante y saliente. Cada grupo de seguridad tiene un conjunto de reglas que controlan el tráfico entrante y un conjunto de reglas distinto que controlan el tráfico saliente. Para obtener más información, consulte [Grupos de seguridad de Amazon EC2 para instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) en la *Guía del usuario de Amazon EC2*.
Puede utilizar dos clases de grupos de seguridad con Amazon EMR: *grupos de seguridad administrados por Amazon EMR* y *grupos de seguridad adicionales*.
Cada clúster tiene asociados grupos de seguridad administrados. Puede utilizar los grupos de seguridad administrados predeterminados que Amazon EMR crea o especificar grupos de seguridad administrados personalizados. De cualquier forma, Amazon EMR añade automáticamente las reglas a los grupos de seguridad gestionados que un clúster necesita para comunicarse entre las instancias y AWS los servicios del clúster.
Los grupos de seguridad adicionales son opcionales. Puede especificarlos junto con los grupos de seguridad administrados para adaptar el acceso a las instancias de clúster. Los grupos de seguridad adicionales contienen solo las reglas que defina. Amazon EMR no los modifica.
Las reglas que Amazon EMR crea en los grupos de seguridad administrados permiten la comunicación entre los componentes internos del clúster. Para permitir que los usuarios y las aplicaciones obtengan acceso a un clúster desde fuera de este, puede editar las reglas de los grupos de seguridad administrados, crear grupos de seguridad adicionales con reglas adicionales o ambas cosas.
**importante**
Además, la edición de reglas de los grupos de seguridad administrados puede tener consecuencias no deseadas. Es posible bloquear accidentalmente el tráfico necesario para que los clústeres funcionen correctamente y generar errores debido a que los nodos estén inaccesibles. Planifique y pruebe cuidadosamente las configuraciones de los grupos de seguridad antes de su implementación.
Solo puede especificar grupos de seguridad al crear un clúster. No se pueden añadir a un clúster ni a las instancias de clúster mientras se está ejecutando un clúster, pero es posible editar, añadir y eliminar reglas de los grupos de seguridad existentes. Las reglas surtirán efecto tan pronto como se guarden.
Los grupos de seguridad son restrictivos de forma predeterminada. A menos que se añada una regla que permita el tráfico, el tráfico se rechaza. Si existe más de una regla que se aplica al mismo tráfico y al mismo origen, se aplica la regla más permisiva. Por ejemplo, si tiene una regla que permite el tráfico SSH desde la dirección IP 192.0.2.12/32 y otra regla que permite el acceso a todo el tráfico TCP desde el rango 192.0.2.0/24, tiene prioridad la regla que permite todo el tráfico TCP desde el rango que incluye 192.0.2.12. En este caso, el cliente en la dirección 192.0.2.12 podría tener más acceso del deseado.
**importante**
Actúe con precaución al editar las reglas de grupos de seguridad para abrir puertos. Asegúrese de agregar reglas que solo permitan el tráfico desde los clientes de confianza y autenticados para los protocolos y puertos necesarios para ejecutar las cargas de trabajo.
Puede configurar *Bloquear acceso público* de Amazon EMR en cada región que utilice para evitar la creación de clústeres si una regla permite el acceso público en algún puerto que no haya agregado a una lista de excepciones. En el AWS caso de las cuentas creadas después de julio de 2019, Amazon EMR bloquea el acceso público y está activado de forma predeterminada. En el AWS caso de las cuentas que crearon un clúster antes de julio de 2019, el bloqueo de acceso público de Amazon EMR está desactivado de forma predeterminada. Para obtener más información, consulte [Uso de Bloquear el acceso público de Amazon EMR](emr-block-public-access.md).
**Topics**
+ [Uso de grupos de seguridad administrados por Amazon EMR](emr-man-sec-groups.md)
+ [Trabajo con grupos de seguridad adicionales para un clúster de Amazon EMR](emr-additional-sec-groups.md)
+ [Especificación de los grupos de seguridad adicionales administrados por Amazon EMR](emr-sg-specify.md)
+ [Especificación de grupos de seguridad de EC2 para Cuadernos de Amazon EMR](emr-managed-notebooks-security-groups.md)
+ [Uso de Bloquear el acceso público de Amazon EMR](emr-block-public-access.md)
**nota**
Amazon EMR tiene como objetivo utilizar alternativas inclusivas para términos industriales potencialmente ofensivos o no inclusivos, como “maestro” y “esclavo”. Hemos adoptado una nueva terminología para fomentar una experiencia más inclusiva y que así pueda entender mejor los componentes del servicio.
Ahora describimos los “nodos” como **instancias** y describimos los tipos de instancias de Amazon EMR como instancias **principales**, **básicas** y **de tareas**. Durante la transición, es posible que siga encontrando referencias antiguas a términos obsoletos, como los que se refieren a los grupos de seguridad de Amazon EMR.
# Uso de grupos de seguridad administrados por Amazon EMR
**nota**
Amazon EMR tiene como objetivo utilizar alternativas inclusivas para términos industriales potencialmente ofensivos o no inclusivos, como “maestro” y “esclavo”. Hemos adoptado una nueva terminología para fomentar una experiencia más inclusiva y que así pueda entender mejor los componentes del servicio.
Ahora describimos los “nodos” como **instancias** y describimos los tipos de instancias de Amazon EMR como instancias **principales**, **básicas** y **de tareas**. Durante la transición, es posible que siga encontrando referencias antiguas a términos obsoletos, como los que se refieren a los grupos de seguridad de Amazon EMR.
Son varios los grupos de seguridad administrados que están asociados a la instancia principal y con las instancias secundarias y de tareas de un clúster. Se requiere un grupo de seguridad administrado adicional para el acceso al servicio al crear un clúster en una subred privada. Para obtener más información sobre la función de los grupos de seguridad administrados con respecto a la configuración de la red, consulte [Opciones de Amazon VPC al lanzar un clúster](emr-clusters-in-a-vpc.md).
Cuando especifique grupos de seguridad administrados para un clúster, debe utilizar el mismo tipo de grupo de seguridad, predeterminado o personalizado, para todos los grupos. Por ejemplo, no puede especificar un grupo de seguridad personalizado para la instancia principal y, acto seguido, no especificar un grupo de seguridad personalizado para las instancias secundarias y de tareas.
Si piensa utilizar los grupos de seguridad administrados predeterminados, no es necesario que los especifique al crear un clúster. Amazon EMR utiliza automáticamente los valores predeterminados. Además, si los valores predeterminados aún no existen en la VPC del clúster, Amazon EMR los crea. Amazon EMR también los crea si los especifica de forma explícita y aún no existen.
Puede editar reglas en los grupos de seguridad administrados una vez que se hayan creado los clústeres. Cuando se crea un clúster nuevo, Amazon EMR comprueba las reglas de los grupos de seguridad administrados que se especifican y, a continuación, crea las reglas *entrantes* que faltan y que el clúster nuevo necesita, junto con las reglas que se hayan podido agregar anteriormente. A menos que se indique lo contrario, cada regla para los grupos de seguridad administrados por Amazon EMR predeterminados también se agrega a los grupos de seguridad administrados por Amazon EMR personalizados que especifique.
Los grupos de seguridad administrados predeterminados son los siguientes:
+ **ElasticMapReduce-principal**
Para ver las reglas de este grupo de seguridad, consulte [Grupo de seguridad administrado por Amazon EMR para la instancia principal (subredes públicas)](#emr-sg-elasticmapreduce-master).
+ **ElasticMapReduce-núcleo**
Para ver las reglas de este grupo de seguridad, consulte [Grupo de seguridad administrado por Amazon EMR para las instancias básicas y de tareas (subredes públicas)](#emr-sg-elasticmapreduce-slave).
+ **ElasticMapReduce-Primario-Privado**
Para ver las reglas de este grupo de seguridad, consulte [Grupo de seguridad administrado por Amazon EMR para la instancia principal (subredes privadas)](#emr-sg-elasticmapreduce-master-private).
+ **ElasticMapReduce-Núcleo: privado**
Para ver las reglas de este grupo de seguridad, consulte [Grupo de seguridad administrado por Amazon EMR para las instancias secundarias y de tareas (subredes privadas)](#emr-sg-elasticmapreduce-slave-private).
+ **ElasticMapReduce-ServiceAccess**
Para ver las reglas de este grupo de seguridad, consulte [Grupo de seguridad administrado por Amazon EMR para el acceso de los servicios (subredes privadas)](#emr-sg-elasticmapreduce-sa-private).
## Grupo de seguridad administrado por Amazon EMR para la instancia principal (subredes públicas)
**El grupo de seguridad administrado predeterminado para la instancia principal en las subredes públicas tiene el **nombre de ElasticMapReduce grupo -primary**.** Tiene las siguientes reglas: Si especifica un grupo de seguridad administrado personalizado, Amazon EMR agrega las mismas reglas a su grupo de seguridad personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-man-sec-groups.html)
**Para conceder a los orígenes de confianza acceso SSH al grupo de seguridad principal con la consola**
Para editar los grupos de seguridad, debe tener permiso para administrar los grupos de seguridad de la VPC en la que se encuentra el clúster. Para obtener más información, consulte [Cambio de los permisos de un usuario](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html) y el [Ejemplo de política](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) que permite administrar los grupos de seguridad de EC2 en la *Guía del usuario de IAM*.
1. [Inicie sesión en y abra la Consola de administración de AWS consola de Amazon EMR en https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. Seleccione **Clusters (Clústeres)**. Seleccione el **ID** del clúster que desea modificar.
1. En el panel **Red y seguridad**, amplíe el menú desplegable de **grupos de seguridad (firewall) de EC2**.
1. En **Nodo principal**, elija su grupo de seguridad.
1. Elija **Editar reglas de entrada**.
1. Compruebe si hay una regla de entrada que permita el acceso público con la siguiente configuración. Si existe, seleccione **Eliminar** para eliminarla.
+ **Tipo**
SSH
+ **Puerto**
22
+ **Origen**
0.0.0.0/0 personalizado
**aviso**
Antes de diciembre de 2020, había una regla preconfigurada para permitir el tráfico entrante en el puerto 22 desde todas las fuentes. Esta regla se creó para simplificar las conexiones SSH iniciales al nodo principal. Le recomendamos encarecidamente que elimine esta regla de entrada y que restrinja el tráfico a los orígenes de confianza.
1. Desplácese a la parte inferior de la lista de reglas y seleccione **Agregar regla**.
1. En **Type (Tipo)**, seleccione **SSH**.
Al seleccionar SSH, se ingresa automáticamente **TCP** en **Protocolo** y **22** en **Rango de puertos**.
1. Como origen, seleccione **Mi IP** para agregar automáticamente su dirección IP como dirección de origen. También puede agregar un rango de direcciones IP de clientes de confianza **personalizadas** o crear reglas adicionales para otros clientes. Muchos entornos de red asignan direcciones IP de forma dinámica, por lo que es posible que en el futuro necesite actualizar las direcciones IP de los clientes de confianza.
1. Seleccione **Save**.
1. Si lo desea, puede seleccionar el otro grupo de seguridad en **Nodos principales y de tareas** en el panel **Red y seguridad** y repetir los pasos anteriores para permitir que el cliente SSH acceda a dichos nodos principales y de tareas.
## Grupo de seguridad administrado por Amazon EMR para las instancias básicas y de tareas (subredes públicas)
**El grupo de seguridad administrado predeterminado para las instancias principales y de tareas en las subredes públicas tiene el **nombre de ElasticMapReduce grupo -core**.** El grupo de seguridad administrado predeterminado tiene las siguientes reglas, y Amazon EMR agrega las mismas reglas si especifica un grupo de seguridad administrado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Grupo de seguridad administrado por Amazon EMR para la instancia principal (subredes privadas)
**El grupo de seguridad administrado predeterminado para la instancia principal en las subredes privadas tiene el nombre de **grupo** -Primary-Private. ElasticMapReduce** El grupo de seguridad administrado predeterminado tiene las siguientes reglas, y Amazon EMR agrega las mismas reglas si especifica un grupo de seguridad administrado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-man-sec-groups.html)
## Grupo de seguridad administrado por Amazon EMR para las instancias secundarias y de tareas (subredes privadas)
**El grupo de seguridad administrado predeterminado para las instancias principales y de tareas en las subredes privadas tiene el nombre de **grupo** -Core-Private. ElasticMapReduce** El grupo de seguridad administrado predeterminado tiene las siguientes reglas, y Amazon EMR agrega las mismas reglas si especifica un grupo de seguridad administrado personalizado.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-man-sec-groups.html)
### Edición de reglas de salida
De forma predeterminada, Amazon EMR crea este grupo de seguridad con reglas de salida que permiten todo el tráfico saliente en todos los protocolos y puertos. Se selecciona Permitir todo el tráfico saliente porque varias aplicaciones cliente y de Amazon EMR que se pueden ejecutar en clústeres de Amazon EMR pueden requerir reglas de salida diferentes. Amazon EMR no puede anticipar estos ajustes específicos al crear grupos de seguridad predeterminados. Puede limitar las salidas en sus grupos de seguridad para incluir solo las reglas que se adapten a sus casos de uso y políticas de seguridad. Como mínimo, este grupo de seguridad requiere las siguientes reglas de salida, pero es posible que algunas aplicaciones necesiten una salida adicional.
| Tipo | Protocolo | Rango de puerto | Destino | Details |
| --- | --- | --- | --- | --- |
| Todos los TCP | TCP | Todos | pl- xxxxxxxx | Lista de prefijos de Amazon S3 administrados com.amazonaws.MyRegion.s3. |
| All Traffic | Todos | Todos | sg- xxxxxxxxxxxxxxxxx | El ID del grupo de seguridad ElasticMapReduce-Core-Private. |
| All Traffic | Todos | Todos | sg- xxxxxxxxxxxxxxxxx | El ID del grupo de seguridad ElasticMapReduce-Primary-Private. |
| TCP personalizada | TCP | 9443 | sg- xxxxxxxxxxxxxxxxx | El ID del grupo de seguridad ElasticMapReduce-ServiceAccess. |
## Grupo de seguridad administrado por Amazon EMR para el acceso de los servicios (subredes privadas)
El grupo de seguridad administrado predeterminado para el acceso a los servicios en subredes privadas tiene el **nombre de grupo** de **ElasticMapReduce- ServiceAccess**. Tiene reglas de entrada y reglas de salida que permiten el tráfico a través de HTTPS (puerto 8443 o 9443) hacia los demás grupos de seguridad administrados en las subredes privadas. Estas reglas permiten que el administrador del clúster se comunique con el nodo principal y con nodos principales y de tarea. Se necesitan las mismas reglas si utiliza grupos de seguridad personalizados.
| Tipo | Protocolo | Intervalo de puertos | origen | Details |
| --- | --- | --- | --- | --- |
| Reglas de entrada necesarias para clústeres de Amazon EMR con versiones 5.30.0 y posteriores. |
| TCP personalizada | TCP | 9443 | El ID de grupo del grupo de seguridad administrado de la instancia principal. | Esta regla permite la comunicación entre el grupo de seguridad de la instancia principal y el grupo de seguridad de acceso al servicio. |
| Reglas de salida necesarias para todos los clústeres de Amazon EMR |
| TCP personalizada | TCP | 8443 | El ID de grupo del grupo de seguridad administrado de la instancia principal. | Estas reglas permiten que el administrador del clúster se comunique con el nodo principal y con nodos principales y de tarea. |
| TCP personalizada | TCP | 8443 | El ID de grupo del grupo de seguridad administrado para las instancias secundarias y de tareas. | Estas reglas permiten que el administrador del clúster se comunique con el nodo principal y con nodos principales y de tarea. |
# Trabajo con grupos de seguridad adicionales para un clúster de Amazon EMR
Tanto si utiliza los grupos de seguridad administrados predeterminados como si especifica grupos de seguridad administrados personalizados, puede utilizar grupos de seguridad adicionales. Los grupos de seguridad adicionales le proporcionan la flexibilidad necesaria para adaptar el acceso entre diferentes clústeres y desde clientes, aplicaciones y recursos externos.
Considere el siguiente escenario de ejemplo. Dispone de varios clústeres y necesita que se comuniquen entre ellos, pero desea permitir el acceso SSH entrante a la instancia principal solo a un determinado subconjunto de clústeres. Para ello, puede utilizar el mismo conjunto de grupos de seguridad administrados para los clústeres. A continuación, debe crear grupos de seguridad adicionales que permitan el acceso SSH entrante desde los clientes de confianza y especificar los grupos de seguridad adicionales para la instancia principal de cada uno de los clústeres del subconjunto.
Puede aplicar hasta 15 grupos de seguridad adicionales a la instancia principal, 15 a las instancias secundarias y de tareas, y 15 para el acceso al servicio (en subredes privadas). Si fuera necesario, puede especificar el mismo grupo de seguridad adicional para las instancias principales, las instancias secundarias y de tareas y el acceso al servicio. El número máximo de grupos de seguridad y reglas de la cuenta está sujeto a los límites de la cuenta. Para obtener más información, consulte [Límites de los grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups) en la *Guía del usuario de Amazon VPC*.
# Especificación de los grupos de seguridad adicionales administrados por Amazon EMR
Puede especificar grupos de seguridad mediante la Consola de administración de AWS AWS CLI, la o la API de Amazon EMR. Si no especifica grupos de seguridad, Amazon EMR crea grupos de seguridad predeterminados. La especificación de grupos de seguridad adicionales es opcional. Puede asignar grupos de seguridad adicionales a las instancias principales, a las instancias secundarias y de tareas y al acceso de los servicios (solo para las subredes privadas).
------
#### [ Console ]
**Para especificar grupos de seguridad con la consola**
1. [Inicie sesión en y abra la Consola de administración de AWS consola de Amazon EMR en https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. En **EMR en EC2** situado en el panel de navegación izquierdo, elija **Clústeres** y, a continuación, elija **Crear clúster**.
1. En **Redes**, seleccione la flecha situada junto a **Grupos de seguridad de EC2 (firewall)** para ampliar esta sección. En **Nodo principal** y en **Nodos principales y de tareas**, se seleccionan de forma predeterminada los grupos de seguridad administrados por Amazon EMR predeterminados. Si utiliza una subred privada, también tiene la opción de seleccionar un grupo de seguridad para **Acceso de servicio**.
1. Para cambiar el grupo de seguridad administrado por Amazon EMR, utilice el menú desplegable **Elegir los grupos de seguridad** para seleccionar una opción diferente de la lista de opciones del **grupo de seguridad administrado por Amazon EMR**. Dispone de un grupo de seguridad administrado por Amazon EMR tanto para **Nodo principal** como para **Nodos principales y de tareas**.
1. Para agregar grupos de seguridad personalizados, utilice el mismo menú desplegable **Elegir los grupos de seguridad** para seleccionar hasta cuatro grupos de seguridad personalizados de la lista de opciones **Grupos de seguridad personalizados**. Puede tener hasta cuatro grupos de seguridad personalizados tanto para **Nodo principal** como para **Nodos principales y de tareas**.
1. Elija cualquier otra opción que se aplique a su clúster.
1. Para lanzar el clúster, elija **Crear clúster**.
------
## Especificar los grupos de seguridad con el AWS CLI
Para especificar grupos de seguridad mediante el, AWS CLI utilice el `create-cluster` comando con los siguientes parámetros de la `--ec2-attributes` opción:
| Parámetro | Description (Descripción) |
| --- | --- |
| `EmrManagedPrimarySecurityGroup` | Utilice este parámetro para especificar un grupo de seguridad administrado personalizado para la instancia principal. Si se especifica este parámetro, también se deben especificar `EmrManagedCoreSecurityGroup`. Para clústeres en subredes privadas, también se debe especificar `ServiceAccessSecurityGroup`. |
| `EmrManagedCoreSecurityGroup` | Utilice este parámetro para especificar un grupo de seguridad administrado personalizado para las instancias secundarias y de tareas. Si se especifica este parámetro, también se deben especificar `EmrManagedPrimarySecurityGroup`. Para clústeres en subredes privadas, también se debe especificar `ServiceAccessSecurityGroup`. |
| `ServiceAccessSecurityGroup` | Utilice este parámetro para especificar un grupo de seguridad administrado personalizado para el acceso de los servicios, que se aplica únicamente a los clústeres de las subredes privadas. El grupo de seguridad que especifique como `ServiceAccessSecurityGroup` no debe usarse para ningún otro propósito y también debe reservarse para Amazon EMR. Si se especifica este parámetro, también se deben especificar `EmrManagedPrimarySecurityGroup`. |
| `AdditionalPrimarySecurityGroups` | Utilice este parámetro para especificar hasta cuatro grupos de seguridad adicionales para la instancia principal. |
| `AdditionalCoreSecurityGroups` | Utilice este parámetro para especificar hasta cuatro grupos de seguridad adicionales para las instancias secundarias y de tareas. |
**Example : especifique grupos de seguridad administrados por Amazon EMR personalizados y grupos de seguridad adicionales**
En el siguiente ejemplo, se especifican grupos de seguridad administrados por Amazon EMR personalizados para un clúster en una subred privada, varios grupos de seguridad adicionales para la instancia principal y un único grupo de seguridad adicional para las instancias secundarias y de tareas.
Se incluyen caracteres de continuación de línea de Linux (\$1) para facilitar la lectura. Se pueden eliminar o utilizar en los comandos de Linux. En Windows, elimínelos o sustitúyalos por un signo de intercalación (^).
```
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 obtener más información, consulte [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html) en la *Referencia de comandos de la AWS CLI *.
# Especificación de grupos de seguridad de EC2 para Cuadernos de Amazon EMR
Al crear un cuaderno de EMR, se utilizan dos grupos de seguridad para controlar el tráfico de red entre el cuaderno de EMR y el clúster de Amazon EMR cuando se usa el editor de cuadernos. Los grupos de seguridad predeterminados tienen reglas mínimas que únicamente permiten el tráfico de red entre el servicio Cuadernos de Amazon EMR y los clústeres a los que están asociados los cuadernos.
Un cuaderno EMR utiliza [Apache Livy](https://livy.incubator.apache.org/) para comunicarse con el clúster mediante un proxy a través del puerto TCP 18888. Cuando crea grupos de seguridad personalizados con reglas adaptadas al entorno, puede limitar el tráfico de la red de forma que solo un subconjunto de cuadernos pueda ejecutar código en el editor de cuadernos en determinados clústeres. El clúster utiliza su seguridad personalizada además de los grupos de seguridad predeterminados del clúster. Para obtener más información, consulte [Control del tráfico de red con grupos de seguridad](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html) en la *Guía de administración de Amazon EMR* y [Especificación de grupos de seguridad de EC2 para Cuadernos de Amazon EMR](#emr-managed-notebooks-security-groups).
## Grupo de seguridad de EC2 predeterminado para la instancia principal
El grupo de seguridad de EC2 predeterminado para la instancia principal está asociado a esta, junto con los grupos de seguridad del clúster para dicha instancia.
Nombre del grupo: **ElasticMapReduceEditors-Livy**
**Reglas**
+ Entrada
Permite el tráfico en el puerto TCP 18888 desde cualquier recurso en el grupo de seguridad de EC2 predeterminado para Cuadernos de Amazon EMR
+ Salida
Ninguno
## Grupo de seguridad de EC2 predeterminado para Cuadernos de Amazon EMR
El grupo de seguridad de EC2 predeterminado para el cuaderno de EMR está asociado al editor de cualquier cuaderno de EMR al que esté asignado.
**Nombre del grupo: -Editor ElasticMapReduceEditors**
**Reglas**
+ Entrada
Ninguno
+ Salida
Permite el tráfico en el puerto TCP 18888 a cualquier recurso en el grupo de seguridad de EC2 predeterminado para Cuadernos de Amazon EMR
## Grupo de seguridad de EC2 personalizado para Cuadernos de Amazon EMR al asociar cuadernos con repositorios de Git
Para vincular un repositorio de Git a su cuaderno, el grupo de seguridad del cuaderno de EMR debe incluir una regla de salida para permitir que el cuaderno envíe tráfico a Internet. Se recomienda crear un nuevo grupo de seguridad para este fin. La actualización del grupo de seguridad **ElasticMapReduceEditors-Editor** predeterminado puede dar las mismas reglas de salida a otros blocs de notas adjuntos a este grupo de seguridad.
**Reglas**
+ Entrada
Ninguno
+ Salida
Permita que el cuaderno envíe tráfico a Internet a través del clúster, como se muestra en el siguiente ejemplo: El valor 0.0.0.0/0 se usa solo como ejemplo. Puede modificar esta regla para especificar las direcciones IP de sus repositorios basados en Git.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-managed-notebooks-security-groups.html)
# Uso de Bloquear el acceso público de Amazon EMR
*Bloquear el acceso público (BPA)* de Amazon EMR le impide lanzar un clúster en una subred pública si el clúster tiene una configuración de seguridad que permite el tráfico entrante desde direcciones IP públicas en un puerto.
**importante**
*Bloquear el acceso público* está habilitado de forma predeterminada. Si desea aumentar la protección de la cuenta, le recomendamos que lo mantenga habilitado.
## Explicación de Bloquear el acceso público
Puede utilizar la configuración de cuenta de *Bloquear el acceso público* para administrar de forma centralizada el acceso a la red pública a los clústeres de Amazon EMR.
Cuando un usuario de su empresa Cuenta de AWS lanza un clúster, Amazon EMR comprueba las reglas de puerto del grupo de seguridad del clúster y las compara con las reglas de tráfico entrante. Si el grupo de seguridad tiene una regla de entrada que abre los puertos a las direcciones IP públicas IPv4 0.0.0.0/0 o IPv6 : :/0, y esos puertos no se especifican como excepciones para su cuenta, Amazon EMR no permite que el usuario cree el clúster.
Si un usuario modifica las reglas del grupo de seguridad de un clúster en ejecución en una subred pública para tener una regla de acceso público que infrinja la configuración de BPA de su cuenta, Amazon EMR revoca la nueva regla si tiene permiso para hacerlo. Si Amazon EMR no tiene permiso para revocar la regla, crea un evento en el panel de AWS Health que describe la infracción. Para conceder el permiso de revocación de la regla a Amazon EMR, consulte [Configuración de Amazon EMR para revocar las reglas de los grupos de seguridad](#revoke-block-public-access).
Bloquear acceso público está habilitado de forma predeterminada para todos los clústeres de cada Región de AWS de su Cuenta de AWS. BPA se aplica a todo el ciclo de vida de un clúster, pero no a los clústeres que se crean en subredes privadas. Puede configurar excepciones a la regla de BPA; el puerto 22 es una excepción de forma predeterminada. Para obtener más información sobre la configuración de excepciones, consulte [Configuración de Bloquear el acceso público](#configure-block-public-access).
## Configuración de Bloquear el acceso público
Puede actualizar los grupos de seguridad y la configuración de Bloquear el acceso público en sus cuentas en cualquier momento.
Puede activar y desactivar la configuración de bloqueo de acceso público (BPA) con Consola de administración de AWS, AWS Command Line Interface (AWS CLI) y la API Amazon EMR. La configuración se aplica a toda su cuenta de forma puntual. Region-by-Region Para mantener la seguridad del clúster, le recomendamos usar BPA.
------
#### [ Console ]
**Para configurar: bloqueo de acceso público con la consola**
1. [Inicie sesión en y, a continuación Consola de administración de AWS, abra la consola de Amazon EMR en https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr)
1. En la barra de navegación superior, seleccione la **Región** que quiera configurar si aún no está seleccionada.
1. En **EMR en EC2**, en el panel de navegación izquierdo, elija **Bloquear el acceso público**.
1. En **Block public access settings (Configuración de Block Public Access)**, complete los pasos siguientes.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-block-public-access.html)
------
#### [ AWS CLI ]
**Para configurar el bloqueo del acceso público mediante el AWS CLI**
+ Utilice el comando `aws emr put-block-public-access-configuration` para configurar Block Public Access, tal y como se muestra en los siguientes ejemplos.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ManagementGuide/emr-block-public-access.html)
------
## Configuración de Amazon EMR para revocar las reglas de los grupos de seguridad
Amazon EMR necesita permiso para revocar las reglas de los grupos de seguridad y cumplir con la configuración de Bloquear el acceso público. Puede seguir uno de estos métodos para conceder a Amazon EMR el permiso que necesita:
+ **Recomendado** Asocie la política administrada `AmazonEMRServicePolicy_v2` al rol de servicio. Para obtener más información, consulte [Rol de servicio para Amazon EMR (rol de EMR)](emr-iam-role.md).
+ Cree una nueva política insertada que permita realizar la acción `ec2:RevokeSecurityGroupIngress` en los grupos de seguridad. Para obtener más información sobre cómo modificar una política de permisos de roles, consulte **Modificación de una política de permisos de rol** con la [consola de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy), la [API de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-api.html#roles-modify_permissions-policy-api) y [AWS CLI](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-cli.html#roles-modify_permissions-policy-cli) en la *Guía del usuario de IAM*.
## Resolución de infracciones de Bloquear el acceso público
Si se produce una infracción de Bloquear el acceso público, puede mitigarla con una de las siguientes acciones:
+ Si desea acceder a una interfaz web de su clúster, utilice una de las opciones descritas en [Ver las interfaces web alojadas en clústeres de Amazon EMR](emr-web-interfaces.md) para acceder a la interfaz a través de SSH (puerto 22).
+ Para permitir el tráfico al clúster desde direcciones IP específicas en lugar de desde la dirección IP pública, agregue una regla de grupo de seguridad. Para obtener más información, consulte [Agregar reglas a un grupo de seguridad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) en la *Guía de introducción de Amazon EC2*.
+ **(No recomendado)** Puede configurar las excepciones de BPA de Amazon EMR para que incluyan el puerto o el rango de puertos que desee. Al especificar una excepción de BPA, se crea un riesgo con un puerto desprotegido. Si planea especificar una excepción, debe eliminarla tan pronto como deje de ser necesaria. Para obtener más información, consulte [Configuración de Bloquear el acceso público](#configure-block-public-access).
## Identificación de los clústeres asociados a las reglas de los grupos de seguridad
Es posible que tenga que identificar todos los clústeres asociados a una regla de grupo de seguridad determinada o buscar la regla de grupo de seguridad de un clúster determinado.
+ Si conoce el grupo de seguridad, puede identificar sus clústeres asociados si encuentra las interfaces de red del grupo de seguridad. Para obtener más información, consulte [¿Cómo puedo encontrar los recursos asociados a un grupo de seguridad de Amazon EC2?](https://forums.aws.amazon.com/knowledge-center/ec2-find-security-group-resources) en AWS re:Post. Las instancias de Amazon EC2 que estén conectadas a estas interfaces de red se etiquetarán con el ID del clúster al que pertenecen.
+ Si desea buscar los grupos de seguridad de un clúster conocido, siga los pasos que se indican en [Visualización del estado y los detalles del clúster de Amazon EMR](emr-manage-view-clusters.md). Puede encontrar los grupos de seguridad del clúster en el panel **Red y seguridad** de la consola o en el campo `Ec2InstanceAttributes` de la AWS CLI.
# Validación de la conformidad de Amazon EMR
Los auditores externos evalúan la seguridad y el cumplimiento de Amazon EMR como parte de varios programas de AWS cumplimiento. Estos incluyen SOC, PCI, FedRAMP, HIPAA y otros.
Para obtener una lista de AWS los servicios incluidos en el ámbito de los programas de conformidad específicos, consulte los [AWS servicios incluidos en el ámbito de aplicación por programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/). Para obtener información general, consulte [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/).
Puede descargar informes de auditoría de terceros utilizando AWS Artifact. Para obtener más información, consulte [Descargar informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
La responsabilidad de conformidad al utilizar Amazon EMR se determina en función de la confidencialidad de los datos, los objetivos de conformidad de la empresa y la legislación y normativa aplicables. Si el uso de Amazon EMR está sujeto al cumplimiento de normas como HIPAA, PCI o FedRAMP, proporciona recursos que le ayudarán a: AWS
+ Guías de [inicio rápido sobre seguridad y conformidad: estas guías](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) de implementación analizan las consideraciones arquitectónicas y proporcionan los pasos para implementar entornos básicos centrados en la seguridad y el cumplimiento. AWS
+ Documento técnico sobre [cómo diseñar una arquitectura basada en la seguridad y el cumplimiento de la HIPAA: este documento técnico describe cómo pueden utilizar](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) las empresas para crear aplicaciones que cumplan con la HIPAA. AWS
+ [AWS Recursos de cumplimiento](https://aws.amazon.com/compliance/resources/): esta colección de libros de trabajo y guías puede aplicarse a su sector y ubicación.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Este AWS servicio evalúa en qué medida las configuraciones de sus recursos cumplen con las prácticas internas, las directrices del sector y las normativas.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Este AWS servicio proporciona una visión integral del estado de su seguridad AWS que le ayuda a comprobar el cumplimiento de los estándares y las mejores prácticas del sector de la seguridad.
# Resiliencia en Amazon EMR
La infraestructura AWS global se basa en AWS regiones y zonas de disponibilidad. AWS Las regiones proporcionan varias zonas de disponibilidad aisladas y separadas físicamente, que están conectadas mediante redes de baja latencia, alto rendimiento y alta redundancia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
[Para obtener más información sobre AWS las regiones y las zonas de disponibilidad, consulte la infraestructura global.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
Además de la infraestructura AWS global, Amazon EMR ofrece varias funciones que ayudan a respaldar sus necesidades de respaldo y resiliencia de datos.
+ **Integración con Amazon S3 a través de EMRFS**
+ **Soporte para varios nodos principales**
# Seguridad de la infraestructura de Amazon EMR
Como servicio gestionado, Amazon EMR está protegido por la seguridad de la red AWS global. Para obtener información sobre los servicios AWS de seguridad y cómo se AWS protege la infraestructura, consulte [Seguridad AWS en la nube](https://aws.amazon.com/security/). Para diseñar su AWS entorno utilizando las mejores prácticas de seguridad de la infraestructura, consulte [Protección de infraestructuras en un marco](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de buena * AWS arquitectura basado en el pilar de la seguridad*.
Utiliza las llamadas a la API AWS publicadas para acceder a Amazon EMR a través de la red. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
**Topics**
+ [Conexión a Amazon EMR mediante un punto de conexión de VPC de tipo interfaz](interface-vpc-endpoint.md)
# Conexión a Amazon EMR mediante un punto de conexión de VPC de tipo interfaz
Puede conectarse directamente a Amazon EMR mediante un [punto de enlace de VPC de interfaz (AWS PrivateLink) en su Virtual Private Cloud (](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html)VPC) en lugar de conectarse a través de Internet. Cuando utiliza un punto final de VPC de interfaz, la comunicación entre su VPC y Amazon EMR se lleva a cabo íntegramente dentro de la red. AWS Cada punto final de la VPC está representado por una o más [interfaces de red elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) con direcciones IP privadas en las subredes de la VPC.
El punto de conexión de la VPC de la interfaz conecta la VPC directamente a Amazon EMR sin necesidad de una pasarela de Internet, un dispositivo NAT, una conexión VPN o una conexión. Direct Connect Las instancias de la VPC no necesitan direcciones IP públicas para comunicarse con la API de Amazon EMR.
Para utilizar Amazon EMR a través de la VPC, debe conectarse desde una instancia que esté dentro de la VPC o conectar su red privada a la VPC a través de una red privada virtual (VPN) de Amazon o Direct Connect. Para obtener más información sobre Amazon VPN, consulte [Conexiones VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) en la *Guía del usuario de Amazon Virtual Private Cloud*. *Para obtener información al respecto AWS Direct Connect, consulte [Crear una conexión](https://docs.aws.amazon.com/directconnect/latest/UserGuide/create-connection.html) en la Guía del Direct Connect usuario.*
Puede crear un punto de enlace de VPC de interfaz para conectarse a Amazon EMR mediante la AWS consola o AWS Command Line Interface los comandos ().AWS CLI Para obtener más información, consulte [Creación de un punto de conexión de interfaz](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html#create-interface-endpoint).
Después de crear un punto de conexión de VPC de tipo interfaz, si habilita nombres de host DNS privados para el punto de conexión, el punto de conexión predeterminado de Amazon EMR se resuelve en el punto de conexión de VPC. El punto de conexión del nombre de servicio predeterminado de Amazon EMR tiene el siguiente formato:
```
elasticmapreduce.Region.amazonaws.com
```
Si no habilita nombres de host de DNS privados, Amazon VPC proporciona un nombre de punto de conexión de DNS que puede utilizar en el siguiente formato.
```
VPC_Endpoint_ID.elasticmapreduce.Region.vpce.amazonaws.com
```
Para obtener más información, consulte [Puntos de conexión de VPC de interfaz (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) en la *Guía del usuario de Amazon VPC*.
Amazon EMR permite llamar a todas las [acciones de la API](https://docs.aws.amazon.com/emr/latest/APIReference/API_Operations.html) en su VPC.
Puede adjuntar políticas de punto de conexión de VPC a un punto de conexión de VPC para controlar el acceso de las entidades principales de IAM. También puede asociar grupos de seguridad con un punto de conexión de VPC para controlar el acceso de entrada y salida en función del origen y el destino del tráfico de red, como un rango de direcciones IP. Para obtener más información, consulte [Control del acceso a los servicios con puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html).
## Creación de una política de punto de conexión de VPC para Amazon EMR
Puede crear una política para los puntos de conexión de VPC de Amazon para Amazon EMR y especificar lo siguiente:
+ La entidad principal que puede o no puede realizar acciones
+ Las acciones que se pueden realizar
+ Los recursos en los que se pueden llevar a cabo las acciones
Para más información, consulte [Control del acceso a los servicios con puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) en la *Guía del usuario de Amazon VPC*.
**Example — Política de punto final de VPC para denegar todo acceso desde una cuenta específica AWS**
La siguiente política de punto final de VPC deniega a la AWS cuenta *123456789012* todo acceso a los recursos que utilizan el punto final.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": {
"AWS": [
"123456789012"
]
}
}
]
}
```
**Example : política de punto de conexión de VPC para permitir el acceso de VPC solo a una entidad principal de IAM especificada (usuario).**
La siguiente política de puntos finales de VPC permite el acceso total solo a un usuario *lijuan* de la cuenta. AWS *123456789012* A las demás entidades principales de IAM se les deniega el acceso a través del punto de enlace.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:user/lijuan"
]
}
}]
}
```
**Example : política de punto de conexión de VPC para permitir operaciones de EMR de solo lectura.**
La siguiente política de puntos finales de VPC permite que solo la AWS cuenta realice *123456789012* las acciones especificadas de Amazon EMR.
Las acciones especificadas proporcionan el equivalente al acceso de solo lectura para Amazon EMR. Las demás acciones en la VPC se deniegan para la cuenta especificada. A las demás cuentas se les deniega el acceso. Para obtener una lista de acciones de Amazon EMR, consulte [Acciones, recursos y claves de condición de 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 punto de conexión de VPC que deniega el acceso a un clúster específico.**
La siguiente política de puntos finales de VPC permite el acceso total a todas las cuentas y entidades principales, pero deniega el acceso de la AWS cuenta *123456789012* a las acciones realizadas en el clúster de Amazon EMR con el ID de clúster. *j-A1B2CD34EF5G* Se siguen permitiendo otras acciones de Amazon EMR que no admiten permisos de recursos para los clústeres. Para obtener una lista de acciones de Amazon EMR y su tipo de recurso correspondiente, consulte [Acciones, recursos y claves de condición para 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"
]
}
}
]
}
```