Utilisation d'un rôle IAM dans AWS CLI

Cette documentation concerne AWS CLI uniquement la version 1 du. Pour la documentation relative à la version 2 du AWS CLI, consultez le guide de l'utilisateur de la version 2.

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.

Cette documentation concerne AWS CLI uniquement la version 1 du. Pour la documentation relative à la version 2 du AWS CLI, consultez le guide de l'utilisateur de la version 2.

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.

Un rôle AWS Identity and Access Management (IAM) est un outil d'autorisation qui permet à un utilisateur d'obtenir des autorisations supplémentaires (ou différentes), ou d'obtenir des autorisations pour effectuer des actions dans un autre AWS compte.

Prérequis

Pour exécuter les iam commandes, vous devez installer et configurer le AWS CLI. Cela inclut la configuration d'un profil configuré, en supposant qu'un rôle soit associé à une autre méthode d'identification. Pour de plus amples informations, veuillez consulter Installation, mise à jour et désinstallation du AWS CLI.

Vue d'ensemble de l'utilisation des rôles IAM

Vous pouvez configurer le AWS Command Line Interface (AWS CLI) pour utiliser un rôle IAM en définissant un profil pour le rôle dans le ~/.aws/config fichier.

L'exemple suivant illustre un profil de rôle nommé marketingadmin. Si vous exécutez des commandes avec --profile marketingadmin (ou si vous le spécifiez avec la variable d'AWS_PROFILE environnement), AWS CLI utilise les informations d'identification définies dans un profil distinct user1 pour assumer le rôle avec l'Amazon Resource Name (ARN)arn:aws:iam::123456789012:role/marketingadminrole. Vous pouvez exécuter toutes les opérations permises par les autorisations affectées à ce rôle.

[profile marketingadmin]
role_arn = arn:aws:iam::123456789012:role/marketingadminrole
source_profile = user1

Vous pouvez ensuite spécifier un source_profile qui pointe vers un profil nommé distinct contenant les informations d'identification des utilisateurs autorisés à utiliser le rôle. Dans l'exemple précédent, le profil marketingadmin utilise les informations d'identification du profil user1. Lorsque vous spécifiez qu'une AWS CLI commande doit utiliser le profilmarketingadmin, elle recherche AWS CLI automatiquement les informations d'identification du user1 profil lié et les utilise pour demander des informations d'identification temporaires pour le rôle IAM spécifié. Pour ce faire, la CLI utilise l'AssumeRoleopération sts : en arrière-plan. Ces informations d'identification temporaires sont ensuite utilisées pour exécuter la AWS CLI commande demandée. Le rôle spécifié doit être associé à des politiques d'autorisation IAM autorisant l'exécution de la AWS CLI commande demandée.

Pour exécuter une AWS CLI commande depuis une instance Amazon Elastic Compute Cloud (Amazon EC2) ou un conteneur Amazon Elastic Container Service (Amazon ECS), vous pouvez utiliser un rôle IAM associé au profil d'instance ou au conteneur. Si vous ne spécifiez aucun profil ou ne définissez aucune variable d'environnement, ce rôle est utilisé directement. Cela vous permet d'éviter de stocker des clés d'accès à longue durée de vie sur vos instances. Vous pouvez également utiliser ces rôles d'instance ou de conteneur uniquement pour obtenir les informations d'identification d'un autre rôle. Pour ce faire, vous devez utiliser credential_source (au lieu de source_profile) pour spécifier comment trouver les informations d'identification. L'attribut credential_source prend en charge les valeurs suivantes :

L'exemple suivant montre le même marketingadminrole rôle que celui utilisé pour référencer un profil d' EC2 instance Amazon.

[profile marketingadmin]
role_arn = arn:aws:iam::123456789012:role/marketingadminrole
credential_source = Ec2InstanceMetadata

Lorsque vous appelez un rôle, vous disposez d'options supplémentaires dont vous pouvez avoir besoin, telles que l'utilisation d'une authentification multifacteur et d'un ID externe (utilisé par des sociétés tierces pour accéder aux ressources de leurs clients). Vous pouvez également spécifier des noms de session de rôle uniques qui peuvent être audités plus facilement dans AWS CloudTrail les journaux.

Configuration et utilisation d'un rôle

Lorsque vous exécutez des commandes à l'aide d'un profil qui spécifie un rôle IAM, il AWS CLI utilise les informations d'identification du profil source pour appeler AWS Security Token Service (AWS STS) et demander des informations d'identification temporaires pour le rôle spécifié. L'utilisateur dans le profil source doit avoir l'autorisation d'appeler sts:assume-role pour le rôle dans le profil spécifié. Le rôle doit avoir une relation d'approbation qui permet à l'utilisateur dans le profil source d'utiliser le rôle. Le processus de récupération, puis d'utilisation d'informations d'identification temporaires pour un rôle revient à assumer le rôle.

