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.
# Didacticiels IAM
Les didacticiels suivants présentent end-to-end des procédures complètes pour les tâches courantes pour Gestion des identités et des accès AWS (IAM). Ils sont conçus pour une environnement de travaux pratiques, avec des exemples fictifs de noms de sociétés, de noms d'utilisateur, etc. Leur objectif consiste à fournir des instructions générales. Ils ne sont pas conçus pour être utilisés directement dans votre environnement de production sans être préalablement vérifiés et adaptés soigneusement aux besoins uniques de votre organisation.
**Topics**
+ [Déléguer l'accès Comptes AWS aux différents rôles](tutorial_cross-account-with-roles.md)
+ [Créer une politique gérée par le client](tutorial_managed-policies.md)
+ [Utiliser le contrôle d'accès basé sur les attributs (ABAC, attribute-based access control)](tutorial_attribute-based-access-control.md)
+ [Autoriser les utilisateurs à gérer leurs informations d'identification et leurs paramètres MFA](tutorial_users-self-manage-mfa-and-creds.md)
+ [Créez un IdP SAML avec CloudFormation](tutorial_saml-idp.md)
+ [Créez un rôle fédéré SAML avec CloudFormation](tutorial_saml-federated-role.md)
+ [Créez un IdP SAML et un rôle fédéré avec CloudFormation](tutorial_saml-idp-and-federated-role.md)
# Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM
**Important**
[Les meilleures pratiques](best-practices.md) IAM recommandent de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder à l'aide d'informations d'identification temporaires plutôt que d' AWS utiliser des utilisateurs IAM dotés d'informations d'identification à long terme. Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les [cas d’utilisation spécifiques](gs-identities-iam-users.md) non pris en charge par les utilisateurs fédérés.
Ce tutoriel vous apprend à utiliser un rôle pour déléguer l’accès à des ressources dans des Comptes AWS différents appelés **Destination** et **Origine**. Vous partagez les ressources d'un compte avec les utilisateurs d'un autre compte. En configurant l'accès entre les comptes de cette manière, vous n'avez pas besoin de créer des utilisateurs IAM individuels dans chaque compte. En outre, les utilisateurs n'ont pas besoin de se déconnecter d'un compte et de se connecter à un autre compte pour accéder à des ressources situées dans des Comptes AWS différents. Après avoir configuré le rôle, vous découvrirez comment utiliser le rôle à partir du AWS Management Console AWS CLI, et de l'API.
Dans ce didacticiel, le compte **Destination** gère les données d’application auxquelles accèdent différentes applications et équipes. Dans chaque compte, vous stockez les informations de l'application dans des compartiments Amazon S3. Vous gérez les utilisateurs IAM dans le compte **Origine**,où vous disposez de deux rôles d’utilisateur IAM : **Développeurs** et **Analystes**. Les développeurs et les analystes utilisent le compte **Origine** pour générer des données partagées par plusieurs microservices. Les deux rôles ont des autorisations pour travailler dans le compte Origine et y accéder aux ressources qui s’y trouvent. De temps à autre, un développeur doit mettre à jour les données partagées dans le compte **Destination**. Les développeurs stockent ces données dans un compartiment Amazon S3 appelé `amzn-s3-demo-bucket-shared-container`.
Au terme de ce tutoriel, vous disposerez des éléments suivants :
+ Utilisateurs du compte **Origine** (le compte approuvé) autorisés à endosser un rôle spécifique dans le compte **Destination**.
+ Rôle du compte **Destination** (le compte d’approbation) autorisé à accéder à un compartiment Amazon S3 spécifique.
+ Le compartiment `amzn-s3-demo-bucket-shared-container` du compte **Destination**.
Les développeurs peuvent utiliser le rôle indiqué dans le AWS Management Console pour accéder au `amzn-s3-demo-bucket-shared-container` compartiment dans le compte **Destination**. Ils peuvent également accéder au compartiment à l'aide des appels API authentifiés par les informations d'identification temporaires fournies par le rôle. Les tentatives similaires des analystes pour utiliser le rôle échouent.
Ce flux de travail se compose de trois étapes de base :
**[Création d’un rôle dans le compte Destination](#tutorial_cross-account-with-roles-1)**
Tout d'abord, vous utilisez le AWS Management Console pour établir un lien de confiance entre le compte de **destination** (numéro d'identification 999999999999) et le compte d'**origine** (numéro d'identification 111111111111). Vous commencez par créer un rôle IAM nommé *UpdateData*. Lorsque vous créez le rôle, vous définissez le compte **Origine** en tant qu’entité approuvée et spécifiez une politique d’autorisations qui autorise les utilisateurs de confiance à mettre à jour le compartiment `amzn-s3-demo-bucket-shared-container`.
**[Accorder l'accès au rôle](#tutorial_cross-account-with-roles-2)**
Dans cette section, vous modifiez la politique de rôle pour refuser aux analystes l’accès au rôle `UpdateData`. Parce que les analystes PowerUser y ont accès dans ce scénario, vous devez explicitement *refuser* la possibilité d'utiliser le rôle.
**[Tester l'accès en changeant de rôles](#tutorial_cross-account-with-roles-3)**
Enfin, en tant que développeur, vous utilisez le rôle `UpdateData` pour mettre à jour le compartiment `amzn-s3-demo-bucket-shared-container` dans le compte **Destination**. Vous allez voir comment accéder au rôle via la AWS console, le AWS CLI, et l'API.
## Considérations
Avant d'utiliser les rôles IAM pour déléguer l'accès aux ressources Comptes AWS, il est important de prendre en compte les points suivants :
+ Il n'est pas possible de passer à un rôle si vous vous connectez en tant qu' Utilisateur racine d'un compte AWS.
+ Les politiques IAM basées sur les ressources et les rôles ne délèguent l'accès entre les comptes qu'au sein d'une seule partition. Par exemple, supposons que vous avez un compte dans la région USA Ouest (Californie du Nord) sur la partition `aws` standard. Vous avez également un compte dans la région Chine (Beijing) sur la partition `aws-cn`. Vous ne pouvez pas utiliser une politique basée sur les ressources d’Amazon S3 dans votre compte en Chine (Beijing) pour autoriser l'accès aux utilisateurs de votre compte `aws` standard.
+ Vous pouvez l'utiliser AWS IAM Identity Center pour faciliter l'authentification unique (SSO) pour les comptes externes Comptes AWS (comptes extérieurs au vôtre) à l'aide du langage AWS Organizations SAML (Security Assertion Markup Language). Pour plus de détails, voir [Intégrer des données externes Comptes AWS dans AWS IAM Identity Center pour une gestion centralisée des accès avec facturation indépendante à l'aide de SAML 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en)
+ Vous pouvez associer des rôles à des AWS ressources telles que des instances ou AWS Lambda des fonctions Amazon EC2. Pour en savoir plus, consultez [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md).
+ Si vous souhaitez qu'une application joue un rôle dans une autre Compte AWS, vous pouvez utiliser le AWS SDK pour l'attribution de rôles entre comptes. Pour plus d'informations, consultez la section [Authentification et accès](https://docs.aws.amazon.com//sdkref/latest/guide/access.html) dans le *guide de référence des outils AWS SDKs et des outils*.
+ Le changement de rôle à l'aide du AWS Management Console ne fonctionne qu'avec les comptes qui ne nécessitent pas de`ExternalId`. Par exemple, supposons que vous accordiez l'accès à votre compte à un tiers et que vous ayez besoin d'un `ExternalId` dans un élément `Condition` de votre politique d'autorisations. Dans ce cas, le tiers ne peut accéder à votre compte qu'à l'aide de l' AWS API ou d'un outil de ligne de commande. Le tiers ne peut pas utiliser la console, car elle doit fournir de valeur pour `ExternalId`. Pour plus d'informations sur ce scénario[Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md), consultez la [section « Comment activer l'accès entre comptes » AWS Management Console dans le](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) blog sur la AWS sécurité.
## Conditions préalables
Le didacticiel présume que vous avez déjà ce qui suit en place :
+ **Deux** comptes distincts Comptes AWS que vous pouvez utiliser, l'un pour représenter le compte **d'origine** et l'autre pour représenter le compte de **destination**.
+ Les utilisateurs et les rôles du compte **Origine** créés et configurés comme suit :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ Vous n’avez pas besoin de créer d’utilisateurs dans le compte **Destination**.
+ Un compartiment Amazon S3 créé dans le compte **Destination**. Vous pouvez l'appeler `amzn-s3-demo-bucket-shared-container` dans ce tutoriel, mais du fait que les noms de compartiment S3 doivent être globalement uniques, vous devrez utiliser un compartiment avec un nom différent.
## Création d’un rôle dans le compte Destination
Vous pouvez autoriser les utilisateurs de l'un Compte AWS à accéder aux ressources d'un autre Compte AWS. Dans ce didacticiel, nous le ferons en créant un rôle qui définit qui peut y accéder et quelles autorisations il accorde aux utilisateurs qui y basculent.
Dans cette étape du didacticiel, vous créez le rôle dans le compte **Destination** et spécifiez le compte **Origine** comme entité approuvée. Vous limitez également les autorisations du rôle à un accès en lecture seule et en écriture au compartiment `amzn-s3-demo-bucket-shared-container`. Toute personne ayant autorisation d'utiliser le rôle peut lire et écrire dans le compartiment `shared-container`.
Avant de créer un rôle, vous avez besoin de l'*identifiant de compte* de l'**Originating** Compte AWS. Chacun Compte AWS possède un identifiant de compte unique qui lui est attribué.
**Pour obtenir l' Compte AWS identifiant d'origine**
1. Connectez-vous en AWS Management Console tant qu'administrateur du compte **Originating** et ouvrez la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans la console IAM, sélectionnez votre nom d'utilisateur dans la barre de navigation, en haut à droite. Cela ressemble généralement à ceci : ***username*@ *account\$1ID\$1number\$1or\$1alias***.
Pour ce scénario, vous pouvez utiliser l’ID 111111111111 pour le compte **Origine**. Toutefois, vous devez utiliser un ID de compte valide si vous utilisez ce scénario dans votre environnement de test.
**Pour créer un rôle dans le compte Destination qui peut être utilisé par le compte Origine**
1. Connectez-vous en AWS Management Console tant qu'administrateur du compte **Destination** et ouvrez la console IAM.
1. Avant de créer le rôle, préparez la politique gérée qui définit les autorisations pour les exigences du rôle. Vous attachez cette politique au rôle dans une étape ultérieure.
Vous devez définir l'accès en lecture et en écriture au compartiment `amzn-s3-demo-bucket-shared-container`. Bien que AWS certaines politiques soient gérées par Amazon S3, aucune ne fournit un accès en lecture et en écriture à un seul compartiment Amazon S3. Vous pouvez créer votre propre politique à la place.
Dans le panneau de navigation, choisissez **Politiques**, puis **Créer une politique**.
1. Choisissez l'onglet **JSON** et copiez le texte du document de politique JSON suivant. Collez ce texte dans la zone de texte **JSON**, en remplaçant l'ARN de la ressource (`arn:aws:s3:::shared-container`) par celui qui correspond véritablement à votre compartiment Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
```
------
L'action `ListAllMyBuckets` accorde l'autorisation de répertorier tous les compartiments appartenant à l'expéditeur authentifié de la demande. L'autorisation `ListBucket` permet aux utilisateurs d'afficher des objets dans le compartiment `amzn-s3-demo-bucket-shared-container`. Les autorisations `GetObject`, `PutObject`, `DeleteObject` permettent aux utilisateurs d'afficher, de mettre à jour et de supprimer le contenu du compartiment `amzn-s3-demo-bucket-shared-container`.
**Note**
Vous pouvez basculer à tout moment entre les options des éditeurs **visuel** et **JSON**. Toutefois, si vous apportez des modifications ou si vous choisissez **Suivant** dans l'éditeur **visuel**, IAM peut restructurer votre politique afin de l'optimiser pour l'éditeur visuel. Pour de plus amples informations, veuillez consulter [Restructuration de politique](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Sur la page **Vérifier et créer**, tapez **read-write-app-bucket** pour le nom de la politique. Vérifiez les autorisations accordées par votre politique, puis choisissez **Créer une politique** pour enregistrer votre travail.
La nouvelle politique apparaît dans la liste des politiques gérées.
1. Dans le panneau de navigation, choisissez **Roles** (Rôles), puis **Create role** (Créer un rôle).
1. Choisissez le type de rôle **Un Compte AWS**.
1. Dans le champ **ID de compte**, saisissez l’ID du compte **Origine**.
Ce didacticiel utilise l’exemple d’ID de compte **111111111111** pour le compte **Origine**. Vous devez utiliser un ID de compte valide. Si vous utilisez un ID de compte non valide, comme **111111111111**, IAM ne vous laisse pas créer de rôle.
Pour le moment, les utilisateurs n'ont pas besoin d'un ID externe ou d'une authentification multi-facteurs (MFA) pour endosser le rôle. Laissez ces options décochées. Pour plus d’informations, veuillez consulter [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md).
1. Choisissez **suivant : autorisations** pour configurer les autorisations associées au rôle.
1. Cochez la case en regard de la politique que vous avez créée précédemment.
**Conseil**
Pour **filtre**, sélectionnez **politiques gérées par le client** pour affiner la liste afin d'inclure uniquement les politiques que vous avez créées. Cela masque les politiques créées par AWS et permet de rechercher plus facilement celle dont vous avez besoin.
Ensuite, choisissez **Suivant**.
1. (Facultatif) Ajoutez des métadonnées au rôle en associant les identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md).
1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle.
1. Après avoir procédé à la révision du rôle, sélectionnez **Créer un rôle**.
Le rôle `UpdateData` s'affiche dans la liste des rôles.
À présent, vous devez obtenir l'Amazon Resource Name (ARN) du rôle, qui est un identifiant unique du rôle. Lorsque vous modifiez le rôle du développeur dans le compte Origine, vous spécifiez l’ARN du rôle à partir du compte Destination afin d’accorder ou de refuser des autorisations.
**Pour obtenir l'ARN pour UpdateData**
1. Dans le panneau de navigation de la console IAM, sélectionnez **Roles** (Rôles).
1. Dans la liste des rôles, sélectionnez le rôle `UpdateData`.
1. Dans la section **Récapitulatif** du panneau des détails, copiez la valeur du champ **ARN de rôle**.
Le compte Destination ayant pour ID de compte 999999999999, l’ARN du rôle est donc `arn:aws:iam::999999999999:role/UpdateData`. Assurez-vous de fournir le véritable Compte AWS identifiant du compte Destination.
À ce stade, vous avez établi un lien d’approbation entre les comptes **Destination** et **Origine**. Pour ce faire, créez un rôle dans le compte **Destination** qui identifie le compte **Origine** en tant que principal compte d’approbation. Vous avez également défini ce que les utilisateurs qui basculent vers le rôle `UpdateData` peuvent faire.
Ensuite, modifiez les autorisations pour le rôle Développeur.
## Accorder l'accès au rôle
À ce stade, les analystes et les développeurs disposent d’autorisations leur permettant de gérer les données dans le compte **Origine**. Utilisez la procédure requise pour ajouter des autorisations visant à autoriser le changement de rôle.
**Pour modifier le rôle des développeurs afin de leur permettre de passer au UpdateData rôle**
1. Connectez-vous en tant qu’administrateur dans le compte **Origine**, puis ouvrez la console IAM.
1. Choisissez **Rôles**, puis choisissez **Développeurs**.
1. Sélectionnez l'onglet **Permissions** (Autorisations), puis **Add permissions** (Ajouter des autorisations), et enfin **Create inline policy** (Créer une politique en ligne).
1. Choisissez l’onglet **JSON**.
1. Ajoutez l’instruction de politique suivante pour autoriser l’action `AssumeRole` sur le rôle `UpdateData` dans le compte Destination. Assurez-vous de remplacer *DESTINATION-ACCOUNT-ID* l'`Resource`élément par l' Compte AWS identifiant réel du compte de destination.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L’effet `Allow` autorise explicitement l’accès du groupe Développeurs au rôle `UpdateData` dans le compte Destination. Tout développeur qui essaie d'accéder à ce rôle y parvient.
1. Choisissez **Examiner une politique**.
1. Tapez un **Nom**, tel que **allow-assume-S3-role-in-destination**.
1. Choisissez **Create Policy** (Créer une politique).
Dans la plupart des environnements, vous n'aurez peut-être pas besoin de la procédure suivante. Toutefois, si vous utilisez PowerUserAccess des autorisations, il est possible que certains groupes soient déjà en mesure de changer de rôle. Les procédures suivantes indiquent comment ajouter une autorisation `"Deny"` au groupe Analystes pour s’assurer qu’ils ne peuvent pas endosser le rôle. Si vous n'avez pas besoin de cette procédure dans votre environnement, nous vous recommandons de ne pas l'ajouter. Les autorisations `"Deny"` rendent l'ensemble des autorisations plus compliqué à gérer et à comprendre. Utilisez les autorisations `"Deny"` uniquement lorsque vous ne disposez pas de meilleure option.
**Pour modifier le rôle Analystes afin de lui refuser l’autorisation d’endosser ce rôle `UpdateData`**
1. Choisissez **Rôles**, puis **Analystes**.
1. Sélectionnez l'onglet **Permissions** (Autorisations), puis **Add permissions** (Ajouter des autorisations), et enfin **Create inline policy** (Créer une politique en ligne).
1. Choisissez l’onglet **JSON**.
1. Ajoutez l'instruction de politique suivante pour refuser l'action `AssumeRole` sur le rôle `UpdateData`. Assurez-vous de remplacer *DESTINATION-ACCOUNT-ID* l'`Resource`élément par l' Compte AWS identifiant réel du compte de destination.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/UpdateData"
}
}
```
------
L’effet `Deny` refuse explicitement l’accès du groupe Analystes au rôle `UpdateData` dans le compte Destination. Tout analyste qui essaiera d’accéder au rôle recevra un message d’accès refusé.
1. Choisissez **Examiner une politique**.
1. Tapez un **Nom** comme **deny-assume-S3-role-in-destination**.
1. Choisissez **Create Policy** (Créer une politique).
Le rôle Développeurs a maintenant l’autorisation d’utiliser le rôle `UpdateData` dans le compte Destination. Le rôle Analystes ne peut pas utiliser le rôle `UpdateData`.
Ensuite, vous pouvez voir comment David, un développeur, peut accéder au compartiment `amzn-s3-demo-bucket-shared-container` dans le compte Destination. David peut accéder au bucket depuis le AWS Management Console AWS CLI, le ou l' AWS API.
## Tester l'accès en changeant de rôles
Après avoir terminé les deux premières étapes de ce didacticiel, vous disposez d’un rôle qui accorde l’accès à une ressource du compte **Destination**. Vous disposez également d’un rôle dans le compte **Origine** avec des utilisateurs autorisés à utiliser ce rôle. Cette étape explique comment tester le passage à ce rôle depuis l'API AWS Management Console AWS CLI, le et l' AWS API.
Pour obtenir de l’aide sur les problèmes courants que vous êtes susceptible de rencontrer lors de l’utilisation des rôles IAM, consultez [Résolution des problèmes liés aux rôles IAM](troubleshoot_roles.md).
### Changer de rôle (console)
Si David a besoin de mettre à jour les données du compte **Destination** dans le AWS Management Console, il peut le faire en utilisant **Switch Role**. Il indique l'ID de compte ou l'alias et le nom du rôle, et ses autorisations passent immédiatement à celles autorisées par le rôle. Il peut ensuite utiliser la console pour travailler avec le compartiment `amzn-s3-demo-bucket-shared-container`, mais il ne peut pas utiliser d’autres ressources de l’environnement **Destination**. Bien que David utilise le rôle, il ne peut pas non plus utiliser ses privilèges d’utilisateur avancé dans le compte **Origine**. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois.
IAM fournit deux procédures que David peut utiliser pour accéder à la page **Switch Role (changer de rôle)** :
+ David reçoit un lien de son administrateur qui dirige vers la configuration Switch Role prédéfinie. Le lien est fourni à l'administrateur sur la page finale de l'assistant **Créer un rôle** ou sur la page **Résumé du rôle** pour un rôle inter-compte. Si David choisit ce lien, il accède à la page **Switch Role (Changer de rôle)** avec les champs **ID de compte** et **Nom du rôle** déjà remplis. Il ne reste plus à David qu’à choisir **Changer de rôle**.
+ L'administrateur n'envoie pas le lien dans un e-mail, mais il envoie les valeurs de l'**ID de compte** et du **Nom de rôle**. Pour changer de rôle, David doit manuellement saisir les valeurs. La procédure suivante en est l'illustration.
**Pour endosser un rôle**
1. David se connecte en AWS Management Console utilisant son utilisateur habituel dans le compte **Originating**.
1. Il choisit le lien que l'administrateur lui a envoyé par email. Cela amène David à la page **Switch Role** (Changer de rôle) avec l'identifiant ou l'alias de compte et les informations sur le nom du rôle déjà remplis.
—ou—
David choisit son nom (le menu Identity [Identité]) dans la barre de navigation, puis sélectionne **Switch Roles** (Changer de rôle).
Si c'est la première fois que David essaie d'accéder à la page Switch Role (changer de rôle) de cette manière, il est dirigé vers la 1ère page de mise en route **Switch Role (changer de rôle)**. Cette page fournit des informations supplémentaires sur la manière dont le changement de rôle permet aux utilisateurs de gérer des ressources entre Comptes AWS. David doit choisir **Switch Role (changer de rôle)** sur cette page pour appliquer le reste de la procédure.
1. Ensuite, pour accéder au rôle, David doit saisir manuellement le numéro d’ID (`999999999999`) et le nom du rôle (`UpdateData`) du compte Destination.
En outre, David souhaite contrôler les rôles et les autorisations associées actuellement actifs dans IAM. Pour suivre ces informations, il saisit `Destination` dans la zone de texte **Display Name** (nom complet), choisit l'option de couleur rouge, puis choisit **Switch Role** (changer de rôle).
1. David peut maintenant utiliser la console Amazon S3 pour travailler avec le compartiment Amazon S3 ou toute autre ressource pour laquelle le rôle `UpdateData` dispose d'autorisations.
1. Quand c'est fait, David peut retourner dans ses autorisations d'origine. Pour cela, il choisit le nom complet du rôle **Destination** sur la barre de navigation, puis il sélectionne **Revenir à David à 111111111111**.
1. La prochaine fois que David voudra changer de rôle et choisira le menu **Identité** dans la barre de navigation, il verra l’entrée Destination toujours affichée depuis la dernière fois. Il lui suffira de choisir cette entrée pour changer de rôle immédiatement sans avoir à ressaisir l'ID du compte et le nom du rôle.
### Changer de rôles (AWS CLI)
Si David a besoin de travailler dans l’environnement **Destination** dans la ligne de commande, il peut y parvenir grâce à l’outil [AWS CLI](https://aws.amazon.com/cli/). Il exécute la commande `aws sts assume-role` et transmet l'ARN du rôle pour obtenir les informations d'identification de sécurité temporaires de ce rôle. Il configure ensuite ces informations d'identification dans les variables d'environnement afin que AWS CLI les commandes suivantes fonctionnent en utilisant les autorisations du rôle. Bien que David utilise le rôle, il ne peut pas utiliser ses privilèges d’utilisateur avancé dans le compte **Origine**, car un seul ensemble d’autorisations peut être effectif à la fois.
Notez que toutes les clés d'accès et tous les jetons sont des exemples uniquement et ne peuvent pas être utilisés comme indiqué. Remplacez-les par les valeurs correspondantes de votre environnement en direct.
**Pour endosser un rôle**
1. David ouvre une fenêtre d'invite de commande et confirme que le AWS CLI client fonctionne en exécutant la commande :
```
aws help
```
**Note**
L'environnement par défaut de David utilise les informations d'identification de l'utilisateur `David` de son profil par défaut qu'il a créé avec la commande `aws configure`. Pour plus d'informations, veuillez consulter [configuration de l'outil AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) dans le *guide de l'utilisateur de l'outil AWS Command Line Interface *.
1. Il commence le processus de changement de rôle en exécutant la commande suivante pour passer au rôle `UpdateData` dans le compte **Destination**. Il a reçu l'ARN du rôle auprès de l'administrateur ayant créé le rôle. La commande nécessite que vous fournissiez un nom de session également. Pour cela, vous pouvez choisir n'importe quel texte.
```
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
```
David voit ensuite ce qui suit dans le résultat :
```
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
```
1. David voit les trois éléments dont il a besoin dans la section informations d'identification du résultat.
+ `AccessKeyId`
+ `SecretAccessKey`
+ `SessionToken`
David doit configurer l' AWS CLI environnement pour utiliser ces paramètres lors des appels suivants. Pour plus d'informations sur les différentes manières de configurer vos informations d'identification, veuillez consulter [Configuration de l'outil AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence). Vous ne pouvez pas utiliser la commande `aws configure`, car elle ne prend pas en charge la capture du jeton de session. En revanche, vous pouvez saisir manuellement les informations dans un fichier de configuration. Du fait qu'il s'agisse d'informations d'identification temporaires avec un délai d'expiration relativement court, il est plus facile de les ajouter à l'environnement de votre session de ligne de commande actuelle.
1. Pour ajouter les trois valeurs à l'environnement, David coupe et colle le résultat de l'étape précédente dans les commandes suivantes. Vous pourriez vouloir couper et coller dans un simple éditeur de texte pour résoudre les problèmes de retour à la ligne dans le résultat du jeton de session. Elles doivent être ajoutées sous la forme d'une simple chaîne longue, même si elles s'affichent avec des retours de ligne pour plus de clarté.
L'exemple suivant illustre les commandes fournies dans l'environnement Windows où « set » est la commande destinée à créer une variable d'environnement. Sur Linux ou macOS, vous devez plutôt utiliser la commande « export ». Toutes les autres sections de l'exemple sont valides dans les trois environnements.
Pour en savoir plus sur l'utilisation des outils pour Windows Powershell, consultez [Basculer vers un rôle IAM (Outils pour Windows PowerShell)](id_roles_use_switch-role-twp.md)
```
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
```
À ce stade, toutes les commandes seront exécutées avec les autorisations du rôle identifié par ces informations d'identification. Dans le cas de David, le rôle `UpdateData`.
**Important**
Vous pouvez enregistrer vos paramètres de configuration utilisés fréquemment et vos informations d’identification dans des fichiers qui sont gérés par l’ AWS CLI. Pour plus d’informations, consultez [Utilisations de fichiers de configurations et d’informations d’identification existants](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing) dans le *Guide de l’utilisateur AWS Command Line Interface *.
1. Exécutez la commande pour accéder aux ressources du compte Destination. Dans cet exemple, David répertorie simplement le contenu de son compartiment S3 avec la commande suivante.
```
aws s3 ls s3://shared-container
```
Du fait que les noms de compartiments Amazon S3 sont universellement uniques, il n'est pas nécessaire de spécifier l'ID du compte qui est titulaire du compartiment. Pour accéder aux ressources d'autres AWS services, reportez-vous à la AWS CLI documentation de ce service pour connaître les commandes et la syntaxe requises pour référencer ses ressources.
### Utilisation AssumeRole (AWS API)
Lorsque David a besoin de faire une mise à jour dans le compte **Destination** depuis le code, il réalise un appel `AssumeRole` pour endosser le rôle `UpdateData`. L’appel renvoie des informations d’identification temporaires qu’il peut utiliser pour accéder au compartiment `amzn-s3-demo-bucket-shared-container` dans le compte **Destination**. Grâce à ces informations d'identification, David peut réaliser des appels d'API pour mettre à jour le compartiment `amzn-s3-demo-bucket-shared-container`. Cependant, il ne peut pas réaliser des appels d’API pour accéder aux autres ressources du compte **Destination**, même s’il a des autorisations d’utilisateur avancé dans le compte **Origine**.
**Pour endosser un rôle**
1. David appelle `AssumeRole` dans le cadre d'une application. Il doit spécifier l'ARN `UpdateData` : `arn:aws:iam::999999999999:role/UpdateData`.
La réponse de l'appel `AssumeRole` inclut les informations d'identification temporaires avec un `AccessKeyId` et un `SecretAccessKey`. Elle inclut également une heure `Expiration` qui indique à quel moment les informations d'identification expirent et vous devez en demander de nouvelles. Lorsque vous configurez le chaînage des rôles avec le AWS SDK, de nombreux fournisseurs d'informations d'identification actualisent automatiquement les informations d'identification avant leur expiration.
1. Grâce aux informations d'identification de sécurité temporaires, David réalise un appel `s3:PutObject` pour mettre à jour le compartiment `amzn-s3-demo-bucket-shared-container`. Il transfère les informations d'identification à l'appel d'API en tant que paramètre `AuthParams`. Du fait que les informations d’identification de rôle temporaires ont uniquement accès en lecture et en écriture au compartiment `amzn-s3-demo-bucket-shared-container`, toute autre action dans le compte Destination est refusée.
Pour obtenir un exemple de code (à l'aide de Python), veuillez consulter [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md).
## Ressources supplémentaires
Les ressources suivantes peuvent vous aider à en savoir plus sur les sujets abordés dans ce didacticiel :
+ Pour plus d’informations sur les utilisateurs IAM, consultez [IAM identités](id.md).
+ Pour plus d'informations sur les compartiments Amazon S3, veuillez consulter [créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) dans le *Amazon Simple Storage Service User Guide* (guide de l'utilisateur du service de stockage simple de Amazon).
+ Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, veuillez consulter [Qu'est-ce que l'Analyseur d'accès IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
## Résumé
Vous avez terminé le didacticiel d'accès aux API entre les comptes. Vous avez créé un rôle pour établir des relations de confiance avec un autre compte et défini les actions que les entités approuvées peuvent effectuer. Ensuite, vous avez modifié une politique de rôle pour contrôler les utilisateurs IAM qui peuvent accéder au rôle. Par conséquent, les développeurs du compte **Origine** peuvent faire des mises à jour dans le compartiment `amzn-s3-demo-bucket-shared-container` du compte **Destination** à l’aide d’informations d’identification temporaires.
# Didacticiel IAM : créer et attacher votre première politique gérée par le client
Dans ce didacticiel, vous allez utiliser le AWS Management Console pour créer une [politique gérée par le client](access_policies_managed-vs-inline.md#customer-managed-policies), puis associer cette politique à un utilisateur IAM de votre Compte AWS. La politique que vous créez permet à un utilisateur de test IAM de se connecter directement au AWS Management Console avec des autorisations en lecture seule.
Ce flux de travail se compose de trois étapes de base :
**[Étape 1 : Créer la politique](#step1-create-policy)**
Par défaut, les utilisateurs IAM ne sont autorisés à rien faire. Ils ne peuvent pas accéder à la Console de gestion AWS ou à gérer les données qu'elle contient sans votre autorisation. Dans cette étape, vous créez une politique gérée par le client qui autorise tous les utilisateurs attachés à se connecter à la console.
**[Étape 2 : Attacher la politique](#step2-attach-policy)**
Lorsque vous attachez une politique à un utilisateur, celui-ci hérite des autorisations d'accès associées à cette politique. Dans cette étape, vous attachez la nouvelle politique à un utilisateur test.
**[Étape 3 : Tester l'accès utilisateur](#step3-test-access)**
Une fois la politique attachée, vous pouvez vous connecter en tant que l'utilisateur pour tester la politique.
## Conditions préalables
Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :
+ Et Compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur IAM avec des autorisations administratives.
+ Un utilisateur IAM de test n'a aucune autorisation attribuée et n'appartient à aucun groupe comme suit :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_managed-policies.html)
## Étape 1 : Créer la politique
Au cours de cette étape, vous créez une politique gérée par le client qui permet à tout utilisateur attaché de se connecter AWS Management Console avec un accès en lecture seule aux données IAM.
**Pour créer la politique de votre utilisateur de test**
1. Connectez-vous à la console IAM à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse de votre utilisateur disposant d'autorisations d'administrateur.
1. Dans le panneau de navigation, sélectionnez **Policies** (Politiques).
1. Dans le panneau de contenu, sélectionnez **Créer une politique**.
1. Choisissez l'option **JSON** et copiez le texte du document de politique JSON suivant. Collez ce texte dans la zone de texte **JSON**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
```
------
1. Résolvez les avertissements de sécurité, les erreurs ou les avertissements généraux générés durant la [validation de la politique](access_policies_policy-validator.md), puis choisissez **Suivant**.
**Note**
Vous pouvez basculer à tout moment entre les options des éditeurs **visuel** et **JSON**. Toutefois, si vous apportez des modifications ou sélectionnez **Examiner une politique** dans l'onglet **Editeur visuel**, IAM peut restructurer votre politique pour optimiser son affichage dans l'éditeur visuel. Pour de plus amples informations, veuillez consulter [Restructuration de politique](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Sur la page **Vérifier et créer**, tapez **UsersReadOnlyAccessToIAMConsole** pour le nom de la politique. Vérifiez les autorisations accordées par votre politique, puis choisissez **Créer une politique** pour enregistrer votre travail.
La nouvelle politique s'affiche dans la liste des politiques gérées et est prête à être attachée.
## Étape 2 : Attacher la politique
Ensuite, vous attachez la politique que vous venez de créer à votre utilisateur IAM de test.
**Pour attacher la politique à votre utilisateur de test**
1. Dans le panneau de navigation de la console IAM, sélectionnez **Policies** (Politiques).
1. En haut de la liste des politiques, dans la zone de recherche, commencez à taper **UsersReadOnlyAccesstoIAMConsole** jusqu'à ce que vous puissiez voir votre politique. Cliquez ensuite sur le bouton radio situé à côté **UsersReadOnlyAccessToIAMConsole**dans la liste.
1. Cliquez sur le bouton **Actions**, puis choisissez **Attach** (Attacher).
1. Dans les entités IAM, choisissez l'option de filtrage pour les **Utilisateurs**.
1. Dans la zone de recherche, commencez à taper **PolicyUser** jusqu'à ce que cet utilisateur soit visible dans la liste. Cochez ensuite la case en regard de cet utilisateur dans la liste.
1. Choisissez **Attach policy** (Attacher la politique).
Vous avez attaché la politique à votre utilisateur de test IAM, ce qui signifie que l'utilisateur dispose maintenant d'un accès en lecture seule à la console IAM.
## Étape 3 : Tester l'accès utilisateur
Dans le cadre de ce didacticiel, nous vous recommandons de tester l'accès en vous connectant en tant que chacun des utilisateurs de test afin de vous rendre compte de l'expérience que vivent vos utilisateurs.
**Tester l'accès en vous connectant avec votre utilisateur test**
1. Connectez-vous à la console IAM à l'adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)avec votre utilisateur de `PolicyUser` test.
1. Parcourez les pages de la console et essayez de créer un nouvel utilisateur ou un nouveau groupe. Notez que `PolicyUser` peut afficher des données mais ne peut ni créer, ni modifier des données IAM existantes.
## Ressources connexes
Pour plus d'informations, consultez les ressources suivantes :
+ [Politiques gérées et politiques en ligne](access_policies_managed-vs-inline.md)
+ [Contrôlez l'accès des utilisateurs IAM au AWS Management Console](console_controlling-access.md)
## Résumé
Vous avez terminé toutes les étapes nécessaires pour créer et attacher une politique gérée par l'utilisateur. Par conséquent, vous pouvez vous connecter à la console IAM avec votre compte de test pour voir à quoi ressemble l'expérience de vos utilisateurs.
# Tutoriel IAM : définir les autorisations d'accès aux AWS ressources en fonction des balises
Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit des autorisations en fonction des attributs. Dans AWS, ces attributs sont appelés *balises*. Vous pouvez associer des balises aux ressources IAM, notamment aux entités IAM (utilisateurs ou rôles) et aux AWS ressources. Vous pouvez définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Lorsque vous utilisez des balises pour contrôler l'accès à vos AWS ressources, vous permettez à vos équipes et à vos ressources de se développer en modifiant moins les AWS politiques. Les politiques ABAC sont plus flexibles que AWS les politiques traditionnelles, qui vous obligent à répertorier chaque ressource individuelle. Pour de plus amples informations sur l'ABAC et ses avantages par rapport aux politiques traditionnelles, veuillez consulter [Définition des autorisations en fonction des attributs avec autorisation ABAC](introduction_attribute-based-access-control.md).
**Note**
Vous devez transmettre une valeur unique pour chaque balise de session. AWS Security Token Service ne prend pas en charge les balises de session à valeurs multiples.
**Topics**
+ [
## Aperçu du didacticiel
](#tutorial_attribute-based-access-control-overview)
+ [
## Conditions préalables
](#tutorial_abac_prereqs)
+ [
## Étape 1 : Créer des utilisateurs test
](#tutorial_abac_step1)
+ [
## Étape 2 : Créer la politique ABAC
](#tutorial_abac_step2)
+ [
## Étape 3 : Créer les rôles
](#tutorial_abac_step3)
+ [
## Étape 4 : Tester la création de secrets
](#tutorial_abac_step4)
+ [
## Étape 5 : Tester l'affichage des secrets
](#tutorial_abac_step5)
+ [
## Étape 6 : Tester l'adaptabilité
](#tutorial_abac_step6)
+ [
## Étape 7 : Tester la mise à jour et la suppression des secrets
](#tutorial_abac_step7)
+ [
## Résumé
](#tutorial-abac-summary)
+ [
## Ressources connexes
](#tutorial_abac_related)
+ [
# Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC
](tutorial_abac-saml.md)
## Aperçu du didacticiel
Ce didacticiel explique comment créer et tester une politique qui autorise des rôles IAM avec des balises de principal à accéder aux ressources dont les balises correspondent. Lorsqu'un principal fait une demande à AWS, les autorisations lui sont accordées si sa balise correspond à celle des ressources. Cette stratégie permet aux individus de consulter ou de modifier uniquement les AWS ressources nécessaires à leur travail.
**Scénario**
Supposons que vous soyez un développeur principal dans une grande entreprise nommée Exemple, ainsi qu'un administrateur IAM expérimenté. Vous savez créer et gérer des utilisateurs, des rôles et des politiques IAM. Vous voulez vous assurer que vos ingénieurs en développement et les membres de l'équipe d'assurance qualité peuvent accéder aux ressources dont ils ont besoin. Vous avez également besoin d'une stratégie qui évolue en même temps que votre entreprise.
Vous choisissez d'utiliser AWS des balises de ressources et des balises principales de rôle IAM pour mettre en œuvre une stratégie ABAC pour les services qui la prennent en charge, en commençant par. AWS Secrets Manager Pour connaître les services prenant en charge l'autorisation basée sur des balises, veuillez consulter [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour savoir quelles clés de condition de balisage vous pouvez utiliser dans une politique concernant les actions et les ressources de chaque service, consultez la section [Actions, ressources et clés de condition pour les AWS services](reference_policies_actions-resources-contextkeys.html). Vous pouvez configurer votre fournisseur d'identité Web ou basé sur SAML pour qu'il transmette les [étiquettes de session](id_session-tags.md) à l’interface AWS. Lorsque vos employés se fédérent dans AWS, leurs attributs sont appliqués au principal qui en résulte dans AWS. Vous pouvez ensuite utiliser l'ABAC pour autoriser ou refuser des autorisations sur la base de ces attributs. Pour savoir comment l'utilisation de balises de session avec une identité fédérée SAML diffère de ce didacticiel, veuillez consulter [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md).
Les membres de votre équipe d'ingénierie et d'assurance qualité sont sur le projet **Pegasus** ou le projet **Unicorn**. Vous sélectionnez les valeurs de balise de 3 caractères ci-dessous pour les projets et l'équipe :
+ `access-project` = `peg` pour le projet **Pegasus**
+ `access-project` = `uni` pour le projet **Unicorn**
+ `access-team` = `eng` pour l'équipe d'ingénierie
+ `access-team` = `qas` pour l'équipe d'assurance qualité
En outre, vous choisissez d'exiger l'étiquette de répartition des `cost-center` coûts pour activer les rapports AWS de facturation personnalisés. Pour plus d’informations, consultez [Utilisation des balises d’allocation des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) dans le *Guide de l’utilisateur AWS Billing and Cost Management *.
**Résumé des décisions clés**
+ Les employés se connectent avec leurs informations d'identification utilisateur IAM, puis endossent le rôle IAM pour leur équipe et leur projet. Si votre entreprise possède son propre système d'identité, vous pouvez configurer une fédération pour autoriser les employés à endosser un rôle sans utilisateurs IAM. Pour plus d’informations, veuillez consulter [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md).
+ La même politique est attachée à tous les rôles. Les actions sont autorisées ou refusées en fonction des balises.
+ Les employés peuvent créer des ressources, mais uniquement s'ils attachent à la ressource les balises qui sont appliquées à leur rôle. Ils peuvent ainsi afficher la ressource après l'avoir créée. Les administrateurs ne sont plus tenus de mettre à jour les politiques avec l'ARN des nouvelles ressources.
+ Les employés peuvent lire les ressources appartenant à leur équipe, quel que soit le projet.
+ Les employés peuvent mettre à jour et supprimer des ressources appartenant à leur équipe et à leur projet.
+ Les administrateurs IAM peuvent ajouter un nouveau rôle pour les nouveaux projets. Ils peuvent créer et baliser un nouvel utilisateur IAM pour lui permettre d'accéder au rôle approprié. Les administrateurs ne sont pas tenus de modifier une politique pour prendre en charge un nouveau projet ou membre de l'équipe.
Dans ce didacticiel, vous allez baliser chaque ressource, baliser les rôles de votre projet et ajouter des politiques aux rôles afin d'autoriser le comportement décrit précédemment. La politique qui en résulte autorise les rôles `Create`, `Read`, `Update` et `Delete` à accéder aux ressources qui ont les mêmes balises que le projet et l'équipe. La politique autorise également l'accès `Read` interprojet pour les ressources qui ont les mêmes balises que l'équipe.
![\[Le diagramme montre deux projets dans lesquels les rôles sont limités à un accès en lecture seule en dehors de leur projet, alors qu’ils ont des autorisations de création, de lecture, de mise à jour et de suppression des ressources dans leur propre projet.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/tutorial-abac-cross-project.png)
## Conditions préalables
Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :
+ Et Compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur disposant d'autorisations administratives.
+ Votre ID de compte à 12 chiffres, que vous utilisez pour créer les rôles à l'étape 3.
Pour trouver le numéro d'identification de votre AWS compte à l'aide du AWS Management Console, choisissez **Support** dans la barre de navigation en haut à droite, puis sélectionnez **Support Center**. Le numéro de compte (ID) apparaît dans le panneau de navigation à gauche.
![\[Support Page centrale indiquant le numéro de compte.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/account-id-support-center.console.png)
+ Une expérience dans la création et la modification d'utilisateurs, de rôles et de politiques IAM dans AWS Management Console. Toutefois, si vous avez besoin d'aide pour vous souvenir d'un processus de gestion IAM, ce didacticiel fournit des liens permettant de consulter step-by-step les instructions.
## Étape 1 : Créer des utilisateurs test
Pour le test, créez quatre utilisateurs IAM autorisés à endosser des rôles avec les mêmes balises. Cela facilite l'ajout d'utilisateurs à vos équipes. Lorsque vous balisez les utilisateurs, ces derniers bénéficient d'un automatiquement d'un accès pour endosser le rôle. Vous n'avez pas à ajouter les utilisateurs à la politique d'approbation du rôle s'ils travaillent sur un seul projet et dans une seule équipe.
1. Créez la politique gérée par le client ci-dessous et nommez-la `access-assume-role`. Pour de plus amples informations sur la création d'une politique JSON, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start).
**Politique ABAC : endosser n'importe quel rôle de la politique ABAC, mais uniquement lorsque les balises de l'utilisateur et du rôle correspondent**
La politique suivante autorise un utilisateur à endosser n'importe quel rôle de votre compte avec le préfixe de nom `access-`. Le rôle doit également être balisé avec les mêmes balises de projet, d'équipe et de centre de coûts que l'utilisateur.
Pour utiliser cette politique, remplacez le *texte en italique de l'espace réservé* dans l'exemple de politique par vos propres informations de compte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/access-*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}
]
}
```
------
Pour étendre ce didacticiel à un plus grand nombre d'utilisateurs, vous pouvez attacher la politique à un groupe et ajouter chaque utilisateur au groupe. Pour plus d’informations, consultez [Création de groupes IAM](id_groups_create.md) et [Modification des utilisateurs dans les groupes IAM](id_groups_manage_add-remove-users.md).
1. Créez les utilisateurs IAM suivants, attachez la politique d'autorisation `access-assume-role`. Assurez-vous de sélectionner **Fournir un accès utilisateur à la AWS Management Console**, puis d'ajouter les balises suivantes.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Étape 2 : Créer la politique ABAC
Créez la politique suivante et nommez-la **access-same-project-team**. Vous allez ajouter cette politique aux rôles ultérieurement. Pour de plus amples informations sur la création d'une politique JSON, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start).
Pour accéder à des politiques supplémentaires que vous pouvez adapter pour ce didacticiel, veuillez consulter les pages suivantes :
+ [Contrôle de l'accès pour les principaux IAM](access_iam-tags.md#access_iam-tags_control-principals)
+ [Amazon EC2 : autorise le démarrage ou l'arrêt des instances EC2 balisées par un utilisateur, par programmation et dans la console](reference_policies_examples_ec2_tag-owner.md)
+ [EC2 : démarrer ou arrêter les instances en fonction des balises de ressources et de principaux correspondantes](reference_policies_examples_ec2-start-stop-match-tags.md)
+ [EC2: démarrer ou arrêter des instances en fonction des balises](reference_policies_examples_ec2-start-stop-tags.md)
+ [IAM : endosser des rôles qui ont une balise spécifique](reference_policies_examples_iam-assume-tagged-role.md)
**Politique ABAC : accéder aux ressources Secrets Manager uniquement lorsque les balises du principal et des ressources correspondent**
La politique suivante autorise les principaux à créer, lire, modifier et supprimer des ressources, mais uniquement lorsque ces ressources sont balisées avec les mêmes paires clé-valeur que le principal. Lorsqu'un principal crée une ressource, il doit ajouter les balises `access-project`, `access-team` et `cost-center` avec des valeurs qui correspondent aux balises du principal. La politique autorise également l'ajout de balises `Name` ou `OwnedBy` facultatives.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
},
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}
```
------
**À quoi sert cette politique ?**
+ La instruction `AllActionsSecretsManagerSameProjectSameTeam` autorise toutes les actions de ce service sur toutes les ressources associées, mais uniquement si les balises des ressources correspondent aux balises du principal. En ajoutant `"Action": "secretsmanager:*"` à la politique, cette dernière évolue en même temps que Secrets Manager. Si Secrets Manager ajoute une nouvelle opération d'API, vous n'êtes pas obligé d'ajouter cette action à l'instruction. La instruction implémente l'ABAC en utilisant trois blocs de condition. La demande n'est autorisée que si les trois blocs renvoient la valeur « true » (vrai).
+ Le premier bloc de condition de cette instruction renvoie la valeur true si les clés de balise spécifiées sont présentes sur la ressource et que leurs valeurs correspondent aux balises du principal. Ce bloc renvoie la valeur « false » (faux) pour les étiquettes qui ne correspondent pas, ou pour les actions qui ne prennent pas en charge l’étiquettage des ressources. Pour savoir quelles actions ne sont pas autorisées par ce bloc, voir [Actions, ressources et clés de condition pour AWS Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html). Cette page montre que les actions effectuées sur le [type de ressource **Secret**](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-resources-for-iam-policies) prennent en charge la clé de condition `secretsmanager:ResourceTag/tag-key`. Certaines [actions Secrets Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssecretsmanager.html#awssecretsmanager-actions-as-permissions) ne prennent pas en charge ce type de ressource, y compris `GetRandomPassword` et `ListSecrets`. Vous devez créer des instructions supplémentaires pour autoriser ces actions.
+ Le deuxième bloc de condition renvoie la valeur « true » (vrai) si chaque clé d’identification transmise dans la demande figure dans la liste spécifiée. Cette opération est effectuée en utilisant `ForAllValues` avec l'opérateur de condition `StringEquals`. Si aucune clé ni sous-ensemble de l'ensemble de clés n'est transmis, la condition renvoie la valeur « true » (vrai). Cela permet les opérations `Get*` qui n'autorisent pas l’inclusion des étiquettes dans la demande. Si le demandeur inclut une clé d’identification qui ne figure pas dans la liste, la condition renvoie la valeur « false » (faux) Chaque clé de balise transmise dans la demande doit correspondre à un membre de cette liste. Pour de plus amples informations, veuillez consulter [Définir les opérateurs pour les clés de contexte à valeurs multiples](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ Le troisième bloc de condition renvoie la valeur « true » (vrai) si la demande prend en charge la transmission des étiquettes, si les trois étiquettes sont présentes et si elles correspondent aux valeurs de l’étiquette principale. Ce bloc renvoie également la valeur « true » (vrai) si la demande ne prend pas en charge la transmission des étiquettes. C'est grâce à [`...IfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) dans l'opérateur de condition. Le bloc renvoie la valeur « false » (faux) si aucune étiquette n'est transmise pendant une action qui la prend en charge, ou si les clés et les valeurs d’étiquette ne correspondent pas.
+ La instruction `AllResourcesSecretsManagerNoTags` autorise les actions `GetRandomPassword` et `ListSecrets` qui ne sont pas autorisées par la première instruction.
+ La instruction `ReadSecretsManagerSameTeam` autorise les opérations en lecture seule si le principal est balisé avec la même balise access-team que la ressource. Ceci est autorisé indépendamment de l’étiquette du projet ou du centre de coûts.
+ La instruction `DenyUntagSecretsManagerReservedTags` refuse les demandes de suppression de balises avec des clés commençant par « access- » de Secrets Manager. Ces balises servent à contrôler l'accès aux ressources. Leur suppression pourrait supprimer des autorisations.
+ La déclaration `DenyPermissionsManagement` refuse l'accès à la création, à la modification ou à la suppression de politiques basées sur les ressources de Secrets Manager. Ces politiques peuvent être utilisées pour modifier les autorisations du secret.
**Important**
Cette politique utilise une stratégie qui autorise toutes les actions d'un service, mais refuse explicitement les actions de modification des autorisations. Le refus d'une action remplace toute autre politique autorisant le principal à effectuer cette action. Ce refus peut entraîner des résultats imprévus. La bonne pratique consiste à utiliser uniquement le refus explicite lorsqu'aucune circonstance ne doit autoriser cette action. Sinon, dressez la liste des actions autorisées. Les actions indésirables seront refusées par défaut.
## Étape 3 : Créer les rôles
Créez les rôles IAM suivants et attachez la politique **access-same-project-team** que vous avez créée à l'étape précédente. Pour plus d'informations sur la création de rôles IAM, veuillez consulter [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md). Si vous sélectionnez d'utiliser la fédération plutôt que des utilisateurs et des rôles IAM, veuillez consulter [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md).
| Fonction de tâche | Nom du rôle | Balises de rôle | Description du rôle |
| --- | --- | --- | --- |
| Ingénierie du projet Pegasus | access-peg-engineering | access-project = `peg` access-team = `eng` cost-center = `987654` | Autorise les ingénieurs à lire toutes les ressources d'ingénierie et à créer et gérer les ressources d'ingénierie du projet Pegasus. |
| Assurance qualité du projet Pegasus | access-peg-quality-assurance | access-project = `peg` access-team = `qas` cost-center = `987654` | Autorise l'équipe d'assurance qualité à lire toutes les ressources d'assurance qualité et à créer et gérer toutes les ressources d'assurance qualité du projet Pegasus. |
| Ingénierie du projet Unicorn | access-uni-engineering | access-project = `uni` access-team = `eng` cost-center = `123456` | Autorise les ingénieurs à lire toutes les ressources d'ingénierie et à créer et gérer les ressources d'ingénierie du projet Unicorn. |
| Assurance qualité du projet Unicorn | access-uni-quality-assurance | access-project = `uni` access-team = `qas` cost-center = `123456` | Autorise l'équipe d'assurance qualité à lire toutes les ressources d'assurance qualité et à créer et gérer toutes les ressources d'assurance qualité du projet Unicorn. |
## Étape 4 : Tester la création de secrets
La politique d'autorisation attachée aux rôles autorise les employés à créer des secrets. Ceci n'est autorisé que si le secret est labelisé au niveau du projet, de l’équipe et du centre de coûts. Vérifiez que vos autorisations fonctionnent comme prévu en vous connectant comme vos utilisateurs, en endossant le bon rôle et en testant l'activité dans Secrets Manager.
**Pour tester la création d'un secret avec et sans les balises requises**
1. Dans la fenêtre principale de votre navigateur, restez connecté en tant qu'utilisateur administrateur afin que vous puissiez passer en revue les utilisateurs, les rôles et les politiques dans IAM. Utilisez une fenêtre de navigation privée ou un navigateur séparé pour votre test. Ensuite, connectez-vous en tant qu'utilisateur `access-Arnav-peg-eng` IAM et ouvrez la console Secrets Manager à [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)l'adresse.
1. Tentez de basculer vers le rôle `access-uni-engineering`.
Cette opération échoue, car les valeurs de balise `access-project` et `cost-center` ne correspondent pas à l'utilisateur `access-Arnav-peg-eng` et au rôle `access-uni-engineering`.
Pour plus d'informations sur le changement de rôle dans le AWS Management Console, voir [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md)
1. Basculez vers le rôle `access-peg-engineering`.
1. Enregistrez un nouveau secret en utilisant les informations suivantes. Pour savoir comment enregistrer un secret, veuillez consulter [Création d'un secret basique](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.
**Important**
Secrets Manager affiche des alertes indiquant que vous ne disposez pas d'autorisations pour des services AWS supplémentaires qui fonctionnent avec Secrets Manager. Par exemple, pour créer des informations d'identification pour une base de données Amazon RDS, vous devez être autorisé à décrire des instances RDS, des clusters RDS et des clusters Amazon Redshift. Vous pouvez ignorer ces alertes car vous n'utilisez pas ces AWS services spécifiques dans ce didacticiel.
1. Dans la section **Sélectionner un type de secret** sélectionnez **Autre type de secrets**. Dans les deux zones de texte, saisissez `test-access-key` et `test-access-secret`.
1. Saisissez `test-access-peg-eng` dans le champ **Nom du secret** .
1. Ajoutez différentes combinaisons de balises du tableau suivant et visualisez le comportement attendu.
1. Choisissez **Stocker** pour tenter de créer le secret. Si le stockage échoue, revenez aux pages précédentes de la console Secrets Manager et utilisez l'ensemble de balises suivant dans le tableau ci-dessous. Le dernier ensemble de balises est autorisé et crée le secret avec succès.
Le tableau suivant présente les combinaisons de balises ABAC pour le rôle `test-access-peg-eng`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. Déconnectez-vous et répétez les trois premières étapes de cette procédure pour chaque rôle et chaque valeur de balise ci-dessous. À la quatrième étape de cette procédure, testez tous les ensembles de balises manquantes, de balises facultatives, de balises non autorisées et de valeurs de balises non valides de votre choix. Puis, utilisez les balises requises pour créer un secret avec les balises et le nom suivants.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Étape 5 : Tester l'affichage des secrets
La politique que vous avez attachée à chaque rôle autorise les employés à afficher tous les secrets labelisés avec leur nom d'équipe, quel que soit leur projet. Vérifiez que vos autorisations fonctionnent comme prévu en testant vos rôles dans Secrets Manager.
**Pour tester l'affichage d'un secret avec et sans les balises requises**
1. Connectez-vous en tant que l'un des utilisateurs IAM suivants :
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
1. Basculez vers le rôle correspondant :
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-uni-quality-assurance`
Pour plus d'informations sur le changement de rôle dans le AWS Management Console, consultez[Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md).
1. Dans le panneau de navigation de gauche, sélectionnez l'icône de menu permettant de développer le menu, puis sélectionnez **Secrets**.
1. Vous devriez voir les quatre secrets du tableau, quel que soit votre rôle actuel. C'est le comportement attendu, car la politique nommée `access-same-project-team` autorise l'action `secretsmanager:ListSecrets` pour toutes les ressources.
1. Choisissez l'un des secrets.
1. Sur la page détaillée du secret, les étiquettes de votre rôle déterminent si vous pouvez afficher le contenu de la page. Comparez le nom de votre rôle avec celui de votre secret. S'ils ont le même nom d'équipe, alors les balises `access-team` correspondent. Si elles ne correspondent pas, l'accès est refusé.
Le tableau suivant montre le comportement d’affichage du secret ABAC pour chaque rôle.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
1. Dans les miniatures en haut de la page, sélectionnez **Secrets** pour revenir à la liste des secrets. Répétez les étapes de cette procédure en utilisant différents rôles pour vérifier si vous pouvez afficher chacun des secrets.
## Étape 6 : Tester l'adaptabilité
L'évolutivité est une raison majeure de privilégier le contrôle d'accès basé sur les attributs (ABAC) par rapport au contrôle d'accès basé sur les rôles (RBAC). Au fur et à mesure que votre entreprise ajoute de nouveaux projets, équipes ou personnes AWS, vous n'avez pas besoin de mettre à jour vos politiques basées sur l'ABAC. Par exemple, supposons que la société Exemple finance un nouveau projet, dont le nom de code est **Centaur**. Un ingénieur nommé Saanvi Sarkar sera l'ingénieur principal du projet **Centaur** tout en continuant à travailler sur le projet **Unicorn** . Saanvi passera également en revue les travaux du projet **Pegasus**. Plusieurs ingénieurs embauchés récemment, dont Nikhil Jayashankar, travailleront exclusivement sur le projet **Centaur** .
**Pour ajouter le nouveau projet à AWS**
1. Connectez-vous en tant qu'utilisateur administrateur IAM et ouvrez la console IAM à l'adresse. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Dans le panneau de navigation de gauche, sélectionnez **Roles** (Rôles) et ajoutez un rôle IAM nommé `access-cen-engineering`. Attachez la politique d'autorisation **access-same-project-team** au rôle et ajoutez les balises de rôle suivantes :
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. Dans le volet de navigation de gauche, choisissez **Utilisateurs**.
1. Ajoutez un nouvel utilisateur nommé `access-Nikhil-cen-eng`, attachez la politique nommée `access-assume-role`, et ajoutez les balises utilisateur suivantes.
+ `access-project` = `cen`
+ `access-team` = `eng`
+ `cost-center` = `101010`
1. Utilisez les procédures des sections [Étape 4 : Tester la création de secrets](#tutorial_abac_step4) et [Étape 5 : Tester l'affichage des secrets](#tutorial_abac_step5). Dans une autre fenêtre de navigateur, vérifiez que Nikhil ne peut créer que des secrets d'ingénierie pour le projet **Centaur** et qu'il peut afficher tous les secrets d'ingénierie.
1. Dans la fenêtre principale du navigateur à partir de laquelle vous vous êtes connecté en tant qu'administrateur, sélectionnez l'utilisateur `access-Saanvi-uni-eng`.
1. Dans l'onglet **Autorisations**, supprimez la politique **access-assume-role**d'autorisations.
1. Ajoutez la politique en ligne ci-dessous et nommez-la `access-assume-specific-roles`. Pour de plus amples informations sur l'intégration d'une politique en ligne pour un utilisateur, veuillez consulter [Pour intégrer une politique en ligne pour un utilisateur ou un rôle (console)](access_policies_manage-attach-detach.md#embed-inline-policy-console).
**Politique ABAC : endosser uniquement des rôles spécifiques**
Cette politique autorise Saanvi à assumer les rôles d'ingénierie pour les projets **Pegasus** et **Centaure**. Il est nécessaire de créer cette politique personnalisée, car IAM ne prend pas en charge les balises à valeurs multiples. Vous ne pouvez pas baliser l'utilisateur Saanvi avec `access-project` = `peg` et `access-project` = `cen`. De plus, le modèle AWS d'autorisation ne peut pas correspondre aux deux valeurs. Pour de plus amples informations, veuillez consulter [Règles de balisage dans IAM et AWS STS](id_tags.md#id_tags_rules). Vous devez spécifier manuellement les deux rôles qu'elle peut endosser.
Pour utiliser cette politique, remplacez le *texte en italique de l'espace réservé* dans l'exemple de politique par vos propres informations de compte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/access-peg-engineering",
"arn:aws:iam::111122223333:role/access-cen-engineering"
]
}
]
}
```
------
1. Utilisez les procédures des sections [Étape 4 : Tester la création de secrets](#tutorial_abac_step4) et [Étape 5 : Tester l'affichage des secrets](#tutorial_abac_step5). Dans une autre fenêtre du navigateur, vérifiez que Saanvi peut endosser les deux rôles. Vérifiez qu'elle peut créer des secrets uniquement pour son projet, son équipe et son centre de coûts, en fonction des balises du rôle. Vérifiez également qu'elle peut afficher les détails de tous les secrets appartenant à l'équipe d'ingénierie, y compris ceux qu'elle vient de créer.
## Étape 7 : Tester la mise à jour et la suppression des secrets
La politique `access-same-project-team` attachée aux rôles autorise les employés à mettre à jour et à supprimer tous les secrets possédant les mêmes balises que leur projet, leur équipe et leur centre de coûts. Vérifiez que vos autorisations fonctionnent comme prévu en testant vos rôles dans Secrets Manager.
**Pour tester la mise à jour et la suppression d'un secret avec et sans les balises requises**
1. Connectez-vous en tant que l'un des utilisateurs IAM suivants :
+ `access-Arnav-peg-eng`
+ `access-Mary-peg-qas`
+ `access-Saanvi-uni-eng`
+ `access-Carlos-uni-qas`
+ `access-Nikhil-cen-eng`
1. Basculez vers le rôle correspondant :
+ `access-peg-engineering`
+ `access-peg-quality-assurance`
+ `access-uni-engineering`
+ `access-peg-quality-assurance`
+ `access-cen-engineering`
Pour plus d'informations sur le changement de rôle dans le AWS Management Console, consultez[Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md).
1. Pour chaque rôle, mettez à jour la description du secret, puis supprimez les secrets suivants. Pour de plus amples informations, veuillez consulter [Modification d'un secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html) et [Suppression et restauration d'un secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.
Le tableau suivant montre le comportement de mise à jour et de suppression du secret ABAC pour chaque rôle.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)
## Résumé
Vous avez à présent terminé toutes les étapes nécessaires pour utiliser des balises pour le contrôle d'accès basé sur les attributs (ABAC). Vous avez appris à définir une stratégie de balisage. Vous avez appliqué cette stratégie à vos principaux et à vos ressources. Vous avez créé et appliqué une politique qui met exécute la stratégie pour Secrets Manager. Vous avez également appris que l'ABAC évolue facilement lorsque vous ajoutez de nouveaux projets et membres d'équipe. Désormais, vous pouvez vous connecter à la console IAM avec vos rôles test et tester l'utilisation de balises ABAC dans AWS.
**Note**
Vous avez ajouté des politiques qui autorisent les actions uniquement dans des conditions spécifiques. Si vous appliquez une politique différente à vos utilisateurs ou rôles disposant d'autorisations plus larges, il se peut que les actions ne soient pas limitées pour demander le balisage. Par exemple, si vous accordez à un utilisateur des autorisations administratives complètes à l'aide de la politique `AdministratorAccess` AWS gérée, ces politiques ne limitent pas cet accès. Pour plus d'informations sur la façon dont les autorisations sont déterminées lorsque plusieurs politiques sont impliquées, veuillez consulter [Comment la logique du code d' AWS application évalue les demandes d'autorisation ou de refus d'accès](reference_policies_evaluation-logic_policy-eval-denyallow.md).
## Ressources connexes
Pour plus d'informations, consultez les ressources suivantes :
+ [Définition des autorisations en fonction des attributs avec autorisation ABAC](introduction_attribute-based-access-control.md)
+ [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md)
+ [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md)
+ [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md)
+ [Contrôle de l'accès aux AWS ressources à l'aide de balises](access_tags.md)
+ [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md)
+ [Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC](tutorial_abac-saml.md)
Pour savoir comment surveiller les balises de votre compte, consultez [Surveiller les modifications des balises sur les AWS ressources avec des flux de travail sans serveur et Amazon CloudWatch Events](https://aws.amazon.com/blogs/mt/monitor-tag-changes-on-aws-resources-with-serverless-workflows-and-amazon-cloudwatch-events/).
# Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit des autorisations en fonction des attributs. Dans AWS, ces attributs sont appelés balises. Vous pouvez associer des balises aux ressources IAM, notamment aux entités IAM (utilisateurs ou rôles), et aux AWS ressources. Lorsque les entités sont utilisées pour envoyer des demandes AWS, elles deviennent des entités principales et ces entités incluent des balises.
Vous pouvez également transmettre des [balises de session](id_session-tags.md) lorsque vous endossez un rôle ou fédérez un utilisateur. Vous pouvez ensuite définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Lorsque vous utilisez des balises pour contrôler l'accès à vos ressources AWS , vous autorisez vos équipes et vos ressources à se développer en modifiant moins les politiques AWS . Les politiques ABAC sont plus flexibles que AWS les politiques traditionnelles, qui vous obligent à répertorier chaque ressource individuelle. Pour de plus amples informations sur l'ABAC et ses avantages par rapport aux politiques traditionnelles, veuillez consulter [Définition des autorisations en fonction des attributs avec autorisation ABAC](introduction_attribute-based-access-control.md).
Si votre entreprise utilise un fournisseur d'identité (IdP, identity provider) basé sur SAML pour gérer les identités des utilisateurs de l'entreprise, vous pouvez utiliser les attributs SAML pour un contrôle d'accès affiné dans l’interface AWS. Les attributs peuvent inclure des identifiants de centre de coûts, des adresses e-mail d'utilisateurs, des classifications de services et des affectations de projet. Lorsque vous transmettez ces attributs en tant qu’étiquettes de session, vous pouvez ensuite contrôler l'accès à l’interface AWS en fonction de ces étiquettes de session.
Pour réaliser le [didacticiel de l'ABAC](tutorial_attribute-based-access-control.md) en transmettant les attributs SAML à votre principal de session, effectuez les tâches de la section [Tutoriel IAM : définir les autorisations d'accès aux AWS ressources en fonction des balises](tutorial_attribute-based-access-control.md) avec les modifications citées dans cette rubrique.
## Conditions préalables
Pour réaliser les étapes d'utilisation des étiquettes de session SAML pour l'ABAC, vous devez déjà disposer des éléments suivants :
+ Un accès à un fournisseur d'identité basé sur SAML vous permettant de créer des utilisateurs test avec des attributs spécifiques.
+ La possibilité de se connecter en tant qu'utilisateur disposant d'autorisations d'administrateur.
+ Une expérience dans la création et la modification d'utilisateurs, de rôles et de politiques IAM dans AWS Management Console. Toutefois, si vous avez besoin d'aide pour vous souvenir d'un processus de gestion IAM, le didacticiel ABAC fournit des liens vers lesquels vous pouvez consulter step-by-step les instructions.
+ Une expérience dans la configuration d'un fournisseur d'identité SAML dans IAM. Pour afficher de plus amples informations et des liens vers la documentation détaillée IAM, veuillez consulter [Transmission de balises de session à l'aide de AssumeRoleWith SAML](id_session-tags.md#id_session-tags_adding-assume-role-saml).
## Étape 1 : Créer des utilisateurs test
Ignorez les instructions de la section [Étape 1 : Créer des utilisateurs test](tutorial_attribute-based-access-control.md#tutorial_abac_step1). Étant donné que vos identités sont définies dans votre fournisseur, il n'est pas nécessaire que vous ajoutiez des utilisateurs IAM pour vos employés.
## Étape 2 : Créer la politique ABAC
Suivez les instructions de la section [Étape 2 : Créer la politique ABAC](tutorial_attribute-based-access-control.md#tutorial_abac_step2) pour créer la politique gérée spécifiée dans IAM.
## Étape 3 : Créer et configurer le rôle SAML
Lorsque vous utilisez le didacticiel ABAC pour SAML, vous devez effectuer des étapes supplémentaires pour créer le rôle, configurer l'IdP SAML et activer l'accès. AWS Management Console Pour de plus amples informations, veuillez consulter [Étape 3 : Créer les rôles](tutorial_attribute-based-access-control.md#tutorial_abac_step3).
### Étape 3A : Créer le rôle SAML
Créez un rôle unique qui approuve votre fournisseur d'identité SAML et l'utilisateur `test-session-tags` que vous avez créé à l'étape 1. Le didacticiel de l'ABAC utilise des rôles distincts avec des balises de rôle différentes. Étant donné que vous transmettez des balises de session à partir de votre fournisseur d'identité SAML, vous n'avez besoin que d'un seul rôle. Pour savoir comment créer un rôle basé sur SAML, veuillez consulter [Création d’un rôle pour la fédération SAML 2.0 (console)](id_roles_create_for-idp_saml.md).
Nommez le rôle `access-session-tags`. Attachez la politique d'autorisation `access-same-project-team` au rôle. Modifiez la politique d'approbation de rôle pour utiliser la politique suivante. Pour obtenir des instructions détaillées sur la modification de la relation d'approbation d'un rôle, veuillez consulter [Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md).
La politique d'approbation de rôle suivante permet à votre fournisseur d'identité SAML et à l'utilisateur `test-session-tags` d'endosser le rôle. Lorsqu'ils endossent le rôle, ils doivent transmettre les trois balises de session spécifiées. L'action `sts:TagSession` est requise pour autoriser la transmission des balises de session.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSamlIdentityAssumeRole",
"Effect": "Allow",
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"},
"Condition": {
"StringLike": {
"aws:RequestTag/cost-center": "*",
"aws:RequestTag/access-project": "*",
"aws:RequestTag/access-team": [
"eng",
"qas"
]
},
"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
}
}
]
}
```
------
La `AllowSamlIdentityAssumeRole` déclaration permet aux membres des équipes d'ingénierie et d'assurance qualité d'assumer ce rôle lorsqu'ils se fédérent avec l'IdP AWS d'Example Corporation. Le fournisseur SAML `ExampleCorpProvider` est défini dans IAM. L'administrateur a déjà configuré l'assertion SAML pour transmettre les trois balises de session requises. L'assertion peut transmettre des balises supplémentaires, mais ces trois balises doivent être présentes. Les attributs de l'identité peuvent avoir n'importe quelle valeur pour les balises `cost-center` et `access-project`. Toutefois, la valeur de l'attribut `access-team` doit correspondre à `eng` ou `qas` pour indiquer que l'identité se trouve dans l'équipe d'ingénierie ou d'assurance qualité.
### Étape 3B : Configurer le fournisseur d'identité SAML
Configurez votre fournisseur d'identité SAML pour qu'il transmette les attributs `cost-center`, `access-project` et `access-team` en tant que balises de session. Pour de plus amples informations, veuillez consulter [Transmission de balises de session à l'aide de AssumeRoleWith SAML](id_session-tags.md#id_session-tags_adding-assume-role-saml).
Pour transmettre ces attributs en tant que balises de session, incluez les éléments suivants dans votre assertion SAML.
```
987654
peg
eng
```
### Étape 3C : Activer l'accès à la console
Activez l'accès à la console pour vos utilisateurs SAML fédérés. Pour de plus amples informations, veuillez consulter [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md).
## Étape 4 : Tester la création de secrets
Fédérez-vous pour AWS Management Console utiliser le `access-session-tags` rôle. Pour de plus amples informations, veuillez consulter [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md). Puis, suivez les instructions de la section [Étape 4 : Tester la création de secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step4) pour créer des secrets. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC. Pour plus d’informations, veuillez consulter [Étape 4 : Tester la création de secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step4).
## Étape 5 : Tester l'affichage des secrets
Suivez les instructions de la section [Étape 5 : Tester l'affichage des secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step5) pour afficher les secrets que vous avez créés à l'étape précédente. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC.
## Étape 6 : Tester l'adaptabilité
Suivez les instructions de la section [Étape 6 : Tester l'adaptabilité](tutorial_attribute-based-access-control.md#tutorial_abac_step6) pour tester l'évolutivité. Pour ce faire, ajoutez une nouvelle identité à votre fournisseur d'identité basé sur SAML avec les attributs suivants :
+ `cost-center = 101010`
+ `access-project = cen`
+ `access-team = eng`
## Étape 7 : Tester la mise à jour et la suppression des secrets
Suivez les instructions de l'étape [Étape 7 : Tester la mise à jour et la suppression des secrets](tutorial_attribute-based-access-control.md#tutorial_abac_step7) pour mettre à jour et supprimer des secrets. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC.
**Important**
Supprimez tous les secrets que vous avez créés pour éviter les frais de facturation. Pour de plus amples informations sur la tarification de Secrets Manager, veuillez consulter [Tarification AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Résumé
Vous avez maintenant terminé avec succès toutes les étapes nécessaires pour utiliser les balises de session SAML et les balises de ressources pour la gestion des autorisations.
**Note**
Vous avez ajouté des politiques qui autorisent les actions uniquement dans des conditions spécifiques. Si vous appliquez une politique différente à vos utilisateurs ou rôles disposant d'autorisations plus larges, il se peut que les actions ne soient pas limitées pour demander le balisage. Par exemple, si vous accordez à un utilisateur des autorisations administratives complètes à l'aide de la politique `AdministratorAccess` AWS gérée, ces politiques ne limitent pas cet accès. Pour plus d'informations sur la façon dont les autorisations sont déterminées lorsque plusieurs politiques sont impliquées, veuillez consulter [Comment la logique du code d' AWS application évalue les demandes d'autorisation ou de refus d'accès](reference_policies_evaluation-logic_policy-eval-denyallow.md).
# Didacticiel IAM : permettre aux utilisateurs de gérer leurs informations d'identification et leurs paramètres MFA
Vous pouvez autoriser les utilisateurs à gérer eux-mêmes leurs propres informations d’identification et dispositifs d’authentification multifactorielle (MFA) sur la page **Informations d’identification de sécurité**. Vous pouvez les utiliser AWS Management Console pour configurer les informations d'identification (clés d'accès, mots de passe, certificats de signature et clés publiques SSH), supprimer ou désactiver les informations d'identification inutiles et activer les dispositifs MFA pour vos utilisateurs. Cette méthode est utile pour un petit nombre d'utilisateurs, mais la tâche peut rapidement devenir fastidieuse si le nombre d'utilisateurs augmente. Ce didacticiel vous montre comment mettre en place ces bonnes pratiques sans surcharger de travail vos administrateurs.
Ce didacticiel explique comment autoriser les utilisateurs à accéder aux AWS services, mais **uniquement** lorsqu'ils se connectent à l'aide de la MFA. S'ils ne sont pas connectés avec un dispositif MFA, les utilisateurs ne peuvent pas accéder à d'autres services.
Ce flux de travail se compose de trois étapes de base.
**[Étape 1 : Créer une politique pour appliquer l'authentification MFA](#tutorial_mfa_step1)**
Créez une politique gérée par le client qui interdit toutes les actions ***à l'exception*** des quelques actions IAM. Ces exceptions permettent à un utilisateur de modifier ses propres informations d’identification et de gérer ses dispositifs MFA sur la page **Informations d’identification de sécurité**. Plus d'informations sur la manière d'accéder à cette page, veuillez consulter [Comment les utilisateurs IAM modifient leur mot de passe (console)](id_credentials_passwords_user-change-own.md#ManagingUserPwdSelf-Console).
**[Étape 2 : Attacher des politiques à votre groupe d'utilisateurs test](#tutorial_mfa_step2)**
Créez un groupe d'utilisateurs dont les membres ont un accès total à toutes les actions Amazon EC2 s'ils se connectent avec MFA. Pour créer un tel groupe d'utilisateurs, vous devez associer à la fois la politique AWS gérée appelée `AmazonEC2FullAccess` et la politique gérée par le client que vous avez créée lors de la première étape.
**[Étape 3 : Test de l'accès utilisateur](#tutorial_mfa_step3)**
Connectez-vous en tant qu'utilisateur test pour vérifier que l'accès à Amazon EC2 est bloqué *jusqu'à* ce que l'utilisateur crée un dispositif MFA. L'utilisateur peut alors se connecter à l'aide de ce dispositif.
## Conditions préalables
Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :
+ Et Compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur IAM avec des autorisations administratives.
+ Votre ID de compte, que vous entrez dans la politique à l'étape 1.
Pour trouver votre ID de compte, sur la barre de navigation située en haut de la page, sélectionnez **Support**, puis sélectionnez **Support Center (Centre de support)**. L'ID de compte se trouve dans le menu **Support** de cette page.
+ Un [périphérique MFA virtuel (logiciel)](id_credentials_mfa_enable_virtual.md), une [clé de sécurité FIDO](id_credentials_mfa_enable_fido.md) ou un [dispositif MFA matériel](id_credentials_mfa_enable_physical.md).
+ Un utilisateur IAM test et membre du groupe d'utilisateurs suivant :
| Nom utilisateur | Instructions du nom d’utilisateur | Nom du groupe d'utilisateurs | Ajouter l'utilisateur en tant que membre | Instructions pour les groupes d’utilisateurs |
| --- | --- | --- | --- | --- |
| MFAUser | Choisissez uniquement l'option pour Activer l'accès à la console (facultatif) et attribuez un mot de passe. | EC2MFA | MFAUser | N'attachez PAS de politique ni n'accordez d'autorisations à ce groupe d'utilisateurs. |
## Étape 1 : Créer une politique pour appliquer l'authentification MFA
Vous commencez par créer une politique gérée par le client IAM qui refuse toutes les autorisations, sauf celles requises par les utilisateurs IAM pour gérer leurs informations d'identification et appareils MFA.
1. Connectez-vous à la console de AWS gestion en tant qu'utilisateur avec des informations d'identification d'administrateur. Pour respecter les meilleures pratiques IAM, ne vous connectez pas avec vos Utilisateur racine d'un compte AWS informations d'identification.
**Important**
[Les meilleures pratiques](best-practices.md) IAM recommandent de demander aux utilisateurs humains d'utiliser la fédération avec un fournisseur d'identité pour accéder à l'aide d'informations d'identification temporaires plutôt que d' AWS utiliser des utilisateurs IAM dotés d'informations d'identification à long terme. Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les [cas d’utilisation spécifiques](gs-identities-iam-users.md) non pris en charge par les utilisateurs fédérés.
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, sélectionnez **Policies** (Politiques), puis **Create policy** (Créer une politique).
1. Sélectionnez l'onglet **JSON**, et copiez le texte du document de politique JSON suivant : [AWS : autorise les utilisateurs IAM authentifiés par MFA à gérer leurs propres informations d’identification sur la page Informations d’identification de sécurité](reference_policies_examples_aws_my-sec-creds-self-manage.md).
1. Collez cette politique dans la zone de texte **JSON**. Résolvez tous les avertissements de sécurité, les erreurs ou les avertissements généraux générés durant la validation de la politique, puis choisissez **Suivant**.
**Note**
Vous pouvez basculer à tout moment entre les options **Éditeur visuel** et **JSON**. Cependant, la politique ci-dessus inclut l'élément `NotAction` qui n'est pas pris en charge dans l'éditeur visuel. Pour cette politique, vous verrez une notification dans l'onglet **Visual editor (Éditeur visuel)**. Revenez à **JSON** pour continuer à travailler avec cette politique.
Cet exemple de politique n'autorise pas les utilisateurs à réinitialiser un mot de passe lorsqu'ils se connectent à l' AWS Management Console pour la première fois. Nous vous recommandons de n'accorder des autorisations aux nouveaux utilisateurs qu'après leur enregistrement et aient réinitialisé leur mot de passe.
1. Sur la page **Vérifier et créer**, tapez **Force\$1MFA** pour le nom de la politique. Pour la description de la politique, tapez **This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.** dans la zone **Balises** ; vous pouvez éventuellement ajouter des paires clé-valeur de balises à la politique gérée par le client. Vérifiez les autorisations accordées par votre politique, puis choisissez **Créer une politique** pour enregistrer votre travail.
La nouvelle politique s'affiche dans la liste des politiques gérées et est prête à être attachée.
## Étape 2 : Attacher des politiques à votre groupe d'utilisateurs test
Vous allez maintenant attacher deux politiques à votre groupe d'utilisateurs IAM test. Elles seront utilisées pour octroyer des autorisations protégées par MFA.
1. Dans le panneau de navigation, sélectionnez **User groups** (Groupes d'utilisateurs).
1. Dans la zone de recherche, saisissez **`EC2MFA`**, puis sélectionnez le nom du groupe (et pas la case à cocher) dans la liste.
1. Choisissez l'onglet **Autorisations**, puis **Ajouter des autorisations**, et enfin **Attacher des politiques**.
1. Sur la page **Attacher des politiques d'autorisation au groupe EC2 MFA**, dans le champ de recherche, tapez. **EC2Full** Cochez ensuite la case à côté d'**Amazon EC2 FullAccess** dans la liste. N'enregistrez pas vos modifications pour le moment.
1. Dans la zone de recherche, saisissez **Force**, puis cochez la case située en regard de **Force\$1MFA** dans la liste.
1. Sélectionnez **Attach Policies (Attacher des politiques)**.
## Étape 3 : Test de l'accès utilisateur
Dans cette étape du didacticiel, vous vous connectez en tant qu'utilisateur test afin de vérifier que la politique fonctionne comme prévu.
1. Connectez-vous à votre annonce **MFAUser** avec Compte AWS le mot de passe que vous avez attribué dans la section précédente. Utilisez l'URL : `https://.signin.aws.amazon.com/console`
1. Sélectionnez **EC2** pour ouvrir la console Amazon EC2 et vérifiez que l'utilisateur ne dispose d'aucune autorisation.
1. Dans la barre de navigation en haut à droite, sélectionnez votre nom d'utilisateur `MFAUser`, puis **Security Credentials** (Informations d'identification de sécurité).
![\[AWS Lien vers les identifiants de sécurité de la console de gestion.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)
1. Maintenant, ajoutez un dispositif MFA. Dans la section **Multi-Factor Authentication (MFA) (Authentification multi-facteurs (MFA))** sélectionnez **Assign MFA device (Attribuer un dispositif MFA)**.
**Note**
Vous pouvez recevoir une erreur que vous n'êtes pas autorisé à effectuer `iam:DeleteVirtualMFADevice`. Cela peut se produire si quelqu'un a commencé précédemment à attribuer un dispositif MFA virtuel pour cet utilisateur et a annulé le processus. Pour continuer, vous ou un autre administrateur devez supprimer le dispositif MFA virtuel non attribué existant de l'utilisateur. Pour de plus amples informations, veuillez consulter [Je ne suis pas autorisé à exécuter : iam : DeleteVirtual MFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa).
1. Dans le cadre de ce didacticiel, nous utilisons un appareil MFA (basé sur un logiciel) virtuel, comme l'application Google Authenticator sur un téléphone portable. Choisissez l'**application Authenticator**, puis cliquez sur **Next** (Suivant).
IAM génère et affiche les informations de configuration du dispositif MFA virtuel, notamment un graphique de code QR. Le graphique est une représentation de la clé de configuration secrète que l'on peut saisir manuellement sur des dispositifs qui ne prennent pas en charge les codes QR.
1. Ouvrez votre application MFA virtuelle. (Pour obtenir une liste des applications que vous pouvez utiliser pour héberger des dispositifs MFA virtuels, veuillez consulter [Applications MFA virtuelles](https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications).) Si l'application MFA virtuelle prend en charge plusieurs comptes (plusieurs dispositifs MFA virtuels), sélectionnez l'option permettant de créer un compte (un nouveau dispositif MFA virtuel).
1. Déterminez si l'application MFA prend en charge les codes QR, puis effectuez l'une des actions suivantes :
+ Dans l'assistant, sélectionnez **Show QR code (Afficher le code QR)**. Utilisez ensuite l'application pour analyser le code QR. Par exemple, vous pouvez choisir l'icône de caméra ou une option similaire à **Scan code**, puis utiliser la caméra du dispositif pour analyser le code.
+ Dans l'assistant **Set up device** (Configurer le dispositif), sélectionnez **Show secret key** (Afficher la clé secrète), puis saisissez la clé secrète dans votre application MFA.
Une fois que vous avez terminé, le dispositif MFA virtuel commence à générer des mots de passe uniques.
1. Dans l'assistant **Configurer le dispositif**, dans la zone **Saisir le code à partir de votre application d'authentification**, saisissez le mot de passe unique qui s'affiche actuellement sur le dispositif MFA virtuel. Sélectionnez **Register MFA** (Enregistrer le dispositif MFA).
**Important**
Envoyez votre demande immédiatement après avoir généré le code. Si vous générez les codes puis attendez trop longtemps avant d'envoyer la requête, l'appareil MFA est associé avec succès à l'utilisateur. Cependant, l'appareil MFA n'est pas synchronisé. En effet, les TOTP (Time-based One-Time Passwords ou mots de passe à usage unique à durée limitée) expirent après une courte période. Dans ce cas, vous pouvez [resynchroniser le dispositif](id_credentials_mfa_sync.md).
Le périphérique MFA virtuel est maintenant prêt à être utilisé avec. AWS
1. Déconnectez-vous de la console, puis reconnectez-vous en tant que **MFAUser**. Cette fois, vous AWS êtes invité à saisir un code MFA sur votre téléphone. Lorsque vous recevez le code, entrez-le dans le champ et sélectionnez **Submit (Soumettre)**.
1. Sélectionnez **EC2** pour rouvrir la console Amazon EC2. Notez que, cette fois, vous pouvez voir toutes les informations et effectuer les actions que vous souhaitez. Si vous accédez à une autre console en tant qu'utilisateur, les messages d'accès refusé s'affichent. La raison en est que les politiques de ce didacticiel n'accordent l'accès qu'à Amazon EC2.
## Ressources connexes
Pour plus d'informations, veuillez consulter les rubriques suivantes :
+ [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md)
+ [Connexion compatible avec la MFA](console_sign-in-mfa.md)
# Tutoriel IAM : Utiliser un CloudFormation modèle pour créer un fournisseur d'identité SAML (IdP)
Pour configurer la fédération SAML pour votre AWS compte, vous devez créer un fournisseur d'identité SAML (IdP). Ce didacticiel explique comment utiliser un CloudFormation modèle pour créer un IdP SAML qui établit la confiance AWS entre et votre IdP externe.
Le modèle crée un IdP SAML configuré avec le document de métadonnées de votre IdP. Les rôles IAM fédérés peuvent ensuite référencer cet IdP pour permettre aux utilisateurs authentifiés depuis votre IdP externe d'accéder aux ressources. AWS
La ressource déployée consiste en un IdP SAML configuré avec le document de métadonnées de votre IdP et des paramètres de chiffrement facultatifs.
## Conditions préalables
Le didacticiel présume que vous avez déjà ce qui suit en place :
+ Python 3.6 ou version ultérieure installée sur votre ordinateur local pour exécuter la commande Python utilisée dans ce didacticiel afin de formater le fichier XML des métadonnées SAML de votre IdP.
+ Un document de métadonnées SAML provenant de votre IdP externe enregistré sous forme de fichier XML.
## Créez un IdP SAML en utilisant CloudFormation
Pour créer l'IdP SAML, vous allez créer CloudFormation un modèle et l'utiliser pour créer une pile contenant la ressource IdP.
### Création du modèle
Créez d'abord le CloudFormation modèle.
1. Dans la section [Modèle](#tutorial_saml-idp-template), cliquez sur l’icône de copie dans l’onglet **JSON** ou **YAML** pour copier le contenu du modèle.
1. Copiez le contenu du modèle dans un nouveau fichier.
1. Enregistrez le fichier au niveau local.
### Créez la pile .
Ensuite, utilisez le modèle que vous avez enregistré pour approvisionner une CloudFormation pile.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sur la page **Piles**, dans le menu **Créer une pile**, choisissez **Avec de nouvelles ressources (standard)**.
1. Spécifiez un modèle :
1. Sous **Prérequis**, choisissez **Choisir un modèle existant**.
1. Sous **Spécifier le modèle**, sélectionnez **Charger un modèle de fichier**.
1. Choisissez **Choisir un fichier**, accédez au fichier du modèle, puis sélectionnez-le.
1. Choisissez **Suivant**.
1. Spécifiez les détails de la pile suivants :
1. Saisissez le nom de la pile.
1. En **IdentityProviderName**effet, vous pouvez laisser ce champ vide pour générer automatiquement un nom basé sur le nom de la pile, ou saisir un nom personnalisé pour votre IdP SAML. Les noms personnalisés doivent contenir uniquement des caractères alphanumériques, des points, des traits de soulignement et des tirets.
1. Pour **IdentityProviderSAMLMetadataDocument**, vous devez formater votre fichier XML de métadonnées SAML sur une seule ligne avant de le coller dans ce champ. Cela est nécessaire car la CloudFormation console exige que le contenu XML soit formaté sur une seule ligne lorsqu'il est transmis via les paramètres de la console.
Utilisez la commande Python suivante pour reformater votre fichier XML :
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**Note**
Le document de métadonnées SAML de l’IdP doit être formaté en une seule ligne pour la saisie des paramètres de la console. La commande Python supprime les sauts de ligne et les espaces supplémentaires afin de créer le format requis tout en conservant l’intégralité du contenu et de la structure d’origine.
Copiez le résultat de la commande Python et collez-le dans le champ **IdentityProviderSAMLMetadataDocument**.
Exemple de document de métadonnées SAML formaté (abrégé) :
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. Pour les autres paramètres, acceptez les valeurs par défaut ou saisissez les vôtres en fonction de vos besoins :
+ **IdentityProviderAddPrivateKey**- Clé privée optionnelle pour déchiffrer les assertions SAML
+ **IdentityProviderAssertionEncryptionMode**- Facultatif, définit le mode de chiffrement pour les assertions SAML (autorisé, obligatoire ou vide)
1. Choisissez **Suivant**.
1. Configurez les options de pile :
1. Sous **Options d’échec de pile**, choisissez **Supprimer toutes les ressources nouvellement créées**.
**Note**
Le choix de cette option vous évite d’être facturé pour des ressources dont la politique de suppression indique qu’elles doivent être conservées même en cas d’échec de la création de la pile.
1. Acceptez toutes les autres valeurs par défaut.
1. Sous **Fonctionnalités**, cochez la case pour confirmer que des ressources IAM CloudFormation peuvent être créées dans votre compte.
1. Choisissez **Suivant**.
1. Vérifiez les détails de la pile et choisissez **Envoyer**.
CloudFormation crée la pile. Une fois la création de la pile terminée, les ressources de la pile sont prêtes à être utilisées. Vous pouvez utiliser l’onglet **Ressources** de la page détaillée de la pile pour afficher les ressources provisionnées dans votre compte.
La pile produira les valeurs suivantes, que vous pouvez consulter dans l’onglet **Sorties** :
+ **ProviderARN** : l’ARN de l’IdP SAML créé (par exemple, `arn:aws:iam::123456789012:saml-provider/CompanyIdP`). Vous aurez besoin de cet ARN pour créer des rôles qui font confiance à ce fournisseur.
+ **ProviderName**: nom de l'IdP SAML créé (par exemple`CompanyIdP`, si vous avez spécifié un nom personnalisé `my-saml-stack-saml-provider` ou si vous avez utilisé le nom par défaut).
Ces sorties sont également exportées, ce qui permet à d’autres piles CloudFormation de les importer à l’aide de la fonction `Fn::ImportValue`.
## Vérifier l’IdP SAML
Une fois l’IdP SAML créé, vous pouvez vérifier sa configuration et noter son ARN pour l’utiliser avec les rôles fédérés.
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, sélectionnez **Identity providers (Fournisseurs d'identité)**.
Vous devez voir votre IdP SAML nouvellement créé dans la liste.
1. Choisissez le nom de l’IdP pour en afficher les détails.
Sur la page de détails de l’IdP, vous pouvez consulter le document de métadonnées SAML et d’autres détails de configuration.
1. Notez l’**ARN du fournisseur** affiché sur la page de détails.
Vous aurez besoin de cet ARN pour créer des rôles IAM fédérés qui font confiance à cet IdP.
1. Vérifiez le document de métadonnées pour vous assurer qu’il correspond à ce que vous avez fourni à partir de votre IdP externe.
Votre IdP SAML est désormais prêt à être utilisé par les rôles IAM fédérés. Vous pouvez créer des rôles qui font confiance à cet IdP afin de permettre aux utilisateurs authentifiés de votre IdP externe d'assumer ces rôles et d'accéder aux ressources. AWS
## Nettoyage : supprimez les ressources
Enfin, vous allez supprimer la pile et les ressources qu’elle contient.
1. Ouvrez la CloudFormation console.
1. Sur la page **Piles**, choisissez la pile créée à partir du modèle, choisissez **Supprimer**, puis confirmez **Supprimer**.
CloudFormation initie la suppression de la pile et de toutes les ressources qu'elle contient.
## CloudFormation détails du modèle
### Ressources
Le CloudFormation modèle de ce didacticiel créera la ressource suivante dans votre compte :
[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP SAML qui établit la confiance AWS entre et votre IdP externe.
### Configuration
Le modèle comprend les paramètres configurables suivants :
+ **IdentityProviderName**- Le nom de votre IdP SAML (laissez le champ vide pour le nom généré automatiquement)
Exemple : `CompanyIdP` ou `EnterpriseSSO`
+ **IdentityProviderSAMLMetadataDocument** - Le document de métadonnées SAML de votre IdP externe (formaté sur une seule ligne)
+ **IdentityProviderAddPrivateKey**- Clé privée optionnelle pour déchiffrer les assertions SAML
+ **IdentityProviderAssertionEncryptionMode**- Facultatif, définit le mode de chiffrement pour les assertions SAML
## CloudFormation modèle
Enregistrez le code JSON ou YAML suivant dans un fichier distinct à utiliser comme CloudFormation modèle pour ce didacticiel.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
}
},
"Conditions": {
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]},
"HasCustomName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"Tags": [
{
"Key": "Name",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]}
}
],
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
}
},
"Outputs": {
"ProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderARN"}
}
},
"ProviderName": {
"Description": "Name of the SAML Identity Provider",
"Value": {"Fn::If": ["HasCustomName", {"Ref": "IdentityProviderName"}, {"Fn::Sub": "${AWS::StackName}-saml-provider"}]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-ProviderName"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens'
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
Conditions:
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
HasCustomName: !Not [!Equals [!Ref IdentityProviderName, ""]]
Resources:
SAMLProvider:
Type: 'AWS::IAM::SAMLProvider'
Properties:
Name: !If
- HasCustomName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
Tags:
- Key: Name
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
Outputs:
ProviderARN:
Description: 'ARN of the created SAML Identity Provider'
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-ProviderARN'
ProviderName:
Description: 'Name of the SAML Identity Provider'
Value: !If
- HasCustomName
- !Ref IdentityProviderName
- !Sub '${AWS::StackName}-saml-provider'
Export:
Name: !Sub '${AWS::StackName}-ProviderName'
```
------
# Tutoriel IAM : Utiliser un CloudFormation modèle pour créer un rôle IAM fédéré SAML
Lorsqu'un fournisseur d'identité (IdP) SAML est déjà configuré dans AWS votre compte, vous pouvez créer des rôles IAM fédérés qui font confiance à cet IdP. Ce didacticiel explique comment utiliser un CloudFormation modèle pour créer un rôle IAM fédéré SAML qui peut être assumé par des utilisateurs authentifiés via votre IdP externe.
Le modèle crée un rôle IAM fédéré avec une politique d’approbation permettant à votre IdP SAML d’endosser le rôle. Les utilisateurs authentifiés par votre IdP externe peuvent endosser ce rôle pour accéder aux ressources AWS en fonction des autorisations associées au rôle.
La ressource déployée est composée des éléments suivants :
+ Un rôle IAM fédéré qui fait confiance à votre idP SAML existant.
+ Des politiques gérées configurables qui peuvent être associées au rôle afin d’accorder des autorisations spécifiques.
+ Des paramètres de limite d’autorisation et de durée de session facultatifs.
## Conditions préalables
Le didacticiel présume que vous avez déjà ce qui suit en place :
+ Un IdP SAML existant configuré dans AWS votre compte. Si vous n’en avez pas, vous pouvez en créer un à l’aide du didacticiel [Tutoriel IAM : Utiliser un CloudFormation modèle pour créer un fournisseur d'identité SAML (IdP)](tutorial_saml-idp.md).
+ L’ARN de votre IdP SAML, que vous devrez spécifier comme paramètre lors de la création de la pile.
+ Python 3.6 ou version ultérieure installée sur votre ordinateur local pour exécuter la commande Python utilisée dans ce didacticiel afin de formater le fichier XML des métadonnées SAML de votre IdP.
## Créez un rôle fédéré SAML à l'aide de CloudFormation
Pour créer le rôle fédéré SAML, vous allez créer un CloudFormation modèle et l'utiliser pour créer une pile contenant le rôle.
### Création du modèle
Créez d'abord le CloudFormation modèle.
1. Dans la section [Modèle](#tutorial_saml-federated-role-template), cliquez sur l’icône de copie dans l’onglet **JSON** ou **YAML** pour copier le contenu du modèle.
1. Copiez le contenu du modèle dans un nouveau fichier.
1. Enregistrez le fichier au niveau local.
### Créez la pile .
Ensuite, utilisez le modèle que vous avez enregistré pour approvisionner une CloudFormation pile.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sur la page **Piles**, dans le menu **Créer une pile**, choisissez **Avec de nouvelles ressources (standard)**.
1. Spécifiez un modèle :
1. Sous **Prérequis**, choisissez **Choisir un modèle existant**.
1. Sous **Spécifier le modèle**, sélectionnez **Charger un modèle de fichier**.
1. Choisissez **Choisir un fichier**, accédez au fichier du modèle, puis sélectionnez-le.
1. Choisissez **Suivant**.
1. Spécifiez les détails de la pile suivants :
1. Saisissez le nom de la pile.
1. Pour l'**SAMLProviderARN**, entrez l'ARN de votre IdP SAML existant. Cela doit être au format `arn:aws:iam::123456789012:saml-provider/YourProviderName`.
Exemple : `arn:aws:iam::123456789012:saml-provider/CompanyIdP`
**Note**
Si vous avez créé votre IdP SAML à l'aide [Tutoriel IAM : Utiliser un CloudFormation modèle pour créer un fournisseur d'identité SAML (IdP)](tutorial_saml-idp.md) du didacticiel, vous trouverez l'ARN du fournisseur dans l'onglet Sorties de CloudFormation cette pile.
1. En **RoleName**effet, vous pouvez laisser ce champ vide pour générer automatiquement un nom basé sur le nom de la pile, ou saisir un nom personnalisé pour le rôle IAM.
Exemple : `SAML-Developer-Access` ou `SAML-ReadOnly-Role`
1. Pour les autres paramètres, acceptez les valeurs par défaut ou saisissez les vôtres en fonction de vos besoins :
+ **RoleSessionDuration**- Durée maximale de session en secondes (3600-43200, 7200 par défaut)
Exemple : `14400` (4 heures)
+ **RolePermissionsBoundary**- ARN facultatif d'une politique de limite d'autorisations
Exemple : `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**- Chemin du rôle IAM (la valeur par défaut est/)
Exemple : `/saml-roles/`
+ **ManagedPolicy1-5** - Possibilité ARNs de joindre jusqu'à 5 politiques gérées
Exemple pour ManagedPolicy 1 : `arn:aws:iam::aws:policy/ReadOnlyAccess`
Exemple pour ManagedPolicy 2 : `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Choisissez **Suivant**.
1. Configurez les options de pile :
1. Sous **Options d’échec de pile**, choisissez **Supprimer toutes les ressources nouvellement créées**.
**Note**
Le choix de cette option vous évite d’être facturé pour des ressources dont la politique de suppression indique qu’elles doivent être conservées même en cas d’échec de la création de la pile.
1. Acceptez toutes les autres valeurs par défaut.
1. Sous **Fonctionnalités**, cochez la case pour confirmer que des ressources IAM CloudFormation peuvent être créées dans votre compte.
1. Choisissez **Suivant**.
1. Vérifiez les détails de la pile et choisissez **Envoyer**.
CloudFormation crée la pile. Une fois la création de la pile terminée, les ressources de la pile sont prêtes à être utilisées. Vous pouvez utiliser l’onglet **Ressources** de la page détaillée de la pile pour afficher les ressources provisionnées dans votre compte.
La pile produira la valeur suivante, que vous pouvez consulter dans l’onglet **Sorties** :
+ **RoleARN** : ARN du rôle IAM créé (par exemple, `arn:aws:iam::123456789012:role/SAML-Developer-Access` ou `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` si vous utilisez un nom généré automatiquement).
Vous aurez besoin de cet ARN de rôle lors de la configuration de votre IdP afin d’envoyer les attributs SAML appropriés pour l’attribution des rôles.
## Tester le rôle fédéré SAML
Une fois le rôle fédéré SAML créé, vous pouvez vérifier sa configuration et tester la configuration de la fédération.
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, choisissez **Rôles**.
1. Trouvez et choisissez le rôle fédéré que vous venez de créer.
Si vous avez fourni un nom de rôle personnalisé, recherchez ce nom. Si vous avez laissé le RoleName paramètre vide, le rôle aura un nom généré automatiquement en fonction du nom de la pile et d'un identifiant unique.
1. Choisissez l’onglet **Relations de confiance** pour consulter la politique de confiance.
La politique de confiance doit indiquer que votre IdP SAML est fiable pour assumer ce rôle à condition que l’audience SAML (`SAML:aud`) corresponde à `https://signin.aws.amazon.com/saml`.
1. Sélectionnez l’onglet **Autorisations** pour consulter les politiques associées.
Vous pouvez voir toutes les politiques gérées associées au rôle lors de sa création.
1. Notez l’**ARN du rôle** affiché sur la page de résumé du rôle.
Vous aurez besoin de cet ARN pour configurer votre IdP externe afin de permettre aux utilisateurs d’assumer ce rôle.
Votre rôle fédéré SAML est maintenant prêt à être utilisé. Configurez votre IdP externe pour inclure l'ARN de ce rôle dans les assertions SAML, et les utilisateurs authentifiés pourront assumer ce rôle pour accéder aux ressources. AWS
## Nettoyage : supprimez les ressources
Enfin, vous allez supprimer la pile et les ressources qu’elle contient.
1. Ouvrez la CloudFormation console.
1. Sur la page **Piles**, choisissez la pile créée à partir du modèle, choisissez **Supprimer**, puis confirmez **Supprimer**.
CloudFormation initie la suppression de la pile et de toutes les ressources qu'elle contient.
## CloudFormation détails du modèle
### Ressources
Le CloudFormation modèle de ce didacticiel créera la ressource suivante dans votre compte :
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) : un rôle IAM fédéré qui peut être endossé par les utilisateurs authentifiés via votre IdP SAML.
### Configuration
Le modèle comprend les paramètres configurables suivants :
+ **RoleName**- Nom du rôle IAM (laissez le champ vide pour le nom généré automatiquement)
+ **SAMLProviderARN** : ARN de l'IdP SAML (obligatoire)
+ **RoleSessionDuration**- Durée maximale de session en secondes (3600-43200, 7200 par défaut)
+ **RolePermissionsBoundary**- ARN facultatif de la politique de limite des autorisations
+ **RolePath**- Chemin du rôle IAM (par défaut/)
+ **ManagedPolicy1-5** - Possibilité ARNs de joindre jusqu'à 5 politiques gérées
## CloudFormation modèle
Enregistrez le code JSON ou YAML suivant dans un fichier distinct à utiliser comme CloudFormation modèle pour ce didacticiel.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-federated-role",
"Parameters": {
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"SAMLProviderARN": {
"Type": "String",
"Description": "ARN of the SAML Identity Provider",
"AllowedPattern": "^arn:aws:iam::\\d{12}:saml-provider/[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be a valid SAML provider ARN"
},
"RoleSessionDuration": {
"Type": "Number",
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM role (must start and end with /)",
"Default": "/",
"AllowedPattern": "^\/.*\/$|^\/$",
"ConstraintDescription": "Role path must start and end with forward slash (/)"
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]}
},
"Resources": {
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Description": "IAM role with SAML provider trust",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProviderARN"}
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-federated-role'
Parameters:
RoleName:
Type: String
Description: 'Name of the IAM Role (leave empty for auto-generated name like ''{StackName}-{UniqueId}'')'
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: 'Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-'
SAMLProviderARN:
Type: String
Description: 'ARN of the SAML Identity Provider'
AllowedPattern: '^arn:aws:iam::\d{12}:saml-provider/[a-zA-Z0-9._-]+$'
ConstraintDescription: 'Must be a valid SAML provider ARN'
RoleSessionDuration:
Type: Number
Description: 'The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)'
MinValue: 3600
MaxValue: 43200
Default: 7200
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RolePath:
Type: String
Description: 'Path for the IAM role (must start and end with /)'
Default: "/"
AllowedPattern: '^\/.*\/$|^\/$'
ConstraintDescription: 'Role path must start and end with forward slash (/)'
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
Resources:
SAMLFederatedRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Description: 'IAM role with SAML provider trust'
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
Path: !Ref RolePath
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProviderARN
Action: 'sts:AssumeRoleWithSAML'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns:
!Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref 'AWS::NoValue']
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref 'AWS::NoValue']
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref 'AWS::NoValue']
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref 'AWS::NoValue']
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref 'AWS::NoValue']
Outputs:
RoleARN:
Description: 'ARN of the created IAM Role'
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
```
------
# Tutoriel IAM : Utiliser un CloudFormation modèle pour créer un fournisseur d'identité SAML (IdP) et un rôle IAM fédéré SAML
Pour vous familiariser avec la fédération SAML et ses fonctionnalités, vous allez utiliser un CloudFormation modèle pour configurer un fournisseur d'identité (IdP) SAML et le rôle IAM fédéré associé. Ce didacticiel vous montre comment créer les deux ressources ensemble dans une seule pile.
Le modèle crée un IdP SAML qui peut être utilisé pour un accès fédéré AWS aux ressources, ainsi qu'un rôle IAM qui fait confiance au fournisseur SAML. Les utilisateurs authentifiés par votre IdP externe peuvent assumer ce rôle pour accéder aux AWS ressources.
Les ressources déployées sont composées des éléments suivants :
+ Un IdP SAML configuré avec le document de métadonnées de votre IdP.
+ Un rôle IAM fédéré qui fait confiance à l’IdP SAML et peut être endossé par des utilisateurs authentifiés.
+ Des politiques gérées configurables qui peuvent être associées au rôle afin d’accorder des autorisations spécifiques.
## Conditions préalables
Le didacticiel présume que vous avez déjà ce qui suit en place :
+ Python 3.6 ou version ultérieure installée sur votre ordinateur local pour exécuter la commande Python utilisée dans ce didacticiel afin de formater le fichier XML des métadonnées SAML de votre IdP.
+ Un document de métadonnées SAML provenant de votre IdP externe enregistré sous forme de fichier XML.
## Créez un IdP et un rôle SAML à l'aide de CloudFormation
Pour créer l'IdP SAML et le rôle fédéré, vous allez créer CloudFormation un modèle et l'utiliser pour créer une pile contenant les deux ressources.
### Création du modèle
Créez d'abord le CloudFormation modèle.
1. Dans la section [Modèle](#tutorial_saml-idp-and-federated-role-template), cliquez sur l’icône de copie dans l’onglet **JSON** ou **YAML** pour copier le contenu du modèle.
1. Copiez le contenu du modèle dans un nouveau fichier.
1. Enregistrez le fichier au niveau local.
### Créez la pile .
Ensuite, utilisez le modèle que vous avez enregistré pour approvisionner une CloudFormation pile.
1. Ouvrez la CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sur la page **Piles**, dans le menu **Créer une pile**, choisissez **Avec de nouvelles ressources (standard)**.
1. Spécifiez un modèle :
1. Sous **Prérequis**, choisissez **Choisir un modèle existant**.
1. Sous **Spécifier le modèle**, sélectionnez **Charger un modèle de fichier**.
1. Choisissez **Choisir un fichier**, accédez au fichier du modèle, puis sélectionnez-le.
1. Choisissez **Suivant**.
1. Spécifiez les détails de la pile suivants :
1. Saisissez le nom de la pile.
1. En **IdentityProviderName**effet, vous pouvez laisser ce champ vide pour générer automatiquement un nom basé sur le nom de la pile, ou saisir un nom personnalisé pour votre IdP SAML.
Exemple : `CompanyIdP` ou `EnterpriseSSO`
1. Pour **IdentityProviderSAMLMetadataDocument**, vous devez formater votre fichier XML de métadonnées SAML sur une seule ligne avant de le coller dans ce champ. Cela est nécessaire car la CloudFormation console exige que le contenu XML soit formaté sur une seule ligne lorsqu'il est transmis via les paramètres de la console.
Utilisez la commande Python suivante pour reformater votre fichier XML :
```
python3 -c "import sys, re; content=open(sys.argv[1]).read(); print(re.sub(r'>\s+<', '><', content.replace('\n', '').replace('\r', '').strip()))" saml-metadata.xml
```
**Note**
Le document de métadonnées SAML de l’IdP doit être formaté en une seule ligne pour la saisie des paramètres de la console. La commande Python supprime les sauts de ligne et les espaces supplémentaires afin de créer le format requis tout en conservant l’intégralité du contenu et de la structure d’origine.
Copiez le résultat de la commande Python et collez-le dans le champ **IdentityProviderSAMLMetadataDocument**.
Exemple de document de métadonnées SAML formaté (abrégé) :
```
MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiIMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNV...urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
```
1. En **RoleName**effet, vous pouvez laisser ce champ vide pour générer automatiquement un nom basé sur le nom de la pile, ou saisir un nom personnalisé pour le rôle IAM fédéré.
Exemple : `SAML-Developer-Access` ou `SAML-ReadOnly-Role`
1. Pour les autres paramètres, acceptez les valeurs par défaut ou saisissez les vôtres en fonction de vos besoins :
+ **IdentityProviderAddPrivateKey**- Clé privée optionnelle pour déchiffrer les assertions SAML
+ **IdentityProviderAssertionEncryptionMode**- Mode de chiffrement pour les assertions SAML
Exemples de valeurs : `Allowed`, `Required`, ou laissez vide pour aucun chiffrement
+ **RoleSessionDuration**- Durée maximale de session en secondes (3600-43200, 7200 par défaut)
Exemple : `14400` (4 heures)
+ **RolePermissionsBoundary**- ARN facultatif d'une politique de limite d'autorisations
Exemple : `arn:aws:iam::123456789012:policy/DeveloperBoundary`
+ **RolePath**- Chemin pour le rôle IAM (la valeur par défaut est/)
Exemple : `/saml-roles/`
+ **RoleManagedPolicy1-5** - Possibilité ARNs de joindre jusqu'à 5 politiques gérées
Exemple pour RoleManagedPolicy 1 : `arn:aws:iam::aws:policy/ReadOnlyAccess`
Exemple pour RoleManagedPolicy 2 : `arn:aws:iam::123456789012:policy/CustomPolicy`
1. Choisissez **Suivant**.
1. Configurez les options de pile :
1. Sous **Options d’échec de pile**, choisissez **Supprimer toutes les ressources nouvellement créées**.
**Note**
Le choix de cette option vous évite d’être facturé pour des ressources dont la politique de suppression indique qu’elles doivent être conservées même en cas d’échec de la création de la pile.
1. Acceptez toutes les autres valeurs par défaut.
1. Sous **Fonctionnalités**, cochez la case pour confirmer que des ressources IAM CloudFormation peuvent être créées dans votre compte.
1. Choisissez **Suivant**.
1. Vérifiez les détails de la pile et choisissez **Envoyer**.
CloudFormation crée la pile. Une fois la création de la pile terminée, les ressources de la pile sont prêtes à être utilisées. Vous pouvez utiliser l’onglet **Ressources** de la page détaillée de la pile pour afficher les ressources provisionnées dans votre compte.
La pile produira les valeurs suivantes, que vous pouvez consulter dans l’onglet **Sorties** :
+ **RoleARN** : ARN du rôle IAM créé (par exemple, `arn:aws:iam::123456789012:role/SAML-Developer-Access` ou `arn:aws:iam::123456789012:role/stack-name-a1b2c3d4` si vous utilisez un nom généré automatiquement).
+ **IdentityProviderARN** : ARN de l'IdP SAML créé (par exemple`arn:aws:iam::123456789012:saml-provider/CompanyIdP`,).
Vous aurez besoin de ces deux éléments ARNs lors de la configuration de votre IdP afin d'envoyer les attributs SAML appropriés pour l'attribution des rôles.
## Tester la fédération SAML
Une fois que l’IdP SAML et le rôle fédéré ont été créés, vous pouvez tester la configuration de la fédération.
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, sélectionnez **Identity providers (Fournisseurs d'identité)**.
Vous devez voir votre IdP SAML nouvellement créé dans la liste.
1. Choisissez le nom de l’IdP pour en afficher les détails.
Sur la page de détails de l’IdP, vous pouvez consulter le document de métadonnées SAML et d’autres détails de configuration.
1. Dans le panneau de navigation, choisissez **Rôles**.
1. Trouvez et choisissez le rôle fédéré que vous venez de créer.
Sur la page de détails du rôle, vous pouvez voir la politique de confiance qui permet à l’IdP SAML d’endosser ce rôle.
1. Choisissez l’onglet **Relations de confiance** pour consulter la politique de confiance.
La politique de confiance doit indiquer que l’IdP SAML est fiable pour assumer ce rôle à condition que l’audience SAML (`SAML:aud`) corresponde à `https://signin.aws.amazon.com/saml`.
## Nettoyage : supprimez les ressources
Enfin, vous allez supprimer la pile et les ressources qu’elle contient.
1. Ouvrez la CloudFormation console.
1. Sur la page **Piles**, choisissez la pile créée à partir du modèle, choisissez **Supprimer**, puis confirmez **Supprimer**.
CloudFormation initie la suppression de la pile et de toutes les ressources qu'elle contient.
## CloudFormation détails du modèle
### Ressources
Le CloudFormation modèle de ce didacticiel créera les ressources suivantes dans votre compte :
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-samlprovider.html): un IdP SAML qui établit la confiance AWS entre et votre IdP externe.
+ [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) : un rôle IAM fédéré qui peut être endossé par les utilisateurs authentifiés via l’IdP SAML.
### Configuration
Le modèle comprend les paramètres configurables suivants :
+ **IdentityProviderName**- Nom de l'IdP SAML (laissez le champ vide pour le nom généré automatiquement)
+ **IdentityProviderSAMLMetadataDocument : document** de métadonnées SAML provenant de votre IdP (obligatoire)
+ **IdentityProviderAddPrivateKey**- Clé privée optionnelle pour déchiffrer les assertions SAML
+ **IdentityProviderAssertionEncryptionMode**- Mode de chiffrement pour les assertions SAML
+ **RoleName**- Nom du rôle IAM (laissez le champ vide pour le nom généré automatiquement)
+ **RolePath**- Chemin du rôle IAM (par défaut/)
+ **RolePermissionsBoundary**- ARN facultatif de la politique de limite des autorisations
+ **RoleSessionDuration**- Durée maximale de session en secondes (3600-43200, 7200 par défaut)
+ **RoleManagedPolicy1-5** - Possibilité ARNs de joindre jusqu'à 5 politiques gérées
## CloudFormation modèle
Enregistrez le code JSON ou YAML suivant dans un fichier distinct à utiliser comme CloudFormation modèle pour ce didacticiel.
------
#### [ JSON ]
```
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "[AWSDocs] IAM: tutorial_saml-idp-and-federated-role",
"Parameters": {
"IdentityProviderName": {
"Type": "String",
"Description": "Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[a-zA-Z0-9._-]+$",
"ConstraintDescription": "Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens"
},
"IdentityProviderSAMLMetadataDocument": {
"Type": "String",
"Description": "SAML metadata document from identity provider"
},
"IdentityProviderAddPrivateKey": {
"Type": "String",
"Description": "Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.",
"Default": ""
},
"IdentityProviderAssertionEncryptionMode": {
"Type": "String",
"Description": "Optional, sets encryption mode for SAML assertions",
"Default": "",
"AllowedValues": ["", "Allowed", "Required"]
},
"RoleName": {
"Type": "String",
"Description": "Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')",
"Default": "",
"AllowedPattern": "^$|^[\\w+=,.@-]{1,64}$",
"ConstraintDescription": "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
},
"RolePath": {
"Type": "String",
"Description": "Path for the IAM Role",
"AllowedPattern": "(^\\/$)|(^\\/.*\\/$)",
"Default": "/"
},
"RolePermissionsBoundary": {
"Type": "String",
"Description": "Optional ARN of the permissions boundary policy (leave empty for none)",
"Default": ""
},
"RoleSessionDuration": {
"Description": "The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)",
"Type": "Number",
"MinValue": 3600,
"MaxValue": 43200,
"Default": 7200
},
"RoleManagedPolicy1": {
"Type": "String",
"Description": "Optional managed policy ARN 1",
"Default": ""
},
"RoleManagedPolicy2": {
"Type": "String",
"Description": "Optional managed policy ARN 2",
"Default": ""
},
"RoleManagedPolicy3": {
"Type": "String",
"Description": "Optional managed policy ARN 3",
"Default": ""
},
"RoleManagedPolicy4": {
"Type": "String",
"Description": "Optional managed policy ARN 4",
"Default": ""
},
"RoleManagedPolicy5": {
"Type": "String",
"Description": "Optional managed policy ARN 5",
"Default": ""
}
},
"Conditions": {
"HasCustomProviderName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderName"}, ""]}]},
"HasCustomRoleName": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleName"}, ""]}]},
"HasPermissionsBoundary": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RolePermissionsBoundary"}, ""]}]},
"HasPolicy1": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy1"}, ""]}]},
"HasPolicy2": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy2"}, ""]}]},
"HasPolicy3": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy3"}, ""]}]},
"HasPolicy4": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy4"}, ""]}]},
"HasPolicy5": {"Fn::Not": [{"Fn::Equals": [{"Ref": "RoleManagedPolicy5"}, ""]}]},
"HasPrivateKey": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAddPrivateKey"}, ""]}]},
"HasAssertionEncryptionMode": {"Fn::Not": [{"Fn::Equals": [{"Ref": "IdentityProviderAssertionEncryptionMode"}, ""]}]}
},
"Resources": {
"SAMLProvider": {
"Type": "AWS::IAM::SAMLProvider",
"Properties": {
"Name": {"Fn::If": ["HasCustomProviderName", {"Ref": "IdentityProviderName"}, {"Ref": "AWS::NoValue"}]},
"SamlMetadataDocument": {"Ref": "IdentityProviderSAMLMetadataDocument"},
"AddPrivateKey": {"Fn::If": ["HasPrivateKey", {"Ref": "IdentityProviderAddPrivateKey"}, {"Ref": "AWS::NoValue"}]},
"AssertionEncryptionMode": {"Fn::If": ["HasAssertionEncryptionMode", {"Ref": "IdentityProviderAssertionEncryptionMode"}, {"Ref": "AWS::NoValue"}]}
}
},
"SAMLFederatedRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"RoleName": {"Fn::If": ["HasCustomRoleName", {"Ref": "RoleName"}, {"Ref": "AWS::NoValue"}]},
"Path": {"Ref": "RolePath"},
"Description": "SAML federated IAM role for SSO access with specified permissions",
"MaxSessionDuration": {"Ref": "RoleSessionDuration"},
"PermissionsBoundary": {"Fn::If": ["HasPermissionsBoundary", {"Ref": "RolePermissionsBoundary"}, {"Ref": "AWS::NoValue"}]},
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": {"Ref": "SAMLProvider"}
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
},
"ManagedPolicyArns": {
"Fn::Split": [
",",
{
"Fn::Join": [
",",
[
{"Fn::If": ["HasPolicy1", {"Ref": "RoleManagedPolicy1"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy2", {"Ref": "RoleManagedPolicy2"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy3", {"Ref": "RoleManagedPolicy3"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy4", {"Ref": "RoleManagedPolicy4"}, {"Ref": "AWS::NoValue"}]},
{"Fn::If": ["HasPolicy5", {"Ref": "RoleManagedPolicy5"}, {"Ref": "AWS::NoValue"}]}
]
]
}
]
}
}
}
},
"Outputs": {
"RoleARN": {
"Description": "ARN of the created IAM Role",
"Value": {"Fn::GetAtt": ["SAMLFederatedRole", "Arn"]},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-RoleARN"}
}
},
"IdentityProviderARN": {
"Description": "ARN of the created SAML Identity Provider",
"Value": {"Ref": "SAMLProvider"},
"Export": {
"Name": {"Fn::Sub": "${AWS::StackName}-IdentityProviderARN"}
}
}
}
}
```
------
#### [ YAML ]
```
AWSTemplateFormatVersion: '2010-09-09'
Description: '[AWSDocs] IAM: tutorial_saml-idp-and-federated-role'
Parameters:
IdentityProviderName:
Type: String
Description: Name of the SAML Identity Provider (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[a-zA-Z0-9._-]+$'
ConstraintDescription: Must be empty or contain only alphanumeric characters, periods, underscores, and hyphens
IdentityProviderSAMLMetadataDocument:
Type: String
Description: SAML metadata document from identity provider
IdentityProviderAddPrivateKey:
Type: String
Description: Optional private key for decrypting SAML assertions. The private key must be a .pem file that uses AES-GCM or AES-CBC encryption algorithm to decrypt SAML assertions.
Default: ""
IdentityProviderAssertionEncryptionMode:
Type: String
Description: Optional, sets encryption mode for SAML assertions
Default: ""
AllowedValues:
- ""
- "Allowed"
- "Required"
RoleName:
Type: String
Description: Name of the IAM Role (leave empty for auto-generated name like '{StackName}-{UniqueId}')
Default: ""
AllowedPattern: '^$|^[\w+=,.@-]{1,64}$'
ConstraintDescription: "Must be empty or 1-64 characters and can contain alphanumeric characters and +=,.@-"
RolePath:
Type: String
Description: Path for the IAM Role
AllowedPattern: (^\/$)|(^\/.*\/$)
Default: "/"
RolePermissionsBoundary:
Type: String
Description: Optional ARN of the permissions boundary policy (leave empty for none)
Default: ""
RoleSessionDuration:
Description: The maximum session duration (in seconds) that you want to set for the specified role (3600-43200)
Type: Number
MinValue: 3600
MaxValue: 43200
Default: 7200
RoleManagedPolicy1:
Type: String
Description: Optional managed policy ARN 1
Default: ""
RoleManagedPolicy2:
Type: String
Description: Optional managed policy ARN 2
Default: ""
RoleManagedPolicy3:
Type: String
Description: Optional managed policy ARN 3
Default: ""
RoleManagedPolicy4:
Type: String
Description: Optional managed policy ARN 4
Default: ""
RoleManagedPolicy5:
Type: String
Description: Optional managed policy ARN 5
Default: ""
Conditions:
HasCustomProviderName: !Not [!Equals [!Ref IdentityProviderName, ""]]
HasCustomRoleName: !Not [!Equals [!Ref RoleName, ""]]
HasPermissionsBoundary: !Not [!Equals [!Ref RolePermissionsBoundary, ""]]
HasPolicy1: !Not [!Equals [!Ref RoleManagedPolicy1, ""]]
HasPolicy2: !Not [!Equals [!Ref RoleManagedPolicy2, ""]]
HasPolicy3: !Not [!Equals [!Ref RoleManagedPolicy3, ""]]
HasPolicy4: !Not [!Equals [!Ref RoleManagedPolicy4, ""]]
HasPolicy5: !Not [!Equals [!Ref RoleManagedPolicy5, ""]]
HasPrivateKey: !Not [!Equals [!Ref IdentityProviderAddPrivateKey, ""]]
HasAssertionEncryptionMode: !Not [!Equals [!Ref IdentityProviderAssertionEncryptionMode, ""]]
Resources:
SAMLProvider:
Type: AWS::IAM::SAMLProvider
Properties:
Name: !If
- HasCustomProviderName
- !Ref IdentityProviderName
- !Ref AWS::NoValue
SamlMetadataDocument: !Ref IdentityProviderSAMLMetadataDocument
AddPrivateKey: !If
- HasPrivateKey
- !Ref IdentityProviderAddPrivateKey
- !Ref AWS::NoValue
AssertionEncryptionMode: !If
- HasAssertionEncryptionMode
- !Ref IdentityProviderAssertionEncryptionMode
- !Ref AWS::NoValue
SAMLFederatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: !If
- HasCustomRoleName
- !Ref RoleName
- !Ref AWS::NoValue
Path: !Ref RolePath
Description: "SAML federated IAM role for SSO access with specified permissions"
MaxSessionDuration: !Ref RoleSessionDuration
PermissionsBoundary: !If
- HasPermissionsBoundary
- !Ref RolePermissionsBoundary
- !Ref AWS::NoValue
AssumeRolePolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Principal:
Federated: !Ref SAMLProvider
Action:
- 'sts:AssumeRole'
- 'sts:SetSourceIdentity'
- 'sts:TagSession'
Condition:
StringEquals:
'SAML:aud': 'https://signin.aws.amazon.com/saml'
ManagedPolicyArns: !Split
- ','
- !Join
- ','
- - !If [HasPolicy1, !Ref RoleManagedPolicy1, !Ref "AWS::NoValue"]
- !If [HasPolicy2, !Ref RoleManagedPolicy2, !Ref "AWS::NoValue"]
- !If [HasPolicy3, !Ref RoleManagedPolicy3, !Ref "AWS::NoValue"]
- !If [HasPolicy4, !Ref RoleManagedPolicy4, !Ref "AWS::NoValue"]
- !If [HasPolicy5, !Ref RoleManagedPolicy5, !Ref "AWS::NoValue"]
Outputs:
RoleARN:
Description: ARN of the created IAM Role
Value: !GetAtt SAMLFederatedRole.Arn
Export:
Name: !Sub '${AWS::StackName}-RoleARN'
IdentityProviderARN:
Description: ARN of the created SAML Identity Provider
Value: !Ref SAMLProvider
Export:
Name: !Sub '${AWS::StackName}-IdentityProviderARN'
```
------