Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Identity and Access Management (IAM) en Amazon EMR sin servidor AWS Identity and Access Management (IAM) es una Servicio de AWS que ayuda al administrador a controlar de forma segura el acceso a AWS los recursos. Los administradores de IAM controlan quién se puede *autenticar* (iniciar sesión) y *autorizar* (tener permisos) para utilizar los recursos de Amazon EMR sin servidor. La IAM es una Servicio de AWS herramienta que puede utilizar sin coste adicional. **Topics** + [Público](#security_iam_audience) + [Autenticación con identidades](#security_iam_authentication) + [Administración del acceso con políticas](#security_iam_access-manage) + [Cómo funciona EMR sin servidor con IAM](security-iam-serverless.md) + [Uso de rRoles vinculados al servicio de EMR sin servidor](using-service-linked-roles.md) + [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md) + [Ejemplos de políticas de acceso de usuario para EMR sin servidor](security-iam-user-access-policies.md) + [Políticas para el control de acceso basado en etiquetas](security-iam-TBAC.md) + [Ejemplos de políticas basadas en identidades para EMR sin servidor](security-iam-id-based-policy-examples.md) + [Amazon EMR Serverless actualiza las políticas gestionadas AWS](#security-iam-awsmanpol-updates) + [Solución de problemas de identidad y acceso de Amazon EMR sin servidor](security_iam_troubleshoot.md) ## Público La forma de usar AWS Identity and Access Management (IAM) varía según la función que desempeñes: + **Usuario del servicio:** solicite permisos al administrador si no puede acceder a las características (consulte [Solución de problemas de identidad y acceso de Amazon EMR sin servidor](security_iam_troubleshoot.md)). + **Administrador del servicio:** determine el acceso de los usuarios y envíe las solicitudes de permiso (consulte [Identity and Access Management (IAM) en Amazon EMR sin servidor](#security_iam_service-with-iam)). + **Administrador de IAM**: escribe las políticas para administrar el acceso (consulte [Políticas basadas en identidades de ejemplo para EMR sin servidor](security-iam-serverless.md#security_iam_id-based-policy-examples)). ## Autenticación con identidades La autenticación es la forma en que inicias sesión AWS con tus credenciales de identidad. Debe autenticarse como usuario de Usuario raíz de la cuenta de AWS IAM o asumir una función de IAM. Puede iniciar sesión como una identidad federada con las credenciales de una fuente de identidad, como AWS IAM Identity Center (IAM Identity Center), la autenticación de inicio de sesión único o las credenciales. Google/Facebook Para obtener más información sobre el inicio de sesión, consulte [Cómo iniciar sesión en la Cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de AWS Sign-In *. Para el acceso programático, AWS proporciona un SDK y una CLI para firmar criptográficamente las solicitudes. Para obtener más información, consulte [AWS Signature Version 4 para solicitudes de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) en la *Guía del usuario de IAM*. ### Cuenta de AWS usuario root Al crear un Cuenta de AWS, se comienza con una identidad de inicio de sesión denominada *usuario Cuenta de AWS raíz* que tiene acceso completo a todos Servicios de AWS los recursos. Se recomiendaencarecidamente que no utilice el usuario raíz para las tareas diarias. Para ver las tareas que requieren credenciales de usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*. ### Identidad federada Como práctica recomendada, exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder Servicios de AWS mediante credenciales temporales. Una *identidad federada* es un usuario del directorio empresarial, del proveedor de identidades web o al Directory Service que se accede Servicios de AWS mediante credenciales de una fuente de identidad. Las identidades federadas asumen roles que proporcionan credenciales temporales. Para una administración de acceso centralizada, se recomienda AWS IAM Identity Center. Para obtener más información, consulte [¿Qué es el Centro de identidades de IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) en la *Guía del usuario de AWS IAM Identity Center *. ### Usuarios y grupos de IAM Un *[usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* es una identidad con permisos específicos para una sola persona o aplicación. Recomendamos el uso de credenciales temporales en lugar de usuarios de IAM con credenciales de larga duración. Para obtener más información, consulte [Exigir a los usuarios humanos que utilicen la federación con un proveedor de identidad para acceder AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la Guía del usuario de *IAM*. Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica un conjunto de usuarios de IAM y facilita la administración de los permisos para grupos grandes de usuarios. Para obtener más información, consulte [Casos de uso para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) en la *Guía del usuario de IAM*. ### Roles de IAM Un *[Rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad con permisos específicos que proporciona credenciales temporales. Puede asumir un rol [cambiando de un rol de usuario a uno de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o llamando a una AWS CLI operación de AWS API. Para obtener más información, consulte [Métodos para asumir un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) en la *Guía del usuario de IAM*. Los roles de IAM son útiles para el acceso de usuario federado, los permisos de usuario de IAM temporales, el acceso entre cuentas, el acceso entre servicios y las aplicaciones que se ejecutan en Amazon EC2. Para obtener más información, 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*. ## Administración del acceso con políticas AWS Para controlar el acceso, puede crear políticas y adjuntarlas a AWS identidades o recursos. Una política define los permisos cuando están asociados a una identidad o un recurso. AWS evalúa estas políticas cuando un director hace una solicitud. La mayoría de las políticas se almacenan AWS como documentos JSON. Para obtener más información sobre los documentos de políticas de JSON, consulte [Información general de políticas de JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*. Mediante las políticas, los administradores especifican quién tiene acceso a qué, definiendo qué **entidad principal** puede realizar **acciones** sobre qué **recursos** y en qué **condiciones**. De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM crea políticas de IAM y las agrega a roles, que los usuarios pueden asumir posteriormente. Las políticas de IAM definen permisos independientemente del método que se utilice para realizar la operación. ### Políticas basadas en identidades Las políticas basadas en identidad son documentos de política de permisos JSON que asocia a una identidad (usuario, grupo o rol). Estas políticas controlan qué acciones pueden realizar las identidades, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*. Las políticas basadas en identidad pueden ser *políticas insertadas* (incrustadas directamente en una sola identidad) o *políticas administradas* (políticas independientes asociadas a varias identidades). Para obtener información sobre cómo elegir entre políticas administradas e insertadas, consulte [Selección entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) en la *Guía del usuario de IAM*. ### Políticas basadas en recursos Las políticas basadas en recursos son documentos de políticas JSON que se asocian a un recurso. Los ejemplos incluyen las *Políticas de confianza de roles* de IAM y las *Políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No puedes usar políticas AWS gestionadas de IAM en una política basada en recursos. ### Otros tipos de políticas AWS admite tipos de políticas adicionales que pueden establecer los permisos máximos que conceden los tipos de políticas más comunes: + **Límites de permisos:** establecen los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Para obtener más información, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*. + **Políticas de control de servicios (SCPs)**: especifican los permisos máximos para una organización o unidad organizativa en AWS Organizations. Para obtener más información, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations *. + **Políticas de control de recursos (RCPs)**: establece los permisos máximos disponibles para los recursos de tus cuentas. Para obtener más información, consulte [Políticas de control de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) en la *Guía del AWS Organizations usuario*. + **Políticas de sesión:** políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal para un rol o un usuario federado. Para obtener más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*. ### Varios tipos de políticas Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados de entender. Para saber cómo se AWS determina si se debe permitir una solicitud cuando se trata de varios tipos de políticas, consulte la [lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario de IAM*. # Cómo funciona EMR sin servidor con IAM Antes de utilizar IAM para administrar el acceso a Amazon EMR sin servidor, obtenga información sobre qué características de IAM se encuentran disponibles con Amazon EMR sin servidor. **Características de IAM que puede utilizar con EMR sin servidor** | Característica de IAM | Compatibilidad de Amazon EMR sin servidor | | --- | --- | | [Políticas basadas en identidades](#security-iam-id-based-policies) | Sí | | [Políticas basadas en recursos](#security-iam-resource-based-policies) | No | | [Acciones de políticas](#security-iam-id-based-policies-actions) | Sí | | [Recursos de políticas](#security-iam-id-based-policies-resources) | Sí | | [Claves de condición de política](#security-iam-id-based-policies-conditionkeys) | No | | [ACLs](#security-iam-acls) | No | | [ABAC (etiquetas en políticas)](#security-iam-tags) | Sí | | [Credenciales temporales](#security-iam-roles-tempcreds) | Sí | | [Permisos de entidades principales](#security-iam-principal-permissions) | Sí | | [Roles de servicio](#security-iam-roles-service) | No | | [Roles vinculados al servicio](#security-iam-roles-service-linked) | Sí | *Para obtener una visión general de cómo funcionan EMR Serverless y otros AWS servicios con la mayoría de las funciones de IAM, consulte los [AWS servicios que funcionan con IAM en la Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).* ## Políticas basadas en identidades de EMR sin servidor **Compatibilidad con las políticas basadas en identidad:** sí Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como un usuario de IAM, un grupo de usuarios o un rol. Estas políticas controlan qué acciones pueden realizar los usuarios y los roles, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*. Con las políticas basadas en identidades de IAM, puede especificar las acciones y los recursos permitidos o denegados, así como las condiciones en las que se permiten o deniegan las acciones. Para obtener más información sobre los elementos que puede utilizar en una política de JSON, consulte [Referencia de los elementos de la política de JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*. ### Políticas basadas en identidades de ejemplo para EMR sin servidor Para acceder a ejemplos de políticas basadas en identidades de Amazon EMR sin servidor, consulte [Ejemplos de políticas basadas en identidades para EMR sin servidor](security-iam-id-based-policy-examples.md). ## Políticas basadas en recursos dentro de Amazon EMR sin servidor **Admite políticas basadas en recursos:** no Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Los ejemplos de políticas basadas en recursos son las *políticas de confianza de roles* de IAM y las *políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Para el recurso al que se asocia la política, la política define qué acciones puede realizar una entidad principal especificada en ese recurso y en qué condiciones. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Los principales pueden incluir cuentas, usuarios, roles, usuarios federados o. Servicios de AWS Para habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como la entidad principal de una política en función de recursos. Para obtener más información, 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*. ## Acciones de políticas para EMR sin servidor **Compatibilidad con las acciones de políticas:** sí Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**. El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada. A fin de conocer una lista completa de acciones de EMR sin servidor, consulte [Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) en la *Referencia de autorizaciones de servicio*. Las acciones de políticas de EMR sin servidor utilizan el siguiente prefijo antes de la acción. ``` emr-serverless ``` Para especificar varias acciones en una única instrucción, sepárelas con comas. ``` "Action": [ "emr-serverless:action1", "emr-serverless:action2" ] ``` Para acceder a ejemplos de políticas basadas en identidades de Amazon EMR sin servidor, consulte [Ejemplos de políticas basadas en identidades para EMR sin servidor](security-iam-id-based-policy-examples.md). ## Recursos de políticas para EMR sin servidor **Compatibilidad con los recursos de políticas:** sí Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**. El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). En el caso de las acciones que no admiten permisos por recurso, utilice un carácter comodín (\$1) para indicar que la instrucción se aplica a todos los recursos. ``` "Resource": "*" ``` *Para consultar una lista de los tipos de recursos de Amazon EMR Serverless y sus tipos de recursos ARNs, consulte [Recursos definidos por Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-resources-for-iam-policies) en la Referencia de autorización de servicios.* Para saber con qué acciones especifican el ARN de cada recurso, consulte [Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html). Para acceder a ejemplos de políticas basadas en identidades de Amazon EMR sin servidor, consulte [Ejemplos de políticas basadas en identidades para EMR sin servidor](security-iam-id-based-policy-examples.md). ## Claves de condición de políticas para EMR Serverless **Compatibilidad con claves de condición de políticas** | | | | --- |--- | | Admite claves de condición de políticas específicas del servicio | No | Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**. El elemento `Condition` especifica cuándo se ejecutan las instrucciones en función de criterios definidos. Puede crear expresiones condicionales que utilizan [operadores de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tales como igual o menor que, para que la condición de la política coincida con los valores de la solicitud. Para ver todas las claves de condición AWS globales, consulte las claves de [contexto de condición AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*. Para obtener una lista de las claves de condición de Amazon EMR sin servidor y para más información sobre qué acciones y recursos admiten el uso de una clave de condición, consulte [Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) en la *Referencia de autorizaciones de servicio*. Todas las acciones de Amazon EC2 admiten las claves de condición `aws:RequestedRegion` y `ec2:Region`. Para obtener más información, consulte [Ejemplo: Restringir el acceso a una región específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region). ## Listas de control de acceso (ACLs) en EMR Serverless **Soporta ACLs**: No Las listas de control de acceso (ACLs) controlan qué directores (miembros de la cuenta, usuarios o roles) tienen permisos para acceder a un recurso. ACLs son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON. ## Control de acceso basado en atributos (ABAC) con EMR sin servidor **Compatibilidad con el control de acceso basado en atributos (ABAC)** | | | | --- |--- | | Admite ABAC (etiquetas en las políticas) | Sí | El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos denominados etiquetas. Puede adjuntar etiquetas a las entidades y AWS los recursos de IAM y, a continuación, diseñar políticas de ABAC para permitir las operaciones cuando la etiqueta del director coincida con la etiqueta del recurso. Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`. Si un servicio admite las tres claves de condición para cada tipo de recurso, el valor es **Sí** para el servicio. Si un servicio admite las tres claves de condición solo para algunos tipos de recursos, el valor es **Parcial**. *Para obtener más información sobre ABAC, consulte [Definición de permisos con la autorización de ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) en la Guía del usuario de IAM*. Para ver un tutorial con los pasos para configurar ABAC, consulte [Uso del control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) en la *Guía del usuario de IAM*. ## Uso de credenciales temporales con EMR sin servidor **Compatibilidad con credenciales temporales:** sí Las credenciales temporales proporcionan acceso a AWS los recursos a corto plazo y se crean automáticamente cuando se utiliza la federación o se cambia de rol. AWS recomienda generar credenciales temporales de forma dinámica en lugar de utilizar claves de acceso a largo plazo. Para obtener más información, consulte [Credenciales de seguridad temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) y [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*. ## Permisos de entidades principales entre servicios de EMR sin servidor **Admite sesiones de acceso directo (FAS):** sí Las sesiones de acceso directo (FAS) utilizan los permisos del principal que llama y los que solicitan Servicio de AWS para realizar solicitudes a los servicios descendentes. Servicio de AWS Para obtener información sobre las políticas a la hora de realizar solicitudes de FAS, consulte [Sesiones de acceso directo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). ## Roles de servicio para EMR sin servidor | | | | --- |--- | | Compatible con roles de servicio | No | ## Roles vinculados al servicio de EMR sin servidor | | | | --- |--- | | Compatible con roles vinculados al servicio | Sí | Para más información sobre cómo crear o administrar roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Busque un servicio en la tabla que incluya `Yes` en la columna **Rol vinculado a un servicio**. Seleccione el vínculo **Sí** para acceder a la documentación acerca del rol vinculado a servicios para ese servicio. # Uso de rRoles vinculados al servicio de EMR sin servidor [Amazon EMR Serverless utiliza funciones vinculadas a servicios AWS Identity and Access Management (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 está vinculado directamente a un EMR sin servidor. EMR Serverless predefine las funciones vinculadas al servicio e incluyen todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre. Un rol vinculado a un servicio simplifica la configuración de EMR sin servidor porque ya no tendrá que añadir manualmente los permisos necesarios. EMR sin servidor define los permisos de sus roles vinculados a los servicios y, a menos que esté definido de otra manera, solo EMR sin servidor 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 adjuntar a ninguna otra entidad de IAM. Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma se protegen los recursos de EMR sin servidor, ya que evita que se puedan eliminar accidentalmente permisos de acceso a los recursos. Para obtener información sobre otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Roles vinculados a servicios**. Elija una opción **Sí** con un enlace para acceder a la documentación acerca del rol vinculado al servicio en cuestión. ## Permisos de rol vinculados a servicios para EMR sin servidor EMR Serverless utiliza el rol vinculado al servicio denominado **AWSServiceRoleForAmazonEMRServerless**para permitirle llamar en su nombre. AWS APIs El rol AWSService RoleForAmazon EMRServerless vinculado al servicio confía en los siguientes servicios para asumir el rol: + `ops.emr-serverless.amazonaws.com` La política de permisos del rol denominada `AmazonEMRServerlessServiceRolePolicy` permite que EMR sin servidor realice las siguientes acciones en los recursos especificados: **nota** El contenido de las políticas administradas cambia, por lo que es posible que la política que mostramos aquí se haya quedado obsoleta. Vea la mayoría up-to-date de las políticas de [Amazon EMRServerless ServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRServerlessServiceRolePolicy) en el Consola de administración de AWS. + Acción: `ec2:CreateNetworkInterface` + Acción: `ec2:DeleteNetworkInterface` + Acción: `ec2:DescribeNetworkInterfaces` + Acción: `ec2:DescribeSecurityGroups` + Acción: `ec2:DescribeSubnets` + Acción: `ec2:DescribeVpcs` + Acción: `ec2:DescribeDhcpOptions` + Acción: `ec2:DescribeRouteTables` + Acción: `cloudwatch:PutMetricData` La siguiente política es la política `AmazonEMRServerlessServiceRolePolicy` completa. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EC2PolicyStatement", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeDhcpOptions", "ec2:DescribeRouteTables" ], "Resource": [ "*" ] }, { "Sid": "CloudWatchPolicyStatement", "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "cloudwatch:namespace": [ "AWS/EMRServerless", "AWS/Usage" ] } } } ] } ``` ------ Para permitir que el servicio principal de EMR sin servidor asuma este rol, adjunte la siguiente política de confianza al rol. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "arn:aws:iam::123456789012:role/aws-service-role/emr-serverless.amazonaws.com/AWSServiceRoleForEMRServerless", "Sid": "AllowSTSAssumerole" } ] } ``` ------ 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. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*. ## Creación de un rol vinculado a un servicio para EMR sin servidor No necesita crear manualmente un rol vinculado a servicios. Cuando crea una nueva aplicación EMR Serverless en ( Consola de administración de AWS mediante EMR Studio), la o la AWS CLI API AWS , EMR Serverless crea el rol vinculado al servicio por usted. 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. **Para crear el rol vinculado al servicio mediante IAM AWSService RoleForAmazon EMRServerless ** 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" ], "Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al crear una nueva aplicación de EMR sin servidor, este se encarga nuevamente de crear el rol vinculado a servicios. Puede utilizar la consola de IAM para crear un rol vinculado a servicios con el caso de uso **EMR sin servidor**. En la API AWS CLI o en la AWS API, cree una función vinculada al servicio con el nombre del servicio. `ops.emr-serverless.amazonaws.com` Para obtener más información, consulte [Creación de un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) en la *Guía del usuario de IAM*. Si elimina este rol vinculado al servicio, puede utilizar este mismo proceso para volver a crear el rol. ## Edición de un rol vinculado a un servicio para EMR sin servidor EMR Serverless no le permite editar el rol AWSService RoleForAmazon EMRServerless vinculado al servicio porque varias entidades pueden hacer referencia al rol. No puede editar la política de IAM AWS propia que utiliza el rol vinculado al servicio EMR Serverless, ya que contiene todos los permisos necesarios que EMR Serverless necesita. Sin embargo, puede editar la descripción del rol mediante IAM. **Para editar la descripción del rol vinculado al servicio mediante IAM AWSService RoleForAmazon EMRServerless ** 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/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` Para obtener más información, consulte [Cómo editar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*. ## Eliminación de un rol vinculado a un servicio para EMR sin servidor Si ya no necesita usar una característica o un servicio que requieran un rol vinculado a un servicio, le sugerimos que elimine dicho rol. De esta forma no tiene una entidad no utilizada que no se supervise ni mantenga de forma activa. Sin embargo, debe eliminar todas las aplicaciones de EMR sin servidor de todas las regiones para poder eliminar el rol vinculado a servicio. **nota** Si el servicio EMR sin servidor está utilizando el rol cuando intenta eliminar los recursos asociados al rol, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación. **Para eliminar el rol vinculado al AWSService RoleForAmazon EMRServerless servicio mediante IAM** 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/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*", "Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}} } ``` **Para eliminar manualmente el rol vinculado a servicios mediante IAM** Utilice la consola de IAM AWS CLI, la o la AWS API para eliminar la función vinculada al servicio. AWSService RoleForAmazon EMRServerless Para obtener más información, consulte [Cómo eliminar un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*. ## Regiones admitidas para los roles vinculados a un servicio de EMR sin servidor EMR sin servidor admite el uso de roles vinculados a servicios en todas las regiones en las que el servicio está disponible. Para obtener más información, consulte [Regiones y puntos de conexión de AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html). # Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor Puede especificar los permisos del rol de IAM que una ejecución de trabajo de EMR sin servidor puede asumir cuando llame a otros servicios en su nombre. Esto incluye el acceso a Amazon S3 para cualquier fuente de datos, destino y otros AWS recursos, como los clústeres de Amazon Redshift y las tablas de DynamoDB. Para obtener más información acerca de cómo crear un rol, consulte [Crear un rol de tiempo de ejecución del trabajo](getting-started.md#gs-runtime-role). **Políticas de tiempo de ejecución de ejemplo** Puede adjuntar una política de tiempo de ejecución, como la siguiente, a un rol de tiempo de ejecución de un trabajo. La siguiente política de tiempo de ejecución de trabajos permite: + Acceso de lectura a los buckets de Amazon S3 con ejemplos de EMR. + Acceso completo a los buckets de S3. + Cree y lea el acceso al catálogo de datos de AWS Glue. Para añadir acceso a otros AWS recursos, como DynamoDB, tendrá que incluir sus permisos en la política al crear el rol de tiempo de ejecución. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadAccessForEMRSamples", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*.elasticmapreduce", "arn:aws:s3:::*.elasticmapreduce/*" ] }, { "Sid": "FullAccessToS3Bucket", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Sid": "GlueCreateAndReadDataCatalog", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:CreateDatabase", "glue:GetDataBases", "glue:CreateTable", "glue:GetTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:CreatePartition", "glue:BatchCreatePartition", "glue:GetUserDefinedFunctions" ], "Resource": [ "*" ] } ] } ``` ------ **Transferencia de los privilegios del rol** Puede asociar políticas de permisos de IAM al rol de usuario para permitir al usuario que transfiera solo los roles aprobados. Esto permite a los administradores controlar qué usuarios pueden transferir roles específicos de tiempo de ejecución de trabajos a trabajos de EMR sin servidor. Para obtener más información sobre la configuración de permisos, consulte [Conceder permisos a un usuario para transferir un rol a un AWS servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html). El siguiente es un ejemplo de política que permite transferir un rol de tiempo de ejecución de un trabajo a la entidad principal del servicio EMR sin servidor. ``` { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::1234567890:role/JobRuntimeRoleForEMRServerless", "Condition": { "StringLike": { "iam:PassedToService": "emr-serverless.amazonaws.com" } } } ``` ## Políticas de permisos administradas asociadas con las funciones del tiempo de ejecución Cuando envía ejecuciones de trabajos a EMR sin servidor a través de la consola de EMR Studio, hay un paso en el que debe elegir un **rol de tiempo de ejecución** para asociarlo a su aplicación. Hay políticas administradas subyacentes asociadas a cada selección de la consola que debe tener en cuenta. Las tres opciones son las siguientes: 1. **Todos los buckets**: si eliges esta opción, se especifica la política FullAccess AWS gestionada de [AmazonS3](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FullAccess.html), que proporciona acceso total a todos los buckets. 1. **Buckets específicos**: esta opción especifica el identificador del nombre de recurso de Amazon (ARN) de cada bucket que seleccione. No hay una política administrada subyacente. 1. **Ninguno**: no se incluye ningún permiso de política administrada. Le sugerimos que agregue buckets específicos. Si elige todos los buckets, tenga en cuenta que esta opción configura el acceso completo a todos los buckets. # Ejemplos de políticas de acceso de usuario para EMR sin servidor Puede configurar políticas detalladas para sus usuarios en función de las acciones que desee que realice cada usuario al interactuar con las aplicaciones EMR sin servidor. Las siguientes políticas son ejemplos que pueden ayudar a configurar los permisos adecuados para sus usuarios. Esta sección se centra únicamente en las políticas EMR sin servidor. Para ver ejemplos de las políticas de usuario de EMR Studio, consulte [Configure EMR Studio user permissions](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-advanced-permissions-policy). Para obtener información sobre cómo asociar políticas a los usuarios de IAM (entidades principales), consulte [Administración de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html) en la Guía del usuario de IAM. ## Política de usuarios avanzados Para conceder todas las acciones necesarias para EMR sin servidor, cree y adjunte una política de `AmazonEMRServerlessFullAccess` al usuario, rol o grupo de IAM requerido. El siguiente es un ejemplo de política que permite a los usuarios avanzados crear y modificar aplicaciones EMR sin servidor, así como realizar otras acciones, como enviar y depurar trabajos. Revela todas las acciones que EMR sin servidor requiere para otros servicios. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication", "emr-serverless:UpdateApplication", "emr-serverless:DeleteApplication", "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StopApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ Cuando habilita la conectividad de red con su VPC, las aplicaciones EMR sin servidor crean interfaces de red elásticas (ENI) de Amazon EC2 para comunicarse con los recursos de la VPC. La siguiente política garantiza que cualquier EC2 nuevo solo ENIs se cree en el contexto de las aplicaciones EMR Serverless. **nota** Recomendamos encarecidamente establecer esta política para garantizar que los usuarios no puedan crear EC2 ENIs excepto en el contexto del lanzamiento de aplicaciones EMR Serverless. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowEC2ENICreationWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:network-interface/*" ], "Condition": { "StringEquals": { "aws:CalledViaLast": "ops.emr-serverless.amazonaws.com" } } } ] } ``` ------ Si desea restringir el acceso de EMR sin servidor a determinadas subredes, puede etiquetar cada subred con una condición de etiqueta. Esta política de IAM garantiza que las aplicaciones EMR Serverless solo puedan crear ENIs EC2 dentro de las subredes permitidas. ``` { "Sid": "AllowEC2ENICreationInSubnetAndSecurityGroupWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/KEY": "VALUE" } } } ``` **importante** Si es un administrador o un usuario avanzado que crea su primera aplicación, debe configurar sus políticas de permisos para que le permitan crear un rol vinculado al servicio EMR sin servidor. Para obtener más información, consulte [Uso de rRoles vinculados al servicio de EMR sin servidor](using-service-linked-roles.md). La siguiente política de IAM le permite crear un rol vinculado al servicio de EMR sin servidor para su cuenta. ``` { "Sid":"AllowEMRServerlessServiceLinkedRoleCreation", "Effect":"Allow", "Action":"iam:CreateServiceLinkedRole", "Resource":"arn:aws:iam::account-id:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless" } ``` ## Política de ingeniero de datos A continuación, se muestra un ejemplo de política que permite a los usuarios permisos de solo lectura en las aplicaciones EMR sin servidor, así como la posibilidad de enviar y depurar trabajos. 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. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ ## Uso de etiquetas para el control de acceso Puede usar condiciones de etiquetado para el control de acceso detallado. Por ejemplo, puede restringir a los usuarios de un equipo para que solo puedan enviar trabajos a aplicaciones EMR sin servidor y etiquetadas con el nombre de su equipo. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EMRServerlessActions", "Effect": "Allow", "Action": [ "emr-serverless:ListApplications", "emr-serverless:GetApplication", "emr-serverless:StartApplication", "emr-serverless:StartJobRun", "emr-serverless:CancelJobRun", "emr-serverless:ListJobRuns", "emr-serverless:GetJobRun" ], "Resource": [ "*" ] } ] } ``` ------ # Políticas para el control de acceso basado en etiquetas Puede utilizar las condiciones de su política basada en la identidad para controlar el acceso a las aplicaciones y a las ejecuciones de trabajo basadas en etiquetas. Los siguientes ejemplos muestran distintos supuestos y formas de utilizar los operadores de condiciones con las claves de condición de EMR sin servidor. 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 las 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 se deniegan 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. Para ver un ejemplo de una política que deniega las acciones de etiquetado, consulte [Denegar el acceso para agregar y eliminar etiquetas](#security-iam-TBAC-deny). 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 las aplicaciones de EMR sin servidor. ## Permitir acciones solo en recursos con valores de etiqueta específicos 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 agregó a la aplicación 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 aplicaciones que tengan este valor para esta etiqueta. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:GetApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/department": "dev" } }, "Sid": "AllowEMRSERVERLESSGetapplication" } ] } ``` ------ También puede especificar varios valores de etiqueta utilizando un operador de condición. Por ejemplo, para permitir acciones en las aplicaciones donde la etiqueta `department` contenga el valor `dev` o `test`, reemplace el bloque de condición en el ejemplo anterior por los siguientes. ``` "Condition": { "StringEquals": { "emr-serverless:ResourceTag/department": ["dev", "test"] } } ``` ## Requerir etiquetado cuando se crea un recurso En el siguiente ejemplo, la etiqueta debe aplicarse al crear la aplicación. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } }, "Sid": "AllowEMRSERVERLESSCreateapplication" } ] } ``` ------ La siguiente instrucción de política permite a un usuario crear una aplicación solo si la aplicación tiene una etiqueta `department`, que puede contener cualquier valor. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "emr-serverless:CreateApplication" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] } }, "Sid": "AllowEMRSERVERLESSCreateapplication" } ] } ``` ------ ## Denegar el acceso para agregar y eliminar etiquetas Esta política impide que un usuario agregue o elimine etiquetas en las aplicaciones EMR sin servidor con una etiqueta `department` cuyo valor no sea `dev`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "emr-serverless:TagResource", "emr-serverless:UntagResource" ], "Resource": [ "*" ], "Condition": { "StringNotEquals": { "aws:PrincipalTag/department": "dev" } }, "Sid": "AllowEMRSERVERLESSTagresource" } ] } ``` ------ # Ejemplos de políticas basadas en identidades para EMR sin servidor De forma predeterminada, los usuarios y roles no tienen permiso para crear ni modificar los recursos de Amazon EMR sin servidor. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan. Para obtener información acerca de cómo crear una política basada en identidades de IAM mediante el uso de estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) en la *Guía del usuario de IAM*. *Para obtener más información sobre las acciones y los tipos de recursos definidos por Amazon EMR Serverless, incluido el formato de cada uno de ARNs los tipos de recursos, consulte [Acciones, recursos y claves de condición de Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html) en la Referencia de autorización de servicios.* **Topics** + [Prácticas recomendadas sobre las políticas](#security-iam-policy-best-practices) + [Cómo permitir a los usuarios acceder a sus propios permisos](#security-iam-id-based-policy-examples-view-own-permissions) ## Prácticas recomendadas sobre las políticas **nota** EMR sin servidor no admite políticas administradas, por lo que no se aplica la primera práctica que se detalla a continuación. Las políticas basadas en identidades determinan si alguien puede crear, eliminar o acceder a los recursos de Amazon EMR sin servidor de la cuenta. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades: + **Comience con las políticas AWS administradas y avance hacia los permisos con privilegios mínimos: para empezar a conceder permisos** a sus usuarios y cargas de trabajo, utilice las *políticas AWS administradas* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su. Cuenta de AWS Le recomendamos que reduzca aún más los permisos definiendo políticas administradas por el AWS cliente que sean específicas para sus casos de uso. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*. + **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*. + **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puedes usar condiciones para conceder el acceso a las acciones del servicio si se utilizan a través de una acción específica Servicio de AWS, por ejemplo CloudFormation. Para obtener más información, consulte [Elementos de la política de 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*. + **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*. + **Requerir autenticación multifactor (MFA**): si tiene un escenario que requiere usuarios de IAM o un usuario raíz en Cuenta de AWS su cuenta, active la MFA para mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*. Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*. ## Cómo permitir a los usuarios acceder a 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 asocian 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 API o. AWS CLI AWS ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` ## Amazon EMR Serverless actualiza las políticas gestionadas AWS Acceda a los detalles sobre las actualizaciones de las políticas AWS administradas de Amazon EMR Serverless desde que este servicio comenzó a rastrear estos cambios. Para obtener alertas automáticas sobre cambios en esta página, suscríbase a la fuente RSS en la página del [Historial de documentos](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/doc-history.html) de Amazon EMR sin servidor. | Cambio | Descripción | Fecha | | --- | --- | --- | | Amazon EMRServerlessServiceRolePolicy : actualización de una política existente | [Amazon EMR Serverless ha añadido la nueva `Sid``CloudWatchPolicyStatement` y a la política `EC2PolicyStatement` de Amazon. EMRServerless ServiceRolePolicy ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/using-service-linked-roles.html#slr-permissions) | 25 de enero de 2024 | | Amazon EMRServerlessServiceRolePolicy : actualización de una política existente | Amazon EMR sin servidor agregó nuevos permisos para permitir que Amazon EMR sin servidor publique métricas de cuenta agregadas para el uso de vCPU en el espacio de nombres `"AWS/Usage"`. | 20 de abril de 2023 | | Amazon EMR sin servidor ha comenzado a hacer un seguimiento de los cambios | Amazon EMR Serverless comenzó a realizar un seguimiento de los cambios en sus AWS políticas gestionadas. | 20 de abril de 2023 | # Solución de problemas de identidad y acceso de Amazon EMR sin servidor Utilice la siguiente información para diagnosticar y solucionar los problemas habituales que pueden surgir cuando se trabaja con Amazon EMR sin servidor e IAM. **Topics** + [No tengo autorización para realizar una acción en Amazon EMR sin servidor](#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 Serverless](#security_iam_troubleshoot-cross-account-access) + [No puedo abrir el servidor de UI/Spark historial en vivo desde EMR Studio para depurar mi trabajo o se produce un error de API cuando intento obtener registros usando `get-dashboard-for-job-run`](#security_iam_troubleshoot-emr-identity-access) ## No tengo autorización para realizar una acción en Amazon EMR sin servidor Si Consola de administración de AWS le indica que no está autorizado a realizar una acción, póngase en contacto con su administrador para obtener ayuda. El administrador es la persona que le facilitó el nombre de usuario y la contraseña. El siguiente ejemplo de error se produce cuando el usuario `mateojackson` intenta utilizar la consola para acceder a los detalles acerca de un recurso ficticio `my-example-widget`, pero no tiene los permisos ficticios `emr-serverless:GetWidget`. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: emr-serverless: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-serverless: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 sin servidor. 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 servidor. 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 Serverless 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 usar 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 sin servidor admite estas características, consulte [Identity and Access Management (IAM) en Amazon EMR sin servidor](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*. ## No puedo abrir el servidor de UI/Spark historial en vivo desde EMR Studio para depurar mi trabajo o se produce un error de API cuando intento obtener registros usando `get-dashboard-for-job-run` Si utiliza el almacenamiento administrado de EMR sin servidor para los registros y su aplicación de EMR sin servidor se encuentra en una subred privada con puntos de conexión de VPC para Amazon S3 y adjunta una política de puntos de conexión para controlar el acceso, agregue los permisos que se mencionan en [Registros para EMR sin servidor con almacenamiento administrado](logging.html#jobs-log-storage-managed-storage) de su política de VPC al punto de conexión de la puerta de enlace de S3 para que EMR sin servidor almacene y proporcione los registros de la aplicación.