Vous pouvez créer un rôle dans IAM avec les autorisations que vous souhaitez que les utilisateurs assument en suivant la procédure décrite dans la section Création d'un rôle pour déléguer des autorisations à un utilisateur IAM dans le Guide de l'AWS Identity and Access Management utilisateur. Si le rôle et l'utilisateur du profil source sont dans le même compte, vous pouvez entrer votre propre ID de compte lors de la configuration de la relation de confiance du rôle.

Une fois le rôle créé, modifiez la relation de confiance afin d'autoriser l'utilisateur à assumer ce rôle.

L'exemple suivant illustre une stratégie d'approbation que vous pouvez attacher à un rôle. Cette politique permet que le rôle soit assumé par n'importe quel utilisateur du compte 123456789012, si l'administrateur de ce compte accorde explicitement l'autorisation à l'sts:AssumeRoleutilisateur.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

La stratégie d'approbation n'accorde pas actuellement d'autorisations. L'administrateur du compte doit déléguer l'autorisation d'assumer le rôle à des utilisateurs individuels en associant une stratégie aux autorisations appropriées. L'exemple suivant montre une politique que vous pouvez associer à un utilisateur et qui permet à ce dernier d'assumer uniquement le marketingadminrole rôle. Pour plus d'informations sur l'octroi à un utilisateur de l'accès lui permettant d'assumer un rôle, consultez la section Octroi à un utilisateur de l'autorisation de changer de rôle dans le guide de l'utilisateur IAM.

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

L'utilisateur n'a pas besoin d'autorisations supplémentaires pour exécuter les AWS CLI commandes à l'aide du profil de rôle. Au lieu de cela, les autorisations pour exécuter la commande proviennent de celles qui sont attachées au rôle. Vous associez des politiques d'autorisation au rôle pour spécifier quelles actions peuvent être effectuées sur quelles AWS ressources. Pour plus d'informations sur l'attribution d'autorisations à un rôle (qui fonctionne de la même manière que pour un utilisateur), consultez la section Modification des autorisations pour un utilisateur IAM dans le guide de l'utilisateur IAM.

Maintenant que vous avez correctement configuré le profil de rôle, les autorisations de rôle, la relation d'approbation du rôle et les autorisations utilisateur, vous pouvez utiliser ce rôle au niveau de la ligne de commande en appelant l'option --profile. Par exemple, ce qui suit appelle la ls commande Amazon S3 en utilisant les autorisations associées au marketingadmin rôle, telles que définies dans l'exemple au début de cette rubrique.

$ aws s3 ls --profile marketingadmin

Si vous souhaitez utiliser le rôle pour plusieurs appels, vous pouvez définir la variable d'environnement AWS_PROFILE pour la session en cours à partir de la ligne de commande. Lorsque cette variable d'environnement est définie, vous n'avez pas besoin de spécifier l'option --profile pour chaque commande.

Linux ou macOS

$ export AWS_PROFILE=marketingadmin

Windows

C:\> setx AWS_PROFILE marketingadmin

Pour plus d'informations sur la configuration des utilisateurs et des rôles, consultez les sections Identités IAM (utilisateurs, groupes d'utilisateurs et rôles) et rôles IAM dans le guide de l'utilisateur IAM.

Utilisation de l'authentification multi-facteurs

Pour une sécurité accrue, vous pouvez exiger que les utilisateurs fournissent une clé à usage unique générée à partir d'un périphérique d'authentification multi-facteurs (MFA), d'un appareil U2F ou d'une application mobile lorsqu'ils essaient d'effectuer un appel en utilisant le profil de rôle.

Tout d'abord, vous pouvez choisir de modifier la relation de confiance sur le rôle IAM pour exiger l'authentification MFA. De cette façon, aucun utilisateur ne peut utiliser le rôle sans l'authentification MFA. Pour obtenir un exemple, consultez la ligne Condition dans l'exemple suivant. Cette politique permet à l'utilisateur nommé d'anikaassumer le rôle auquel la politique est attachée, mais uniquement s'il s'authentifie à l'aide de la MFA.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/anika" },
      "Action": "sts:AssumeRole",
      "Condition": { "Bool": { "aws:multifactorAuthPresent": true } }
    }
  ]
}

Ajoutez ensuite une ligne au profil de rôle qui spécifie l'ARN du périphérique MFA de l'utilisateur. Les exemples d'entrées de config fichier suivants présentent deux profils de rôle qui utilisent tous deux les clés d'accès permettant anika à l'utilisateur de demander des informations d'identification temporaires pour le rôlecli-role. L'utilisateur anika dispose des autorisations requises pour assumer le rôle, accordées par la stratégie d'approbation du rôle.

[profile role-without-mfa]
region = us-west-2
role_arn= arn:aws:iam::128716708097:role/cli-role
source_profile=cli-user

[profile role-with-mfa]
region = us-west-2
role_arn= arn:aws:iam::128716708097:role/cli-role
source_profile = cli-user
mfa_serial = arn:aws:iam::128716708097:mfa/cli-user

[profile cli-user]
region = us-west-2
output = json

