Accès aux données S3 dans un autre AWS compte depuis EMR Serverless - Amazon EMR
PrérequisUtiliser une politique de compartiment S3Utiliser un rôle assuméExemples de rôles supposés

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accès aux données S3 dans un autre AWS compte depuis EMR Serverless

Vous pouvez exécuter des tâches Amazon EMR Serverless à partir d'un AWS et configurez-les pour accéder aux données contenues dans des compartiments Amazon S3 appartenant à un autre AWS . Cette page décrit comment configurer l'accès entre comptes à S3 depuis EMR Serverless.

Les tâches exécutées sur EMR Serverless peuvent utiliser une politique de compartiment S3 ou un rôle assumé pour accéder aux données d'Amazon S3 à partir d'un autre AWS .

Prérequis

Pour configurer l'accès entre comptes pour Amazon EMR Serverless, vous devez effectuer des tâches en étant connecté à deux AWS comptes :

  • AccountA— C'est le AWS compte sur lequel vous avez créé une application Amazon EMR Serverless. Avant de configurer l'accès entre comptes, vous devez disposer des éléments suivants sur ce compte :

    • Une application Amazon EMR Serverless dans laquelle vous souhaitez exécuter des tâches.

    • Rôle d'exécution de tâches disposant des autorisations requises pour exécuter des tâches dans l'application. Pour de plus amples informations, veuillez consulter Rôles d'exécution des tâches pour Amazon EMR Serverless.

  • AccountB— C'est le AWS compte contenant le compartiment S3 auquel vous souhaitez que vos tâches Amazon EMR Serverless accèdent.

Utiliser une politique de compartiment S3 pour accéder aux données S3 entre comptes

Pour accéder au compartiment S3 dans account B from account A, attachez la politique suivante au compartiment S3 dans account B.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Sid": "Example permissions 1",
         "Effect": "Allow",
         "Principal": {
            "AWS": "arn:aws:iam::AccountA:root"
         },
         "Action": [
            "s3:ListBucket"
         ],
         "Resource": [
            "arn:aws:s3:::bucket_name_in_AccountB"
         ]
      },
      {
         "Sid": "Example permissions 2",
         "Effect": "Allow",
         "Principal": {
            "AWS": "arn:aws:iam::AccountA:root"
         },
         "Action": [
            "s3:PutObject",
            "s3:GetObject",
            "s3:DeleteObject"
         ],
         "Resource": [
            "arn:aws:s3:::bucket_name_in_AccountB/*"
         ]
      }
   ]
}

Pour plus d'informations sur l'accès entre comptes S3 avec les politiques relatives aux compartiments S3, consultez l'exemple 2 : le propriétaire du compartiment accorde des autorisations de compartiment entre comptes dans le guide de l'utilisateur d'Amazon Simple Storage Service.

Utiliser un rôle assumé pour accéder aux données S3 entre comptes

Une autre méthode pour configurer l'accès entre comptes pour Amazon EMR Serverless consiste à utiliser l'AssumeRoleaction du AWS Security Token Service (AWS STS). AWS STS est un service Web mondial qui vous permet de demander des informations d'identification temporaires à privilèges limités pour les utilisateurs. Vous pouvez API passer des appels vers EMR Serverless et Amazon S3 avec les informations d'identification de sécurité temporaires que vous avez créées avecAssumeRole.

Les étapes suivantes illustrent comment utiliser un rôle assumé pour accéder aux données S3 entre comptes depuis EMR Serverless :

  1. Créez un compartiment Amazon S3, cross-account-bucket, dansAccountB. Pour plus d'informations, consultez la section Création d'un compartiment dans le guide de l'utilisateur d'Amazon Simple Storage Service. 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 la section Création d'une table DynamoDB dans le manuel Amazon DynamoDB Developer Guide.

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

    1. Connectez-vous au AWS Management Console et ouvrez la IAM console à l'adresse https://console.aws.amazon.com/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 IAM rôles, consultez la section Création de IAM rôles dans le Guide de IAM l'utilisateur.

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

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

    Si vous avez besoin d'un accès DynamoDB, créez IAM une politique qui spécifie les autorisations d'accès à la table DynamoDB multicomptes. Attachez ensuite la IAM politique àCross-Account-Role-B. Pour plus d'informations, consultez Amazon DynamoDB : autorise l'accès à une table spécifique dans IAM le guide de l'utilisateur.

    Voici une politique permettant d'autoriser l'accès à la table DynamoDBCrossAccountTable.

    {
"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 pour le rôle, choisissez l'onglet Relations de confiance dans la IAM console pour le rôle Cross-Account-Role-B que vous avez créé à l'étape 2.

    2. Sélectionnez Modifier la relation de confiance.

    3. Ajoutez le document de politique suivant. Cela permet AccountA à Job-Execution-Role-A in d'assumer le Cross-Account-Role-B rôle.

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

  4. Subvention Job-Execution-Role-A dans AccountA le AWS STS AssumeRoleautorisation d'assumerCross-Account-Role-B.

    1. Dans la IAM console pour AWS compteAccountA, sélectionnezJob-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"
        }
    ]
}

