

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.

# Rôles d'exécution pour les étapes Amazon EMR
<a name="emr-steps-runtime-roles"></a>

Un *rôle d'exécution* est un rôle Gestion des identités et des accès AWS (IAM) que vous pouvez spécifier lorsque vous soumettez une tâche ou une requête à un cluster Amazon EMR. La tâche ou la requête que vous soumettez à votre cluster Amazon EMR utilise le rôle d'exécution pour accéder à AWS des ressources, telles que des objets dans Amazon S3. Vous pouvez spécifier des rôles d'exécution avec Amazon EMR pour les tâches Spark et Hive.

Vous pouvez également spécifier des rôles d'exécution lorsque vous vous connectez à des clusters Amazon EMR dans Amazon SageMaker AI et lorsque vous attachez un espace de travail Amazon EMR Studio à un cluster EMR. Pour plus d'informations, consultez [Se connecter à un cluster Amazon EMR depuis SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/connect-emr-clusters.html) et. [Exécuter un Workspace EMR Studio avec un rôle d'exécution](emr-studio-runtime.md)

Auparavant, les clusters Amazon EMR exécutaient des tâches ou des requêtes Amazon EMR avec des autorisations basées sur la politique IAM attachée au profil d'instance que vous utilisiez pour lancer le cluster. Cela signifiait que les politiques devaient contenir l'union de toutes les autorisations pour toutes les tâches et requêtes exécutées sur un cluster Amazon EMR. Avec les rôles d'exécution, vous pouvez désormais gérer le contrôle d'accès pour chaque tâche ou requête individuellement, au lieu de partager le profil d'instance Amazon EMR du cluster.

Sur les clusters Amazon EMR dotés de rôles d'exécution, vous pouvez également appliquer un contrôle d'accès AWS Lake Formation basé aux tâches et requêtes Spark, Hive et Presto concernant vos lacs de données. Pour en savoir plus sur la façon de procéder à l'intégration à AWS Lake Formation, voir[Intégrez Amazon EMR à AWS Lake Formation](emr-lake-formation.md).

**Note**  
Lorsque vous spécifiez un rôle d'exécution pour une étape Amazon EMR, les tâches ou requêtes que vous soumettez ne peuvent accéder qu'aux AWS ressources autorisées par les politiques associées au rôle d'exécution. Ces tâches et requêtes ne peuvent pas accéder au service de métadonnées d'instance sur les instances EC2 du cluster ni utiliser le profil d'instance EC2 du cluster pour accéder aux ressources AWS . 

## Conditions préalables au lancement d'un cluster Amazon EMR doté d'un rôle d'exécution
<a name="emr-steps-runtime-roles-configure"></a>

**Topics**
+ [Étape 1 : Configurer la sécurité dans Amazon EMR](#configure-security)
+ [Étape 2 : Configurer un profil d'instance EC2 pour le cluster Amazon EMR](#configure-ec2-profile)
+ [Étape 3 : Configurer une politique d'approbation](#configure-trust-policy)

### Étape 1 : Configurer la sécurité dans Amazon EMR
<a name="configure-security"></a>

Utilisez la structure JSON suivante pour créer une configuration de sécurité sur le AWS Command Line Interface (AWS CLI), et définissez `EnableApplicationScopedIAMRole` sur`true`. Pour plus d'informations sur les configurations de sécurité, consultez [Utiliser les configurations de sécurité pour configurer la sécurité du cluster Amazon EMR](emr-security-configurations.md).

```
{
    "AuthorizationConfiguration":{
        "IAMConfiguration":{
            "EnableApplicationScopedIAMRole":true
        }
    }
}
```

Nous vous recommandons de toujours activer les options de chiffrement en transit dans la configuration de sécurité, afin que les données transférées sur Internet soient chiffrées, plutôt qu'en texte brut. Vous pouvez ignorer ces options si vous ne souhaitez pas vous connecter aux clusters Amazon EMR avec des rôles d'exécution issus de SageMaker Runtime Studio ou EMR Studio. Pour configurer le chiffrement des données, consultez [Configuration du chiffrement des données](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-create-security-configuration.html#emr-security-configuration-encryption).

Vous pouvez également créer une configuration de sécurité avec des paramètres personnalisés à l'aide de la [AWS Management Console](https://console.aws.amazon.com/emr/home#/securityConfigs).

### Étape 2 : Configurer un profil d'instance EC2 pour le cluster Amazon EMR
<a name="configure-ec2-profile"></a>

Les clusters Amazon EMR utilisent le rôle de profil d'instance Amazon EC2 pour assumer les rôles d'exécution. Pour utiliser des rôles d'exécution avec les étapes Amazon EMR, ajoutez les politiques suivantes au rôle IAM que vous prévoyez d'utiliser comme rôle de profil d'instance. Pour ajouter des politiques à un rôle IAM ou modifier une politique en ligne ou gérée existante, consultez [Ajout et suppression d'autorisations d'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowRuntimeRoleUsage",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/EMRRuntimeRole"
      ]
    }
  ]
}
```

------

### Étape 3 : Configurer une politique d'approbation
<a name="configure-trust-policy"></a>

Pour chaque rôle IAM que vous prévoyez d'utiliser comme rôle d'exécution, définissez la politique d'approbation suivante, en remplaçant `EMR_EC2_DefaultRole` par votre rôle de profil d'instance. Pour modifier la politique d'approbation d'un rôle IAM, consultez [Modification d'une politique d'approbation de rôle](https://docs.aws.amazon.com//IAM/latest/UserGuide/roles-managingrole-editing-console.html).

```
{
    "Sid":"AllowAssumeRole",
    "Effect":"Allow",
    "Principal":{
        "AWS":"arn:aws:iam::{{<AWS_ACCOUNT_ID>}}:role/EMR_EC2_DefaultRole"
    },
    "Action":[
             "sts:AssumeRole",
             "sts:TagSession"
            ]
}
```

## Lancement d'un cluster Amazon EMR avec un contrôle d'accès basé sur les rôles
<a name="emr-steps-runtime-roles-launch"></a>

Après avoir mis en place vos configurations, vous pouvez lancer un cluster Amazon EMR avec la configuration de sécurité depuis [Étape 1 : Configurer la sécurité dans Amazon EMR](#configure-security). Pour utiliser des rôles d'exécution avec les étapes d'Amazon EMR, utilisez l'étiquette de version `emr-6.7.0` ou une version ultérieure, et sélectionnez Hive, Spark ou les deux comme application de cluster. CloudWatchAgent est pris en charge sur les clusters de rôles d'exécution pour EMR 7.6 et versions ultérieures. Pour vous connecter depuis SageMaker AI Studio, utilisez release `emr-6.9.0` ou version ultérieure et sélectionnez Livy, Spark, Hive ou Presto comme application de cluster. Pour savoir comment mettre à jour votre cluster, consultez [Spécifier une configuration de sécurité pour un cluster Amazon EMR](emr-specify-security-configuration.md).

### Soumission de tâches Spark à l'aide des étapes d'Amazon EMR
<a name="launch-spark"></a>

Voici un exemple d'exécution de l' HdfsTest exemple inclus dans Apache Spark. Cet appel d'API ne réussit que si le rôle d'exécution Amazon EMR fourni peut accéder à `S3_LOCATION`.

```
RUNTIME_ROLE_ARN={{<runtime-role-arn>}}
S3_LOCATION={{<s3-path>}}
REGION={{<aws-region>}}
CLUSTER_ID={{<cluster-id>}}

aws emr add-steps --cluster-id $CLUSTER_ID \
--steps '[{ "Name": "Spark Example", "ActionOnFailure": "CONTINUE", "Jar":"command-runner.jar","Args" : ["spark-example","HdfsTest", "$S3_LOCATION"] }]' \
--execution-role-arn $RUNTIME_ROLE_ARN \
--region $REGION
```

**Note**  
Nous vous recommandons de désactiver l'accès SSH au cluster Amazon EMR et d'autoriser uniquement l'API Amazon EMR `AddJobFlowSteps` à accéder au cluster.

### Soumission de tâches Hive à l'aide des étapes d'Amazon EMR
<a name="launch-hive"></a>

L'exemple suivant utilise Apache Hive avec les étapes Amazon EMR pour soumettre une tâche afin d'exécuter le fichier `QUERY_FILE.hql`. Cette requête n'aboutit que si le rôle d'exécution fourni peut accéder au chemin Amazon S3 du fichier de requête.

```
RUNTIME_ROLE_ARN={{<runtime-role-arn>}}
REGION={{<aws-region>}}
CLUSTER_ID={{<cluster-id>}}

aws emr add-steps --cluster-id $CLUSTER_ID \
--steps '[{ "Name": "Run hive query using command-runner.jar - simple select","ActionOnFailure":"CONTINUE", "Jar": "command-runner.jar","Args" :["hive -
f","s3://{{DOC_EXAMPLE_BUCKET}}/QUERY_FILE.hql"] }]' \
--execution-role-arn $RUNTIME_ROLE_ARN \
--region $REGION
```

### Connectez-vous aux clusters Amazon EMR avec des rôles d'exécution depuis un bloc-notes SageMaker AI Studio
<a name="sagemaker"></a>

Vous pouvez appliquer des rôles d'exécution Amazon EMR aux requêtes que vous exécutez dans des clusters Amazon EMR depuis AI Studio. SageMaker Pour ce faire, suivez les étapes suivantes.

1. Suivez les instructions de la [section Lancer Amazon SageMaker AI Studio]() pour créer un studio SageMaker AI.

1. Dans l'interface utilisateur d' SageMaker AI Studio, démarrez un bloc-notes avec des noyaux pris en charge. Par exemple, démarrez une SparkMagic image avec un PySpark noyau.

1. **Choisissez un cluster Amazon EMR dans SageMaker AI Studio, puis sélectionnez Connect.**

1. Choisissez un rôle d'exécution, puis sélectionnez **Connecter**. 

Cela créera une cellule de bloc-notes SageMaker IA avec des commandes magiques pour se connecter à votre cluster Amazon EMR avec le rôle d'exécution Amazon EMR choisi. Dans la cellule du bloc-notes, vous pouvez saisir et exécuter des requêtes avec un rôle d'exécution et un contrôle d'accès basé sur Lake Formation. Pour un exemple plus détaillé, consultez [Appliquer des contrôles d'accès aux données précis avec AWS Lake Formation Amazon EMR depuis Amazon SageMaker ](https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-data-access-controls-with-aws-lake-formation-and-amazon-emr-from-amazon-sagemaker-studio) AI Studio.

### Contrôle de l'accès au rôle d'exécution Amazon EMR
<a name="role-access"></a>

Vous pouvez contrôler l'accès au rôle d'exécution à l'aide de la clé de condition `elasticmapreduce:ExecutionRoleArn`. La politique suivante permet à un principal IAM d'utiliser un rôle IAM nommé `Caller`, ou tout autre rôle IAM commençant par la chaîne `CallerTeamRole`, comme rôle d'exécution.

**Important**  
Vous devez créer une condition basée sur la clé de contexte `elasticmapreduce:ExecutionRoleArn` lorsque vous autorisez un appelant à appeler les API `AddJobFlowSteps` ou `GetClusterSessionCredentials`, comme le montre l'exemple suivant.

```
{
    "Sid":"AddStepsWithSpecificExecRoleArn",
    "Effect":"Allow",
    "Action":[
        "elasticmapreduce:AddJobFlowSteps"
    ],
    "Resource":"*",
    "Condition":{
        "StringEquals":{
            "elasticmapreduce:ExecutionRoleArn":[
                "arn:aws:iam::{{<AWS_ACCOUNT_ID>}}:role/Caller"
            ]
        },
        "StringLike":{
            "elasticmapreduce:ExecutionRoleArn":[
                "arn:aws:iam::{{<AWS_ACCOUNT_ID>}}:role/CallerTeamRole*"
            ]
        }
    }
}
```

### Établir la confiance entre les rôles d'exécution et les clusters Amazon EMR
<a name="external-id"></a>

Amazon EMR génère un identifiant unique `ExternalId` pour chaque configuration de sécurité avec une autorisation de rôle d'exécution activée. Cette autorisation permet à chaque utilisateur de posséder un ensemble de rôles d'exécution à utiliser sur les clusters qui lui appartiennent. Par exemple, dans une entreprise, chaque service peut utiliser son identifiant externe pour mettre à jour la politique d'approbation relative à son propre ensemble de rôles d'exécution.

Vous pouvez trouver l'ID externe avec l'API Amazon EMR `DescribeSecurityConfiguration`, comme illustré dans l'exemple suivant.

```
aws emr describe-security-configuration --name 'iamconfig-with-lf'{"Name": "iamconfig-with-lf",
    "SecurityConfiguration":
        "{\"AuthorizationConfiguration\":{\"IAMConfiguration\":{\"EnableApplicationScopedIAMRole\
        ":true,\"ApplicationScopedIAMRoleConfiguration\":{\"PropagateSourceIdentity\":true,\"Exter
        nalId\":\"FXH5TSACFDWUCDSR3YQE2O7ETPUSM4OBCGLYWODSCUZDNZ4Y\"}},\"Lake
        FormationConfiguration\":{\"AuthorizedSessionTagValue\":\"Amazon EMR\"}}}",
    "CreationDateTime": "2022-06-03T12:52:35.308000-07:00"
}
```

Pour plus d'informations sur l'utilisation d'un identifiant externe, voir [Comment utiliser un identifiant externe lorsque vous accordez l'accès à vos AWS ressources à un tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). 

### Audit
<a name="audit-source-identity"></a>

Pour surveiller et contrôler les actions que les utilisateurs finaux effectuent avec les rôles IAM, vous pouvez activer la fonctionnalité d'identité source. Pour en savoir plus sur l'identité source, consultez [Surveiller et contrôler les actions prises avec les rôles endossés](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor).

Pour suivre l'identité source, `ApplicationScopedIAMRoleConfiguration/PropagateSourceIdentity` `true` configurez-la dans votre configuration de sécurité, comme suit.

```
{
    "AuthorizationConfiguration":{
        "IAMConfiguration":{
            "EnableApplicationScopedIAMRole":true,
            "ApplicationScopedIAMRoleConfiguration":{
                "PropagateSourceIdentity":true
            }
        }
    }
}
```

Lorsque vous définissez `PropagateSourceIdentity` sur `true`, Amazon EMR applique l'identité source des informations d'identification d'appel à une tâche ou à une session de requête que vous créez avec le rôle d'exécution. Si aucune identité source n'est présente dans les informations d'identification d'appel, Amazon EMR ne définit pas l'identité source.

Pour utiliser cette propriété, accordez des autorisations `sts:SetSourceIdentity` à votre profil d'instance, comme suit.

```
{ // PropagateSourceIdentity statement
    "Sid":"PropagateSourceIdentity",
    "Effect":"Allow",
    "Action":"sts:SetSourceIdentity",
    "Resource":[
        {{<runtime-role-ARN>}}
    ],
    "Condition":{
        "StringEquals":{
            "sts:SourceIdentity":{{<source-identity>}}
        }
    }
}
```

Vous devez également ajouter l'instruction `AllowSetSourceIdentity` à la politique d'approbation de vos rôles d'exécution.

```
{ // AllowSetSourceIdentity statement
    "Sid":"AllowSetSourceIdentity",
    "Effect":"Allow",
    "Principal":{
        "AWS":"arn:aws:iam::{{<AWS_ACCOUNT_ID>}}:role/EMR_EC2_DefaultRole"
    },
    "Action":[
        "sts:SetSourceIdentity",
        "sts:AssumeRole"
    ],
    "Condition":{
        "StringEquals":{
            "sts:SourceIdentity":{{<source-identity>}}
        }
    }
}
```

## Considérations supplémentaires
<a name="emr-steps-runtime-roles-considerations"></a>

**Note**  
Avec la version Amazon EMR`emr-6.9.0`, vous risquez de rencontrer des pannes intermittentes lorsque vous vous connectez à des clusters Amazon EMR depuis AI Studio. SageMaker Pour résoudre ce problème, vous pouvez installer le correctif avec une action de démarrage lorsque vous lancez le cluster. Pour plus de détails sur le correctif, consultez [Problèmes connus de la version 6.9.0 d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-690-release.html#emr-690-relnotes).

Tenez également compte des éléments suivants lorsque vous configurez les rôles d'exécution pour Amazon EMR.
+ Amazon EMR prend en charge les rôles d'exécution dans toutes les Régions AWS commerciales.
+ Les étapes Amazon EMR prennent en charge les tâches Apache Spark et Apache Hive avec des rôles d'exécution lorsque vous utilisez la version `emr-6.7.0` ou une version ultérieure.
+ SageMaker AI Studio prend en charge les requêtes Spark, Hive et Presto avec des rôles d'exécution lorsque vous utilisez release `emr-6.9.0` ou version ultérieure. 
+ Les noyaux de bloc-notes suivants dans SageMaker AI prennent en charge les rôles d'exécution :
  + DataScience — Noyau Python 3
  + DataScience 2.0 — Noyau Python 3
  + DataScience 3.0 — Noyau Python 3
  + SparkAnalytics 1.0 — SparkMagic et PySpark noyaux
  + SparkAnalytics 2.0 — SparkMagic et PySpark noyaux
  + SparkMagic — PySpark noyau
+ Amazon EMR prend en charge les étapes qui utilisent `RunJobFlow` uniquement au moment de la création du cluster. Cette API ne prend pas en charge les rôles d'exécution.
+ Amazon EMR ne prend pas en charge les rôles d'exécution sur les clusters que vous configurez pour être hautement disponibles. 
+ À partir de la version 7.5.0 d'Amazon EMR et des versions ultérieures, les rôles d'exécution prennent en charge l'affichage des interfaces utilisateur (UI) Spark et YARN, telles que les suivantes : interface utilisateur Spark Live, Spark History Server NodeManager, YARN et YARN. ResourceManager Lorsque vous accédez à ces interfaces utilisateur, un nom d'utilisateur et un mot de passe vous sont demandés. Les noms d'utilisateur et les mots de passe peuvent être générés à l'aide de l'API GetClusterSessionCredentials EMR. Pour plus d'informations sur les détails d'utilisation de l'API, consultez [GetClusterSessionCredentials](https://docs.aws.amazon.com/emr/latest/APIReference/API_GetClusterSessionCredentials.html).

  Voici un exemple d'utilisation de l' GetClusterSessionCredentials API EMR :

  ```
  aws emr  get-cluster-session-credentials --cluster-id {{<cluster_ID>}} --execution-role-arn {{<IAM_role_arn>}}
  ```
+ Vous devez échapper à vos arguments de commande Bash lorsque vous exécutez des commandes avec le fichier `command-runner.jar` JAR :

  ```
  aws emr add-steps --cluster-id {{<cluster-id>}} --steps '[{"Name":"sample-step","ActionOnFailure":"CONTINUE","Jar":"command-runner.jar","Properties":"","Args":["bash","-c","\"aws s3 ls\""],"Type":"CUSTOM_JAR"}]' --execution-role-arn {{<IAM_ROLE_ARN>}}
  ```

  En outre, vous devez échapper à vos arguments de commande Bash lorsque vous exécutez des commandes avec le lanceur de script. Voici un exemple qui montre comment définir les propriétés de Spark, avec des caractères d'échappement inclus :

  ```
  "\"--conf spark.sql.autoBroadcastJoinThreshold=-1\""
  ```
+ Les rôles d'exécution ne permettent pas de contrôler l'accès aux ressources du cluster, telles que HDFS et HMS.
+ Les rôles d'exécution ne fournissent pas de support pour docker/containers.