Le paramètre mfa_serial peut utiliser un ARN, comme indiqué, ou le numéro de série d'un jeton MFA matériel.

Le premier profil, role-without-mfa, ne nécessite pas d’authentification MFA. Cependant, étant donné que l'exemple précédent de stratégie d'approbation attachée au rôle exige l'authentification MFA, toute tentative d'exécuter une commande avec ce profil échoue.

$ aws iam list-users --profile role-without-mfa

An error occurred (AccessDenied) when calling the AssumeRole operation: Access denied

La deuxième entrée de profil, role-with-mfa, identifie un périphérique MFA à utiliser. Lorsque l'utilisateur tente d'exécuter une AWS CLI commande avec ce profil, il est AWS CLI invité à saisir le mot de passe à usage unique (OTP) fourni par le dispositif MFA. Si l'authentification MFA réussit, la commande exécute l'opération demandée. L'OTP ne s’affiche pas à l'écran.

$ aws iam list-users --profile role-with-mfa
Enter MFA code for arn:aws:iam::123456789012:mfa/cli-user:
{
    "Users": [
        {
            ...

Rôles entre comptes et ID externe

Vous pouvez permettre aux utilisateurs d'utiliser des rôles qui appartiennent à différents comptes en configurant le rôle en tant que rôle entre comptes. Lors de la création du rôle, définissez le type de rôle sur Autre AWS compte, comme décrit dans Création d'un rôle pour déléguer des autorisations à un utilisateur IAM. Le cas échéant, sélectionnez MFA obligatoire. L'option MFA obligatoire configure la condition appropriée dans la relation de confiance comme décrit dans la section Utilisation de l'authentification multi-facteurs.

Si vous utilisez un ID externe pour accorder un contrôle supplémentaire aux personnes susceptibles d'utiliser un rôle entre les comptes, vous devez ajouter le paramètre external_id au profil de rôle. Généralement, vous utilisez uniquement cette option lorsque l'autre compte est contrôlé par une personne qui ne fait pas partie de votre entreprise ou organisation.

[profile crossaccountrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/saanvi
external_id = 123456

Spécification d'un nom de session de rôle pour faciliter l'audit

Lorsque de nombreuses personnes partagent un rôle, la vérification devient plus difficile. Vous souhaitez associer chaque opération appelée à la personne à l’origine de cet appel. Toutefois, lorsque la personne utilise un rôle, la prise en charge du rôle est une action distincte de l'appel d'une opération, et vous devez corréler les deux manuellement.

Vous pouvez simplifier cela en spécifiant des noms de session de rôle uniques lorsque les utilisateurs assument un rôle. Pour ce faire, vous devez ajouter un paramètre role_session_name à chaque profil nommé dans le fichier config qui spécifie un rôle. La valeur de role_session_name est transmise à l'opération AssumeRole et devient partie intégrante de l'ARN de la session de rôle. Il est également inclus dans les AWS CloudTrail journaux de toutes les opérations enregistrées.

Par exemple, vous pouvez créer un profil basé sur le rôle comme suit :

[profile namedsessionrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
source_profile = default
role_session_name = Session_Maria_Garcia

La session de rôle prend alors l'ARN suivant :

arn:aws:iam::234567890123:assumed-role/SomeRole/Session_Maria_Garcia

En outre, tous les AWS CloudTrail journaux incluent le nom de session du rôle dans les informations capturées pour chaque opération.

Utilisation d'un rôle à l'aide d'une identité web

Vous pouvez configurer un profil pour indiquer qu'il AWS CLI doit assumer un rôle à l'aide de la fédération d'identité Web et d'Open ID Connect (OIDC). Lorsque vous le spécifiez dans un profil, il AWS CLI passe automatiquement l' AWS STS AssumeRoleWithWebIdentityappel correspondant pour vous.

Pour récupérer et utiliser des informations d'identification temporaires à l'aide de la fédération d'identité web, vous pouvez spécifier les valeurs de configuration suivantes dans un profil partagé :

Voici un exemple de configuration pour la configuration minimale requise pour configurer un profil de rôle de responsable avec profil identité web :

# In ~/.aws/config

[profile web-identity]
role_arn=arn:aws:iam:123456789012:role/RoleNameToAssume
web_identity_token_file=/path/to/a/token

Vous pouvez également fournir cette configuration à l'aide de variables d'environnement :

Suppression des informations d'identification mises en cache

Lorsque vous utilisez un rôle, les informations d'identification temporaires sont mises en AWS CLI cache localement jusqu'à leur expiration. La prochaine fois que vous essaierez de les utiliser, ils AWS CLI essaieront de les renouveler en votre nom.

Si les informations d'identification temporaires de votre rôle sont révoquées, elles ne sont pas renouvelées automatiquement et les tentatives d’utilisation échouent. Cependant, vous pouvez supprimer le cache pour forcer le AWS CLI à récupérer de nouvelles informations d'identification.

Linux ou macOS

$ rm -r ~/.aws/cli/cache

Windows

C:\> del /s /q %UserProfile%\.aws\cli\cache