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 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.
Créez un compartiment Amazon S3,
cross-account-bucket
, dansAccountB
. 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 dansAccountB
. Pour plus d'informations, consultez Création d'une table DynamoDB.Créez un rôle IAM
Cross-Account-Role-B
dans leAccountB
qui peut accéder aucross-account-bucket
.Connectez-vous à la console IAM.
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.Créez une politique IAM qui spécifie les autorisations du
Cross-Account-Role-B
à accéder au compartiment S3cross-account-bucket
, comme le montre la déclaration de politique suivante. Attachez ensuite la politique IAM auCross-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" } ] }
Modifiez la relation de confiance du rôle
Cross-Account-Role-B
.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
.Sélectionnez Modifier la relation de confiance.
Ajoutez le document de politique suivant, qui permet à
Job-Execution-Role-A
dansAccountA
d'assumer ce rôleCross-Account-Role-B
.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
AccountA
:role/Job-Execution-Role-A" }, "Action": "sts:AssumeRole" } ] }
Accordez à
Job-Execution-Role-A
dansAccountA
l'autorisation d'assumer leCross-Account-Role-B
dans le cadre du rôle STS.Dans la console IAM du compte AWS
AccountA
, sélectionnezJob-Execution-Role-A
.Ajoutez la déclaration de politique générale suivante au rôle
Job-Execution-Role-A
pour autoriser l'actionAssumeRole
sur le rôleCross-Account-Role-B
.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::
AccountB
:role/Cross-Account-Role-B" } ] }
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 surAssumeRoleAWSCredentialsProvider
, EMRFS utilise le rôle correspondant que vous spécifiez avecASSUME_ROLE_CREDENTIALS_ROLE_ARN
au lieu du rôleJob-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 piloteenv
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
.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" }}}'