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.
# 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 entre comptes permet aux utilisateurs d'un AWS compte d'exécuter des tâches Amazon EMR sur EKS et d'accéder aux données sous-jacentes appartenant à AWS un autre compte.
## Conditions préalables
Pour configurer l'accès entre comptes pour Amazon EMR sur EKS, vous devez effectuer des tâches en étant connecté aux AWS comptes suivants :
+ `AccountA`‐ Un AWS compte sur lequel vous avez créé un cluster virtuel Amazon EMR sur EKS en enregistrant Amazon EMR avec un espace de noms sur un cluster EKS.
+ `AccountB`‐ Un AWS compte 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 AWS comptes avant de configurer l'accès entre comptes :
+ 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](creating-job-execution-role.md) et [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).
## 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 plus d’informations, consultez [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html). 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](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html).
1. 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.
1. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) dans le Guide de l'utilisateur IAM.
1. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) 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 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html) dans le Guide de l'utilisateur IAM.
Voici une politique d'accès à une table DynamoDB, `CrossAccountTable`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:us-east-1:*:table/CrossAccountTable"
],
"Sid": "AllowDYNAMODB"
}
]
}
```
------
1. 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`.
1. Sélectionnez **Modifier la relation de confiance**.
1. Ajoutez le document de politique suivant, qui permet à `Job-Execution-Role-A` dans `AccountA` d'assumer ce rôle `Cross-Account-Role-B`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSTSAssumerole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{123456789012}}:role/Job-Execution-Role-A"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. 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 AWS compte`AccountA`, sélectionnez`Job-Execution-Role-A`.
1. 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::*:role/Cross-Account-Role-B"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
1. 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`.
1. 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 --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" }}}'
```