View a markdown version of this page

Consideraciones y limitaciones de Amazon EMR con la integración de Identity Center - Amazon EMR

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.

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 una propagación de identidades confiable, debe usar AWS CLI para crear una configuración de seguridad que tenga habilitada la propagación de identidades confiables 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.

  • Fine-grained Los controles de acceso AWS Lake Formation que utilizan ese uso de Trusted Identity Propagation están disponibles para los clústeres de Amazon EMR con 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 tabla, 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.

  • Fine-grained Los controles de acceso AWS Lake Formation que utilicen Trusted Identity Propagation deberán actualizar la configuración del centro de identidad de Lake Formation añadiendo la aplicación de identidad de IAM gestionada por EMR arn como objetivo autorizado. Puede encontrar el ARN de la aplicación administrada por IAM para Amazon EMR mediante la API de EMR describe-security-configuration 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.

  • Para usar los controles de Fine-grained acceso AWS Lake Formation que utilizan 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.

  • La propagación de identidades confiables 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 para el rol de centro de identidad se elimina y se vuelve a crear accidentalmente, el principal tendrá un identificador principal diferente. El ejemplo NewRole tendría un identificador principal que no coincidiría con el identificador principal 456 registrado. 123 La única forma de resolver este problema en este momento es restablecer el principal de las políticas de recursos descendentes en cada cuenta descendente.