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.

Passez à 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. 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 et Création d’un rôle IAM. 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.

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é en externe (SAML ou OIDC) 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 : 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.

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. 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.

Pour plus d'informations, consultez Endossement d'un rôle 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 commandes sur 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 compte222222222222, 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.

Pour plus d'informations, consultez Endossement d'un rôle dans le Guide de l'utilisateur AWS Command Line Interface .