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. # Basculer vers un rôle IAM (AWS CLI) Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS dont vous avez besoin. À cet égard, il est semblable à un [utilisateur IAM Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté en tant qu'utilisateur, vous pouvez passer à un rôle. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md). **Important** Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement les autorisations utilisateur et de rôle précédentes et utilisez celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées. Vous pouvez utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'utilisateur IAM. Vous pouvez également utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'[utilisateur authentifié de manière externe](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) ou [OIDC](id_roles_providers_oidc.md)) qui utilise déjà un rôle. De plus, vous pouvez utiliser un rôle pour exécuter une commande de la AWS CLI dans une instance Amazon EC2 attachée à un rôle via son profil d'instance. Il n'est pas possible d'assumer un rôle si vous êtes connecté en tant qu' Utilisateur racine d'un compte AWS. [**Chaînage de rôles**](id_roles.md#iam-term-role-chaining) : vous pouvez aussi utiliser le chaînage de rôles, qui utilise les autorisations d'un rôle pour accéder à un second rôle. Par défaut, votre session de rôle dure une heure. Lorsque vous endossez ce rôle à l'aide des opérations de la CLI `assume-role*`, vous pouvez spécifier une valeur pour le paramètre `duration-seconds`. Cette valeur peut être comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Si vous changez de rôle dans la console, la durée de votre session est limitée à une heure. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration). Si vous utilisez la création de chaînes de rôles, la durée de votre session est limitée à une heure maximum. Si vous utilisez ensuite le paramètre `duration-seconds` pour fournir une valeur supérieure à une heure, l'opération échoue. ## Exemple de scénario : passer à un rôle de production Imaginez que vous êtes un utilisateur IAM pour travailler dans l'environnement de développement. Dans ce scénario, vous devez parfois travailler avec l'environnement de production au niveau de la ligne de commande avec l'[AWS CLI](https://aws.amazon.com/cli/). Vous disposez déjà d'un ensemble d'informations d'identification de clé d'accès. Il peut s'agir de la paire de clés d'accès attribuée à votre utilisateur IAM standard. Ou, si vous êtes connecté en tant que principal fédéré SAML ou OIDC, il peut s’agir de la paire de clés d’accès pour le rôle qui vous a été attribué initialement. Si vos autorisations actuelles vous permettent d'assumer un rôle IAM spécifique, vous pouvez identifier ce rôle dans un « profil » des fichiers de AWS CLI configuration. Cette commande est ensuite exécutée avec les autorisations du rôle IAM spécifié, pas l'identité d'origine. Notez que lorsque vous spécifiez ce profil dans une AWS CLI commande, vous utilisez le nouveau rôle. Dans ce cas, vous ne pouvez pas utiliser vos autorisations d'origine dans le compte de développement en même temps. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois. **Note** Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname). **Pour passer à un rôle de production (AWS CLI)** 1. Si vous n'avez jamais utilisé le AWS CLI, vous devez d'abord configurer votre profil CLI par défaut. Ouvrez une invite de commande et configurez votre AWS CLI installation pour utiliser la clé d'accès de votre utilisateur IAM ou de votre rôle fédéré. 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 *. Exécutez la commande [aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) comme suit : ``` aws configure ``` Lorsque vous y êtes invité, fournissez les informations suivantes : ``` AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: us-east-2 Default output format [None]: json ``` 1. Créez un profil pour le rôle dans le `.aws/config` fichier Unix ou Linux, ou le fichier `C:\Users\USERNAME\.aws\config` dans Windows. L'exemple suivant crée un profil appelé `prodaccess` qui passe au rôle `ProductionAccessRole` dans le compte `123456789012`. Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. Lorsque ce profil est invoqué, il AWS CLI utilise les informations d'identification du `source_profile` pour demander les informations d'identification du rôle. De ce fait, l'identité référencée en tant que `source_profile` doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`. ``` [profile prodaccess] role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole source_profile = default ``` 1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre est `--profile prodaccess` exécutée sous les autorisations associées au rôle IAM `ProductionAccessRole` plutôt que sous celles de l'utilisateur par défaut. ``` aws iam list-users --profile prodaccess ``` Cette commande fonctionne si les autorisations affectées au rôle `ProductionAccessRole` permettent de répertorier les utilisateurs dans le compte AWS actuel. 1. Pour revenir aux autorisations accordées par vos informations d'identification d'origine, exécutez les commandes sans le paramètre `--profile`. Vous AWS CLI recommencez à utiliser les informations d'identification de votre profil par défaut, que vous avez configuré dans[Step 1](#step-configure-default). Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *. ## Exemple de scénario : permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte Imaginez que vous en utilisiez deux Comptes AWS et que vous souhaitiez autoriser une application exécutée sur une instance Amazon EC2 à exécuter des [AWS CLI](https://aws.amazon.com/cli/)commandes dans les deux comptes. Supposons que l'instance EC2 existe dans le compte `111111111111`. Cette instance inclut le rôle de profil d'instance `abcd` qui permet à l'appli d'effectuer les tâches Amazon S3 `amzn-s3-demo-bucket1` en lecture seule sur le compartiment dans le même compte `111111111111`. Toutefois, l'application doit également être autorisée à endosser le rôle `efgh` entre comptes pour effectuer des tâches dans le compte `222222222222`. Pour ce faire, le rôle de profil d'instance EC2 `abcd` doit disposer des autorisations suivantes : ***Politique d'autorisations de rôle `abcd` du compte 111111111111*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1/*", "arn:aws:s3:::amzn-s3-demo-bucket1" ] }, { "Sid": "AllowIPToAssumeCrossAccountRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/efgh" } ] } ``` ------ Supposons que le rôle `efgh` entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment `amzn-s3-demo-bucket2` dans le même compte `222222222222`. Pour ce faire, le rôle `efgh` entre comptes doit avoir la politique d'autorisations suivante : ***Politique d'autorisations de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket2/*", "arn:aws:s3:::amzn-s3-demo-bucket2" ] } ] } ``` ------ Le rôle `efgh` doit autoriser le rôle de profil d'instance `abcd` à l'endosser. Pour ce faire, le rôle `efgh` doit avoir la politique de confiance suivante : ***Politique de confiance de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "efghTrustPolicy", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"} } ] } ``` ------ Pour exécuter ensuite AWS CLI les commandes dans le compte`222222222222`, vous devez mettre à jour le fichier de configuration de la CLI. Identifiez le rôle `efgh` en tant que « profil » et le rôle de profil d'instance EC2 `abcd` en tant que « source » d'informations d'identification dans le fichier de configuration d' AWS CLI . Ensuite, vos commandes de CLI sont exécutées avec les autorisations du rôle `efgh`, pas du rôle `abcd` d'origine. **Note** Pour des raisons de sécurité, vous pouvez AWS CloudTrail vérifier l'utilisation des rôles dans le compte. Pour différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux dans les CloudTrail journaux, vous pouvez utiliser le nom de session du rôle. Lorsque le AWS CLI assume un rôle au nom d'un utilisateur tel que décrit dans cette rubrique, un nom de session de rôle est automatiquement créé sous le nom de`AWS-CLI-session-nnnnnnnn`. *nnnnnnnn*Voici un entier qui représente l'heure en temps d'[époque Unix](http://wikipedia.org/wiki/Unix_time) (le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970). Pour plus d'informations, consultez la section [Référence aux CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le *guide de AWS CloudTrail l'utilisateur*. **Pour autoriser un rôle de profil d'instance EC2 afin de passer à un rôle entre comptes (AWS CLI)** 1. Vous n'avez pas besoin de configurer un profil par défaut pour la CLI. Au lieu de cela, vous pouvez charger les informations d'identification à partir des métadonnées du profil d'instance EC2. Créez un profil pour le rôle dans le fichier `.aws/config`. L'exemple suivant crée un profil `instancecrossaccount` qui passe au rôle `efgh` dans le compte `222222222222`. Lorsque ce profil est appelé, l’interface AWS CLI utilise les informations d'identification des métadonnées du profil d'instance EC2 pour demander les informations d'identification du rôle. De ce fait, le rôle de profil d'instance EC2 doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`. ``` [profile instancecrossaccount] role_arn = arn:aws:iam::222222222222:role/efgh credential_source = Ec2InstanceMetadata ``` 1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre `--profile instancecrossaccount` s'exécute sous les autorisations associées au `efgh` rôle dans le compte`222222222222`. ``` aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount ``` Cette commande fonctionne si les autorisations affectées au rôle `efgh` autorisent à répertorier les utilisateurs dans l' Compte AWS actuel. 1. Pour revenir au profil d'instance EC2 d'origine les autorisations de compte `111111111111`, exécutez les commandes de CLI sans le paramètre `--profile`. Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *.