Configuration de l'accès intercompte pour Amazon EMR on EKS

Vous pouvez configurer l'accès intercompte pour Amazon EMR on EKS. L'accès intercompte permet aux utilisateurs d'un compte AWS d'exécuter des tâches Amazon EMR on EKS et d'accéder aux données sous-jacentes appartenant à un autre compte AWS.

Prérequis

Pour configurer l'accès intercompte pour Amazon EMR on EKS, vous devez effectuer des tâches en étant connecté aux comptes AWS suivants :

• AccountA – Un compte AWS où vous avez créé un cluster virtuel Amazon EMR on EKS en enregistrant Amazon EMR avec un espace de noms sur un cluster EKS.

• AccountB – Un compte AWS contenant un compartiment Amazon S3 ou une table DynamoDB auxquels vous souhaitez que vos tâches Amazon EMR on EKS aient accès.

Vous devez disposer des éléments suivants dans vos comptes AWS avant de configurer l'accès intercompte :

• Un cluster virtuel Amazon EMR on EKS dans le AccountA où vous souhaitez exécuter des tâches.

• Un rôle d'exécution de tâches dans le AccountA qui dispose des autorisations nécessaires pour exécuter des tâches dans le cluster virtuel. Pour plus d'informations, consultez Création d'un rôle d'exécution des tâches et Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS.

Procédure d'accès à un compartiment Amazon S3 ou à une table DynamoDB intercompte

Pour configurer l'accès intercompte pour Amazon EMR on EKS, procédez comme suit.

1. Créez un compartiment Amazon S3, cross-account-bucket, dans AccountB. Pour de plus amples informations, veuillez consulter Créer un compartiment dans. Si vous souhaitez bénéficier d'un accès intercompte à DynamoDB, vous pouvez également créer une table DynamoDB dans AccountB. Pour plus d'informations, consultez Création d'une table DynamoDB.

2. Créez un rôle IAM Cross-Account-Role-B dans le AccountB qui peut accéder au cross-account-bucket.

   1. Connectez-vous à la console IAM.

   2. Choisissez Rôles et créez un nouveau rôle : Cross-Account-Role-B. Pour plus d'informations sur la création de rôles IAM, consultez Création de rôles IAM dans le Guide de l'utilisateur IAM.

   3. Créez une politique IAM qui spécifie les autorisations du Cross-Account-Role-B à accéder au compartiment S3 cross-account-bucket, comme le montre la déclaration de politique suivante. Attachez ensuite la politique IAM au Cross-Account-Role-B. Pour plus d'informations, consultez Création d'une nouvelle politique dans le Guide de l'utilisateur IAM.

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

      Si l'accès à DynamoDB est nécessaire, créez une politique IAM qui spécifie les autorisations d'accès à la table DynamoDB intercompte. Attachez ensuite la politique IAM au Cross-Account-Role-B. Pour plus d'informations, consultez Création d'une table DynamoDB dans le Guide de l'utilisateur IAM.

      Voici une politique d'accès à une table DynamoDB, CrossAccountTable.

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

3. Modifiez la relation de confiance du rôle Cross-Account-Role-B.

   1. Pour configurer la relation de confiance du rôle, choisissez l'onglet Relations de confiance dans la console IAM pour le rôle créé à l'étape 2 : Cross-Account-Role-B.

   2. Sélectionnez Modifier la relation de confiance.

   3. Ajoutez le document de politique suivant, qui permet à Job-Execution-Role-A dans AccountA d'assumer ce rôle 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. Accordez à Job-Execution-Role-A dans AccountA l'autorisation d'assumer le Cross-Account-Role-B dans le cadre du rôle STS.

   1. Dans la console IAM du compte AWS AccountA, sélectionnez Job-Execution-Role-A.

   2. Ajoutez la déclaration de politique générale suivante au rôle Job-Execution-Role-A pour autoriser l'action AssumeRole sur le rôle 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. Pour accéder à Amazon S3, définissez les paramètres spark-submit suivants (spark conf) lors de la soumission de la tâche à Amazon EMR on EKS.

   Note

   Par défaut, EMRFS utilise le rôle d'exécution de la tâche pour accéder au compartiment S3 à partir la tâche. Mais lorsque customAWSCredentialsProvider est défini sur AssumeRoleAWSCredentialsProvider, EMRFS utilise le rôle correspondant que vous spécifiez avec ASSUME_ROLE_CREDENTIALS_ROLE_ARN au lieu du rôle Job-Execution-Role-A pour l'accès à 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 \

   Note

   Vous devez définir ASSUME_ROLE_CREDENTIALS_ROLE_ARN à la fois pour l'exécuteur et le pilote env dans la configuration de la tâche Spark.

   Pour l'accès intercompte DynamoDB, vous devez configurer --conf spark.dynamodb.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider.

6. Exécutez la tâche Amazon EMR on EKS avec un accès intercompte, comme le montre l'exemple suivant.

   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" }}}'