Accès aux données S3 depuis 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 depuis un autre AWS compte depuis EMR Serverless

Vous pouvez exécuter des tâches Amazon EMR Serverless à partir d'un AWS compte et les configurer pour accéder aux données des compartiments Amazon S3 appartenant à un autre compte. 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 dans Amazon S3 à partir d'un autre compte. AWS

Prérequis

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

  • AccountA— Il s'agit du AWS compte sur lequel vous avez créé une application Amazon EMR Serverless. Avant de configurer l'accès entre comptes, préparez les éléments suivants dans 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 plus d’informations, consultez Rôles d'exécution des tâches pour Amazon EMR Serverless.

  • AccountB— Il s'agit du AWS compte qui contient 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 account B depuisaccount A, attachez la politique suivante au compartiment S3 depuisaccount B.

JSON
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "ExamplePermissions1",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket-name"
      ]
    },
    {
      "Sid": "ExamplePermissions2",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket-name/*"
      ]
    }
  ]
}

Pour plus d'informations sur l'accès entre comptes S3 avec les politiques relatives aux compartiments S3, reportez-vous à 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 AssumeRole l'action 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 effectuer des appels d'API vers EMR Serverless et Amazon S3 à l'aide des informations d'identification de sécurité temporaires que vous avez créées avec. AssumeRole

Les étapes suivantes montrent 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, dans AccountB. Pour plus d'informations, reportez-vous à 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 multicompte à DynamoDB, créez également une table DynamoDB dans. AccountB Pour plus d'informations, reportez-vous à la section Création d'une table DynamoDB dans le manuel du développeur Amazon 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 AWS Management Console et ouvrez-la à https://console.aws.amazon.com/iam/l'adresse.

    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, reportez-vous à la section 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, reportez-vous à la section Création de politiques IAM dans le Guide de l'utilisateur IAM.

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

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

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

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

  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 console IAM 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.

      JSON
      {
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": "arn:aws:iam::123456789012:role/Job-Execution-Role-A",
      "Sid": "AllowSTSAssumerole"
    }
  ]
}

  4. Accordez Job-Execution-Role-A AccountA l' AWS STS AssumeRoleautorisation d'assumerCross-Account-Role-B.

    1. Dans la console IAM du 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.

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

Exemples de rôles supposés

Utilisez 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, configurez plusieurs rôles IAM à 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 la configuration fs.s3.customAWSCredentialsProvider EMRFS à. 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, l'application principale 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 EMR Serverless Spark 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": "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 d'EMR Serverless, configurez plusieurs rôles IAM à 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 la configuration fs.s3.customAWSCredentialsProvider EMRFS à. com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider

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

Par exemple, utilisez arn:aws:iam::AccountB:role/Cross-Account-Role-B-1 pour accéder au bucket bucket1 et utilisez 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 tâche EMR Serverless Spark exécutée.

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 tâche EMR Serverless Hive exécutée.

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