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.
# Identity and Access Management (IAM) dans Amazon EMR Serverless
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources Amazon EMR Serverless. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment EMR Serverless fonctionne avec IAM](security-iam-serverless.md)
+ [Utilisation de rôles liés à un service pour EMR Serverless](using-service-linked-roles.md)
+ [Rôles d'exécution des tâches pour Amazon EMR Serverless](security-iam-runtime-role.md)
+ [Exemples de politiques d'accès utilisateur pour EMR Serverless](security-iam-user-access-policies.md)
+ [Politiques de contrôle d'accès basées sur les balises](security-iam-TBAC.md)
+ [Exemples de politiques basées sur l'identité pour EMR Serverless](security-iam-id-based-policy-examples.md)
+ [Amazon EMR Serverless : mises à jour des politiques gérées AWS](#security-iam-awsmanpol-updates)
+ [Résolution des problèmes d'identité et d'accès sans serveur Amazon EMR](security_iam_troubleshoot.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes d'identité et d'accès sans serveur Amazon EMR](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Identity and Access Management (IAM) dans Amazon EMR Serverless](#security_iam_service-with-iam))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour EMR Serverless](security-iam-serverless.md#security_iam_id-based-policy-examples))
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle d'utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération d' AWS API AWS CLI ou d'API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment EMR Serverless fonctionne avec IAM
Avant d'utiliser IAM pour gérer l'accès à Amazon EMR Serverless, découvrez quelles fonctionnalités IAM peuvent être utilisées avec Amazon EMR Serverless.
**Utilisation des fonctionnalités IAM avec EMR Serverless**
| Fonctionnalité IAM | Support sans serveur Amazon EMR |
| --- | --- |
| [Politiques basées sur l’identité](#security-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security-iam-resource-based-policies) | Non |
| [Actions de politique](#security-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security-iam-id-based-policies-resources) | Oui |
| [Clés de condition d’une politique](#security-iam-id-based-policies-conditionkeys) | Non |
| [ACLs](#security-iam-acls) | Non |
| [ABAC (étiquettes dans les politiques)](#security-iam-tags) | Oui |
| [Informations d’identification temporaires](#security-iam-roles-tempcreds) | Oui |
| [Autorisations de principal](#security-iam-principal-permissions) | Oui |
| [Rôles du service](#security-iam-roles-service) | Non |
| [Rôles liés à un service](#security-iam-roles-service-linked) | Oui |
*Pour obtenir une vue d'ensemble de la façon dont EMR Serverless et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, reportez-vous aux [AWS services compatibles avec IAM dans le guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Politiques basées sur l'identité pour EMR Serverless
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l'identité pour EMR Serverless
Pour accéder à des exemples de politiques basées sur l'identité Amazon EMR Serverless, reportez-vous à. [Exemples de politiques basées sur l'identité pour EMR Serverless](security-iam-id-based-policy-examples.md)
## Politiques basées sur les ressources dans EMR Serverless
**Prend en charge les politiques basées sur les ressources :** non
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Actions stratégiques pour EMR Serverless
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
*Pour consulter la liste des actions EMR sans serveur, reportez-vous à la section [Actions, ressources et clés de condition pour Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) dans le Service Authorization Reference.*
Les actions de stratégie dans EMR Serverless utilisent le préfixe suivant avant l'action.
```
emr-serverless
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"emr-serverless:action1",
"emr-serverless:action2"
]
```
Pour accéder à des exemples de politiques basées sur l'identité Amazon EMR Serverless, reportez-vous à. [Exemples de politiques basées sur l'identité pour EMR Serverless](security-iam-id-based-policy-examples.md)
## Ressources relatives aux politiques relatives à l'EMR sans serveur
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
*Pour consulter la liste des types de ressources Amazon EMR Serverless et leurs ARNs, consultez la section [Ressources définies par Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-resources-for-iam-policies) dans le Service Authorization Reference.* Pour savoir quelles actions spécifient l'ARN de chaque ressource, reportez-vous à la section [Actions, ressources et clés de condition pour Amazon EMR](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) Serverless.
Pour accéder à des exemples de politiques basées sur l'identité Amazon EMR Serverless, reportez-vous à. [Exemples de politiques basées sur l'identité pour EMR Serverless](security-iam-id-based-policy-examples.md)
## Clés de conditions de politique pour EMR Serverless
**Support des clés d'état des politiques**
| | |
| --- |--- |
| Prend en charge les clés de condition de politique spécifiques au service | Non |
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
*Pour consulter la liste des clés de condition Amazon EMR Serverless et pour savoir quelles actions et ressources vous pouvez utiliser une clé de condition, reportez-vous à la section [Actions, ressources et clés de condition pour Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html) dans le Service Authorization Reference.*
Toutes les actions Amazon EC2 prennent en charge les clés de condition `aws:RequestedRegion` et `ec2:Region`. Pour plus d'informations, reportez-vous à [Exemple : restriction de l'accès à une région spécifique](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
## Listes de contrôle d'accès (ACLs) dans EMR Serverless
**Supports ACLs :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## Contrôle d'accès basé sur les attributs (ABAC) avec EMR Serverless
**Support du contrôle d'accès basé sur les attributs (ABAC)**
| | |
| --- |--- |
| Prend en charge ABAC (étiquettes dans les politiques) | Oui |
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation d'informations d'identification temporaires avec EMR Serverless
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Autorisations principales interservices pour EMR Serverless
**Prend en charge les sessions d’accès direct (FAS) :** oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour EMR Serverless
| | |
| --- |--- |
| Prend en charge les fonctions de service | Non |
## Rôles liés à un service pour EMR Serverless
| | |
| --- |--- |
| Prend en charge les rôles liés à un service. | Oui |
Pour plus de détails sur la création ou la gestion des rôles liés à un service, reportez-vous aux [AWS services qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Cliquez sur le lien **Oui** pour accéder à la documentation des rôles liés au service pour ce service.
# Utilisation de rôles liés à un service pour EMR Serverless
[Amazon EMR Serverless utilise des rôles liés à un service Gestion des identités et des accès AWS (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rôle lié à un service est un type unique de rôle IAM directement lié à EMR Serverless. Les rôles liés à un service sont prédéfinis par EMR Serverless et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service facilite la configuration d'EMR Serverless, car vous n'avez pas à ajouter manuellement les autorisations nécessaires. EMR Serverless définit les autorisations associées à ses rôles liés aux services et, sauf indication contraire, seul EMR Serverless peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Cela protège vos ressources EMR Serverless, car vous ne pouvez pas supprimer par inadvertance l'autorisation d'accès aux ressources.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés aux services, reportez-vous à la section [AWS Services qui fonctionnent avec IAM et recherchez](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) les services dont la valeur est **Oui** dans la colonne Rôles liés aux **services**. Cliquez sur **Oui** avec un lien pour accéder à la documentation des rôles liés au service correspondant à ce service.
## Autorisations de rôle liées à un service pour EMR Serverless
EMR Serverless utilise le rôle lié au service nommé **AWSServiceRoleForAmazonEMRServerless**pour lui permettre d'appeler en votre nom. AWS APIs
Le rôle AWSService RoleForAmazon EMRServerless lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `ops.emr-serverless.amazonaws.com`
La politique d'autorisations de rôle nommée `AmazonEMRServerlessServiceRolePolicy` permet à EMR Serverless d'effectuer les actions suivantes sur les ressources spécifiées.
**Note**
Le contenu des politiques gérées étant modifié, il est possible que la politique présentée ici ne soit plus à jour. Consultez la up-to-date politique la plus importante [d'Amazon EMRServerless ServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRServerlessServiceRolePolicy) dans le AWS Management Console.
+ Action : `ec2:CreateNetworkInterface`
+ Action : `ec2:DeleteNetworkInterface`
+ Action : `ec2:DescribeNetworkInterfaces`
+ Action : `ec2:DescribeSecurityGroups`
+ Action : `ec2:DescribeSubnets`
+ Action : `ec2:DescribeVpcs`
+ Action : `ec2:DescribeDhcpOptions`
+ Action : `ec2:DescribeRouteTables`
+ Action : `cloudwatch:PutMetricData`
Voici la `AmazonEMRServerlessServiceRolePolicy` politique complète.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2PolicyStatement",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeRouteTables"
],
"Resource": [
"*"
]
},
{
"Sid": "CloudWatchPolicyStatement",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"cloudwatch:namespace": [
"AWS/EMRServerless",
"AWS/Usage"
]
}
}
}
]
}
```
------
La politique de confiance suivante est attachée à ce rôle pour permettre au principal EMR Serverless d'assumer ce rôle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/aws-service-role/emr-serverless.amazonaws.com/AWSServiceRoleForEMRServerless",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d'informations, reportez-vous à la section [Autorisations relatives aux rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le Guide de l'utilisateur *IAM*.
## Création d'un rôle lié à un service pour EMR Serverless
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez une nouvelle application EMR Serverless dans (à l' AWS Management Console aide d'EMR Studio), ou dans l' AWS CLI API AWS , EMR Serverless crée le rôle lié au service pour vous. Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service.
**Pour créer le rôle AWSService RoleForAmazon EMRServerless lié à un service à l'aide d'IAM**
Ajoutez l'instruction suivante à la politique d'autorisations pour l'entité IAM qui doit créer le rôle lié à un service.
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
Si vous supprimez ce rôle lié à un service, puis que vous devez le créer à nouveau, suivez le même processus pour recréer le rôle dans votre compte. Lorsque vous créez une nouvelle application EMR Serverless, EMR Serverless crée à nouveau le rôle lié au service pour vous.
Vous pouvez également utiliser la console IAM pour créer un rôle lié à un service avec le cas d'utilisation **EMR** Serverless. Dans l'API AWS CLI ou dans l' AWS API, créez un rôle lié à un service avec le nom du `ops.emr-serverless.amazonaws.com` service. Pour plus d'informations, reportez-vous à la section [Création d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) dans le Guide de l'utilisateur *IAM*. Si vous supprimez ce rôle lié à un service, utilisez le même processus pour le créer à nouveau.
## Modification d'un rôle lié à un service pour EMR Serverless
EMR Serverless ne vous permet pas de modifier le rôle AWSService RoleForAmazon EMRServerless lié au service car diverses entités peuvent y faire référence. Vous ne pouvez pas modifier la politique IAM AWS détenue par le rôle lié au service EMR Serverless, car elle contient toutes les autorisations nécessaires dont EMR Serverless a besoin. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM.
**Pour modifier la description du rôle AWSService RoleForAmazon EMRServerless lié à un service à l'aide d'IAM**
Ajoutez l’instruction suivante à la stratégie d’autorisation de l’entité IAM qui doit modifier la description d’un rôle lié à un service.
```
{
"Effect": "Allow",
"Action": [
"iam: UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
Pour plus d'informations, reportez-vous à la section [Modification d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le Guide de l'utilisateur *IAM*.
## Suppression d'un rôle lié à un service pour EMR Serverless
Si vous n'avez plus besoin d'utiliser une fonctionnalité ou un service nécessitant un rôle lié à un service, nous vous suggérons de supprimer ce rôle. Ainsi, vous n'avez pas d'entité inutilisée qui n'est pas activement surveillée ou maintenue. Toutefois, supprimez toutes les applications EMR sans serveur dans toutes les régions avant de supprimer le rôle lié à un service.
**Note**
Si le service EMR Serverless utilise le rôle lorsque vous essayez de supprimer les ressources associées au rôle, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.
**Pour supprimer le rôle AWSService RoleForAmazon EMRServerless lié à un service à l'aide d'IAM**
Ajoutez la déclaration suivante à la politique d'autorisations pour l'entité IAM qui doit supprimer un rôle lié à un service.
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
**Pour supprimer manuellement le rôle lié au service à l’aide d’IAM**
Utilisez la console IAM, le AWS CLI, ou l' AWS API pour supprimer le rôle lié au AWSService RoleForAmazon EMRServerless service. Pour plus d'informations, reportez-vous à la section [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le guide de l'utilisateur *IAM*.
## Régions prises en charge pour les rôles liés à un service EMR sans serveur
EMR Serverless prend en charge l'utilisation de rôles liés au service dans toutes les régions où le service est disponible. Pour plus d'informations, reportez-vous à la section [AWS Régions et points de terminaison](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Rôles d'exécution des tâches pour Amazon EMR Serverless
Vous pouvez spécifier les autorisations de rôle IAM que l'exécution d'une tâche EMR sans serveur peut assumer lorsque vous appelez d'autres services en votre nom. Cela inclut l'accès à Amazon S3 pour toutes les sources de données, les cibles, ainsi que pour d'autres AWS ressources telles que les clusters Amazon Redshift et les tables DynamoDB. Pour en savoir plus sur la création d'un rôle, reportez-vous à[Création d'un rôle d'exécution de tâches](getting-started.md#gs-runtime-role).
**Exemples de politiques d'exécution**
Vous pouvez associer une politique d'exécution, telle que la suivante, à un rôle d'exécution de tâche. La politique d'exécution des tâches suivante permet :
+ Accès en lecture aux compartiments Amazon S3 contenant des exemples d'EMR.
+ Accès complet aux compartiments S3.
+ Créez et lisez l'accès au catalogue de données AWS Glue.
Pour ajouter l'accès à d'autres AWS ressources telles que DynamoDB, vous devez inclure les autorisations correspondantes dans la politique lors de la création du rôle d'exécution.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadAccessForEMRSamples",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*.elasticmapreduce",
"arn:aws:s3:::*.elasticmapreduce/*"
]
},
{
"Sid": "FullAccessToS3Bucket",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Sid": "GlueCreateAndReadDataCatalog",
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"*"
]
}
]
}
```
------
**Transmettez les privilèges liés aux rôles**
Vous pouvez associer des politiques d'autorisation IAM au rôle d'un utilisateur pour lui permettre de transmettre uniquement les rôles approuvés. Cela permet aux administrateurs de contrôler quels utilisateurs peuvent transmettre des rôles d'exécution de tâches spécifiques aux tâches EMR Serverless. Pour en savoir plus sur la définition des autorisations, reportez-vous à la section [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).
Voici un exemple de politique qui permet de transmettre un rôle d'exécution de tâche au principal du service EMR Serverless.
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::1234567890:role/JobRuntimeRoleForEMRServerless",
"Condition": {
"StringLike": {
"iam:PassedToService": "emr-serverless.amazonaws.com"
}
}
}
```
## Politiques d'autorisation gérées associées aux rôles d'exécution
Lorsque vous soumettez des exécutions de tâches à EMR sans serveur via la console EMR Studio, vous choisissez une étape au cours de laquelle vous choisissez un **rôle Runtime** à associer à votre application. Il est important de connaître les politiques gérées sous-jacentes associées à chaque sélection dans la console. Les trois sélections sont les suivantes :
1. **Tous les compartiments** : lorsque vous choisissez cette option, elle spécifie la politique FullAccess AWS gérée par [AmazonS3](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FullAccess.html), qui fournit un accès complet à tous les compartiments.
1. **Buckets spécifiques** : cela spécifie l'identifiant du nom de ressource Amazon (ARN) de chaque compartiment que vous choisissez. Aucune politique gérée sous-jacente n'est incluse.
1. **Aucune — Aucune** autorisation basée sur des politiques gérées n'est incluse.
Nous vous suggérons d'ajouter des compartiments spécifiques. Si vous choisissez tous les compartiments, n'oubliez pas qu'il définit un accès complet pour tous les compartiments.
# Exemples de politiques d'accès utilisateur pour EMR Serverless
Vous pouvez définir des politiques précises pour vos utilisateurs en fonction des actions que vous souhaitez que chaque utilisateur effectue lorsqu'il interagit avec des applications EMR sans serveur. Les politiques suivantes sont des exemples susceptibles de vous aider à configurer les autorisations appropriées pour vos utilisateurs. Cette section se concentre uniquement sur les politiques EMR Serverless. Pour des exemples de politiques utilisateur d'EMR Studio, reportez-vous à la section Configurer les autorisations utilisateur d'[EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-advanced-permissions-policy) Studio. Pour plus d'informations sur la façon d'associer des politiques aux utilisateurs IAM (principaux), reportez-vous à la section [Gestion des politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html) du Guide de l'utilisateur IAM.
## Politique relative aux utilisateurs expérimentés
Pour accorder toutes les actions requises pour EMR Serverless, créez et associez une `AmazonEMRServerlessFullAccess` politique à l'utilisateur, au rôle ou au groupe IAM requis.
Voici un exemple de politique qui permet aux utilisateurs expérimentés de créer et de modifier des applications EMR sans serveur, ainsi que d'effectuer d'autres actions telles que la soumission et le débogage de tâches. Il révèle toutes les actions requises par EMR Serverless pour les autres services.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication",
"emr-serverless:UpdateApplication",
"emr-serverless:DeleteApplication",
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StopApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
Lorsque vous activez la connectivité réseau à votre VPC, les applications EMR Serverless créent des interfaces réseau élastiques (ENI) Amazon EC2 pour communiquer avec les ressources du VPC. La politique suivante garantit que tout nouvel EC2 ENIs est créé uniquement dans le contexte des applications EMR sans serveur.
**Note**
Nous recommandons vivement de définir cette politique afin de garantir que les utilisateurs ne puissent pas créer d'EC2, ENIs sauf dans le cadre du lancement d'applications EMR sans serveur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEC2ENICreationWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "ops.emr-serverless.amazonaws.com"
}
}
}
]
}
```
------
Si vous souhaitez restreindre l'accès EMR Serverless à certains sous-réseaux, vous pouvez étiqueter chaque sous-réseau avec une condition de balise. Cette politique IAM garantit que les applications EMR sans serveur ne peuvent créer de l' ENIs EC2 que dans les sous-réseaux autorisés.
```
{
"Sid": "AllowEC2ENICreationInSubnetAndSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/KEY": "VALUE"
}
}
}
```
**Important**
Si vous êtes un administrateur ou un utilisateur expérimenté qui crée votre première application, vous devez configurer vos politiques d'autorisation pour vous permettre de créer un rôle lié à un service EMR Serverless. Pour en savoir plus, reportez-vous à[Utilisation de rôles liés à un service pour EMR Serverless](using-service-linked-roles.md).
La politique IAM suivante vous permet de créer un rôle lié à un service EMR Serverless pour votre compte.
```
{
"Sid":"AllowEMRServerlessServiceLinkedRoleCreation",
"Effect":"Allow",
"Action":"iam:CreateServiceLinkedRole",
"Resource":"arn:aws:iam::account-id:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless"
}
```
## Politique relative aux ingénieurs de données
Voici un exemple de politique qui accorde aux utilisateurs des autorisations en lecture seule sur les applications EMR Serverless, ainsi que la possibilité de soumettre et de déboguer des tâches. Gardez à l'esprit que, si cette stratégie n'empêche pas explicitement certaines actions, une autre déclaration de stratégie peut toutefois être utilisée pour accorder l'accès aux actions spécifiées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
## Utilisation de balises pour le contrôle d’accès
Vous pouvez utiliser les conditions des balises pour un contrôle d'accès précis. Par exemple, vous pouvez limiter le nombre d'utilisateurs à une seule équipe afin qu'ils ne puissent soumettre des tâches qu'aux applications EMR Serverless étiquetées avec le nom de leur équipe.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
# Politiques de contrôle d'accès basées sur les balises
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux applications et aux exécutions de tâches en fonction des balises.
Les exemples suivants illustrent différents scénarios et manières d'utiliser les opérateurs de condition avec les clés de condition EMR Serverless. Ces déclarations de politique IAM sont conçues uniquement à des fins de démonstration et ne doivent pas être utilisées dans des environnements de production. Il existe plusieurs façons de combiner des instructions de stratégie pour accorder et refuser des autorisations selon vos besoins. Pour plus d'informations sur la planification et le test des politiques IAM, consultez le guide de l'[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
**Important**
Le refus explicite d'autoriser l'attribution de balises doit être pris en considération. Cela empêche les utilisateurs de baliser une ressource et de s'accorder ainsi des autorisations que vous n'aviez pas l'intention d'accorder. Si les actions de balisage d'une ressource ne sont pas refusées, un utilisateur peut modifier les balises et contourner l'intention des politiques basées sur les balises. Pour un exemple de politique interdisant les actions de balisage, reportez-vous à[Refuser l'accès pour ajouter et supprimer des balises](#security-iam-TBAC-deny).
Les exemples ci-dessous illustrent les politiques d'autorisation basées sur l'identité qui sont utilisées pour contrôler les actions autorisées avec les applications EMR sans serveur.
## Autorisation d'actions uniquement sur les ressources ayant des valeurs de balises spécifiques
Dans l'exemple de politique suivant, l'opérateur de `StringEquals` condition essaie de faire `dev` correspondre la valeur du département des balises. Si le département des balises n'a pas été ajouté à l'application ou ne contient pas la valeur`dev`, la politique ne s'applique pas et les actions ne sont pas autorisées par cette politique. Si aucune autre déclaration de politique n'autorise les actions, l'utilisateur ne peut travailler qu'avec les applications dotées de cette balise avec cette valeur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:GetApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Sid": "AllowEMRSERVERLESSGetapplication"
}
]
}
```
------
Vous pouvez également spécifier plusieurs valeurs de balise à l'aide d'un opérateur de condition. Par exemple, pour autoriser des actions sur des applications où la `department` balise contient la valeur `dev` ou `test` pour remplacer le bloc de condition dans l'exemple précédent par le suivant.
```
"Condition": {
"StringEquals": {
"emr-serverless:ResourceTag/department": ["dev", "test"]
}
}
```
## Exiger le balisage lors de la création d'une ressource
Dans l'exemple ci-dessous, la balise doit être appliquée lors de la création de l'application.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
},
"Sid": "AllowEMRSERVERLESSCreateapplication"
}
]
}
```
------
La déclaration de politique suivante permet à un utilisateur de créer une application uniquement si celle-ci possède une `department` balise, qui peut contenir n'importe quelle valeur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
}
},
"Sid": "AllowEMRSERVERLESSCreateapplication"
}
]
}
```
------
## Refuser l'accès pour ajouter et supprimer des balises
Cette politique empêche un utilisateur d'ajouter ou de supprimer des balises dans les applications EMR Serverless dont la valeur n'est `department` pas la même. `dev`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"emr-serverless:TagResource",
"emr-serverless:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/department": "dev"
}
},
"Sid": "AllowEMRSERVERLESSTagresource"
}
]
}
```
------
# Exemples de politiques basées sur l'identité pour EMR Serverless
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources Amazon EMR Serverless. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
*Pour plus de détails sur les actions et les types de ressources définis par Amazon EMR Serverless, y compris le format du ARNs pour chacun des types de ressources, consultez la section [Actions, ressources et clés de condition pour Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html) dans la référence d'autorisation de service.*
**Topics**
+ [Bonnes pratiques en matière de politiques](#security-iam-policy-best-practices)
+ [Permettre aux utilisateurs d'accéder à leurs propres autorisations](#security-iam-id-based-policy-examples-view-own-permissions)
## Bonnes pratiques en matière de politiques
**Note**
EMR Serverless ne prend pas en charge les politiques gérées. La première pratique décrite ci-dessous ne s'applique donc pas.
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources Amazon EMR Serverless dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Permettre aux utilisateurs d'accéder à leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Amazon EMR Serverless : mises à jour des politiques gérées AWS
Accédez aux informations relatives aux mises à jour des politiques AWS gérées pour Amazon EMR Serverless depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la page d'historique des [documents](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/doc-history.html) Amazon EMR Serverless.
| Modifier | Description | Date |
| --- | --- | --- |
| Amazon EMRServerless ServiceRolePolicy — Mise à jour d'une politique existante | [Amazon EMR Serverless a ajouté le nouveau `Sid``CloudWatchPolicyStatement` et `EC2PolicyStatement` à la politique d'Amazon. EMRServerless ServiceRolePolicy ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/using-service-linked-roles.html#slr-permissions) | 25 janvier 2024 |
| Amazon EMRServerless ServiceRolePolicy — Mise à jour d'une politique existante | Amazon EMR Serverless a ajouté de nouvelles autorisations pour permettre à Amazon EMR Serverless de publier des statistiques de compte agrégées relatives à l'utilisation des vCPU dans l'espace de noms. `"AWS/Usage"` | 20 avril 2023 |
| Amazon EMR Serverless a commencé à suivre les modifications | Amazon EMR Serverless a commencé à suivre les modifications apportées à ses AWS politiques gérées. | 20 avril 2023 |
# Résolution des problèmes d'identité et d'accès sans serveur Amazon EMR
Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Amazon EMR Serverless et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Amazon EMR Serverless](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources Amazon EMR Serverless](#security_iam_troubleshoot-cross-account-access)
+ [Je ne parviens pas à ouvrir le serveur Live UI/Spark History depuis EMR Studio pour déboguer ma tâche ou une erreur d'API se produit lorsque j'essaie d'obtenir des journaux en utilisant `get-dashboard-for-job-run`](#security_iam_troubleshoot-emr-identity-access)
## Je ne suis pas autorisé à effectuer une action dans Amazon EMR Serverless
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, contactez votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d’utilisateur et votre mot de passe.
L'exemple d'erreur suivant se produit lorsque l'`mateojackson`utilisateur essaie d'utiliser la console pour accéder aux détails d'une `my-example-widget` ressource fictive mais ne dispose pas des `emr-serverless:GetWidget` autorisations fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: emr-serverless:GetWidget on resource: my-example-widget
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `my-example-widget` à l’aide de l’action `emr-serverless:GetWidget`.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Amazon EMR Serverless.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L'exemple d'erreur suivant se produit lorsqu'un utilisateur IAM nommé `marymajor` essaie d'utiliser la console pour effectuer une action dans Amazon EMR Serverless. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources Amazon EMR Serverless
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Amazon EMR Serverless prend en charge ces fonctionnalités, consultez. [Identity and Access Management (IAM) dans Amazon EMR Serverless](security_iam_service-with-iam.md)
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Je ne parviens pas à ouvrir le serveur Live UI/Spark History depuis EMR Studio pour déboguer ma tâche ou une erreur d'API se produit lorsque j'essaie d'obtenir des journaux en utilisant `get-dashboard-for-job-run`
Si vous utilisez le stockage géré EMR sans serveur pour la journalisation et que votre application EMR sans serveur se trouve dans un sous-réseau privé [avec des points de terminaison VPC pour Amazon S3 et que vous attachez une politique de point de terminaison pour contrôler l'accès, ajoutez les autorisations mentionnées dans la section Journalisation pour EMR sans serveur dans votre politique VPC au point de terminaison de passerelle S3 pour que EMR Serverless stocke](logging.html#jobs-log-storage-managed-storage) et diffuse les journaux des applications.