Exemples de rôles supposés

Vous pouvez utiliser un seul rôle assumé pour accéder à toutes les ressources S3 d'un compte, ou avec Amazon EMR 6.11 et versions ultérieures, vous pouvez configurer plusieurs IAM rôles à assumer lorsque vous accédez à différents compartiments S3 entre comptes.

Accédez aux ressources S3 avec un rôle assumé

Note

Lorsque vous configurez une tâche pour utiliser un seul rôle assumé, toutes les ressources S3 de la tâche utilisent ce rôle, y compris le entryPoint script.

Si vous souhaitez utiliser un seul rôle assumé pour accéder à toutes les ressources S3 du compte B, spécifiez les configurations suivantes :

  1. Spécifiez EMRFS la configuration fs.s3.customAWSCredentialsProvider àspark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider.

  2. Pour Spark, utilisez spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN et spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN pour spécifier les variables d'environnement sur le pilote et les exécuteurs.

  3. Pour Hive, utilisez hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARNtez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN, et pour spécifier les variables tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN d'environnement sur le pilote Hive, le maître d'application Tez et les conteneurs de tâches Tez.

Les exemples suivants montrent comment utiliser un rôle assumé pour démarrer une tâche EMR sans serveur exécutée avec un accès entre comptes.

Spark

L'exemple suivant montre comment utiliser un rôle assumé pour démarrer une tâche Spark EMR sans serveur exécutée avec un accès multicompte à S3.

aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "entrypoint_location",
            "entryPointArguments": [":argument_1:", ":argument_2:"],
            "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
        }
    }' \
     --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "spark-defaults",
            "properties": {
                "spark.hadoop.fs.s3.customAWSCredentialsProvider": "spark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.emr.AssumeRoleAWSCredentialsProvider",
                "spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
            }
        }]
    }'
Hive

L'exemple suivant montre comment utiliser un rôle assumé pour démarrer une tâche EMR Serverless Hive exécutée avec un accès multicompte à S3.

aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "hive": {
            "query": "query_location",
            "parameters": "hive_parameters"
        }
    }' \
    --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "hive-site",
            "properties": {
                "fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
                "hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
                "tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
            }
        }]
    }'

Accédez aux ressources S3 avec plusieurs rôles assumés

Avec les versions 6.11.0 et supérieures EMR sans serveur, vous pouvez configurer plusieurs IAM rôles à assumer lorsque vous accédez à différents buckets multicomptes. Si vous souhaitez accéder à différentes ressources S3 avec différents rôles assumés dans le compte B, utilisez les configurations suivantes lorsque vous démarrez l'exécution de la tâche :

  1. Spécifiez EMRFS la configuration fs.s3.customAWSCredentialsProvider àcom.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider.

  2. Spécifiez la EMRFS configuration fs.s3.bucketLevelAssumeRoleMapping pour définir le mappage entre le nom du compartiment S3 et le IAM rôle à assumer dans le compte B. La valeur doit être au format debucket1->role1;bucket2->role2.

Par exemple, vous pouvez utiliser arn:aws:iam::AccountB:role/Cross-Account-Role-B-1 pour accéder au bucket bucket1 et utiliser arn:aws:iam::AccountB:role/Cross-Account-Role-B-2 pour accéder au bucketbucket2. Les exemples suivants montrent comment démarrer une tâche EMR sans serveur exécutée avec un accès entre comptes via plusieurs rôles assumés.

Spark

L'exemple suivant montre comment utiliser plusieurs rôles assumés pour créer une exécution de tâche Spark EMR sans serveur.

aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "entrypoint_location",
            "entryPointArguments": [":argument_1:", ":argument_2:"],
            "sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
        }
    }' \
     --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "spark-defaults",
            "properties": {
                "spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider",
                "spark.hadoop.fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
            }
        }]
    }'
Hive

Les exemples suivants montrent comment utiliser plusieurs rôles assumés pour créer une exécution de tâche EMR Serverless Hive.

aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "hive": {
            "query": "query_location",
            "parameters": "hive_parameters"
        }
    }' \
    --configuration-overrides '{
        "applicationConfiguration": [{
            "classification": "hive-site",
            "properties": {
                "fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
                "fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
            }
        }]
    }'