Configurar el acceso entre cuentas de Amazon EMR en EKS

Puede configurar el acceso entre cuentas de Amazon EMR en EKS. El acceso entre cuentas permite a los usuarios de una cuenta de AWS ejecutar trabajos de Amazon EMR en EKS y acceder a los datos subyacentes que pertenecen a otra cuenta de AWS.

Requisitos previos

Para configurar el acceso entre cuentas para Amazon EMR en EKS, deberá completar tareas mientras tenga la sesión iniciada en las siguientes cuentas de AWS:

• AccountA: una cuenta de AWS en la que ha creado un clúster virtual de Amazon EMR en EKS mediante el registro de Amazon EMR con un espacio de nombres en un clúster de EKS.

• AccountB: una cuenta de AWS que contiene un bucket de Amazon S3 o una tabla de DynamoDB a la que desea que accedan sus trabajos de Amazon EMR en EKS.

Debe tener lo siguiente en sus cuentas de AWS antes de configurar el acceso entre cuentas:

• Un clúster virtual de Amazon EMR en EKS en la AccountA donde desee ejecutar los trabajos.

• Un rol de ejecución de trabajos de la AccountA que tiene los permisos necesarios para ejecutar trabajos en el clúster virtual. Para obtener más información, consulte Crear un rol de ejecución de trabajos y Uso de roles de ejecución de trabajos con Amazon EMR en EKS.

Cómo acceder a un bucket de Amazon S3 en diversas cuentas o a una tabla de DynamoDB

Para configurar el acceso entre cuentas de Amazon EMR en EKS, complete los siguientes pasos.

1. Cree un bucket de Amazon S3, cross-account-bucket, en la AccountB. Para obtener más información, consulte Creating a bucket (Creación de un bucket). Si desea tener acceso entre cuentas a DynamoDB, también puede crear una tabla de DynamoDB en la AccountB. Para obtener más información, consulte Creación de una tabla de DynamoDB.

2. Cree un rol de IAM Cross-Account-Role-B en la AccountB que pueda acceder a cross-account-bucket.

   1. Inicie sesión en la consola de IAM.

   2. Elija Roles y, a continuación, cree un nuevo rol: Cross-Account-Role-B. Para obtener más información acerca de cómo crear un rol de IAM, consulte Creación de roles de IAM en la Guía del usuario de IAM.

   3. Cree una política de IAM que especifique los permisos del Cross-Account-Role-B para acceder al bucket de S3 cross-account-bucket, tal como se muestra en la siguiente instrucción de política. Adjunte la política de IAM al Cross-Account-Role-B. Para obtener más información, consulte Creación de una política nueva en la Guía del usuario de IAM.

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "s3:*",
                  "Resource": [
                      "arn:aws:s3:::cross-account-bucket",
                      "arn:aws:s3:::cross-account-bucket/*"
                  ]
              }
          ]
      }

      Si se requiere acceso a DynamoDB, cree una política de IAM que especifique los permisos para acceder a la tabla de DynamoDB entre cuentas. Adjunte la política de IAM al Cross-Account-Role-B. Para obtener más información, consulte Creación de una tabla de DynamoDB en la Guía del usuario de IAM.

      A continuación se presenta una política para acceder a una tabla de DynamoDB, CrossAccountTable.

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "dynamodb:*",
                  "Resource": "arn:aws:dynamodb:MyRegion:AccountB:table/CrossAccountTable"
              }
          ]
      }

3. Edite la relación de confianza del rol Cross-Account-Role-B.

   1. Para configurar la relación de confianza del rol, elija la pestaña Relaciones de confianza en la consola de IAM para el rol creado en el paso 2: Cross-Account-Role-B.

   2. Seleccione Editar la relación de confianza.

   3. Agregue el siguiente documento de política, que permite al Job-Execution-Role-A de la AccountA asumir este rol Cross-Account-Role-B.

      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": "arn:aws:iam::AccountA:role/Job-Execution-Role-A"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }

4. Otorgue al Job-Execution-Role-A de la AccountA el permiso de asunción de roles de STS para asumir el rol Cross-Account-Role-B.

   1. En la consola de IAM de la cuenta de AWS AccountA, seleccione Job-Execution-Role-A.

   2. Agregue la siguiente instrucción de política al Job-Execution-Role-A para denegar la acción AssumeRole en el rol Cross-Account-Role-B.

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "sts:AssumeRole",
                  "Resource": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
              }
          ]
      }

5. Para acceder a Amazon S3, defina los siguientes parámetros spark-submit (spark conf) al enviar el trabajo a Amazon EMR en EKS.

   nota

   De forma predeterminada, EMRFS usa el rol de ejecución del trabajo para acceder al bucket de S3 desde el trabajo. Sin embargo, cuando customAWSCredentialsProvider se establece en AssumeRoleAWSCredentialsProvider, EMRFS utiliza el rol correspondiente que especifique con ASSUME_ROLE_CREDENTIALS_ROLE_ARN en lugar del Job-Execution-Role-A para el acceso a Amazon S3.

   • --conf spark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider

   • --conf spark.kubernetes.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN=arn:aws:iam::AccountB:role/Cross-Account-Role-B \

   • --conf spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN=arn:aws:iam::AccountB:role/Cross-Account-Role-B \

   nota

   Debe configurar ASSUME_ROLE_CREDENTIALS_ROLE_ARN para el env tanto de ejecutor como controlador en la configuración de trabajos de Spark.

   Para el acceso entre cuentas de DynamoDB, debe configurar --conf spark.dynamodb.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider.

6. Ejecute el trabajo de Amazon EMR en EKS con el acceso entre cuentas, tal como se muestra en el siguiente ejemplo.

   aws emr-containers start-job-run \
   --virtual-cluster-id 123456 \
   --name myjob \
   --execution-role-arn execution-role-arn \
   --release-label emr-6.2.0-latest \
   --job-driver '{"sparkSubmitJobDriver": {"entryPoint": "entryPoint_location", "entryPointArguments": ["arguments_list"], "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1 --conf spark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider --conf spark.kubernetes.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN=arn:aws:iam::AccountB:role/Cross-Account-Role-B --conf spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN=arn:aws:iam::AccountB:role/Cross-Account-Role-B"}} ' \
   --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED",  "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'