Cette documentation concerne AWS CLI uniquement la version 1. 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.
Utiliser un IAM rôle dans AWS CLI
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.
Rubriques
- Prérequis
- Vue d'ensemble de l'utilisation IAM des rôles
- Configuration et utilisation d'un rôle
- Utilisation de l'authentification multi-facteurs
- Rôles entre comptes et ID externe
- Spécification d'un nom de session de rôle pour faciliter l'audit
- Utilisation d'un rôle à l'aide d'une identité web
- Suppression des informations d'identification mises en cache
Prérequis
Pour exécuter les iam
commandes, vous devez installer et configurer le AWS CLI. Pour de plus amples informations, veuillez consulter Installation, mise à jour et désinstallation du AWS CLI.
Vue d'ensemble de l'utilisation IAM des rôles
Vous pouvez configurer le AWS Command Line Interface (AWS CLI) pour utiliser un IAM rôle 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_PROFILEenvironnement), AWS CLI utilise les informations d'identification définies dans un profil distinct user1
pour assumer le rôle associé à l'Amazon Resource Name (ARN)arn:aws:iam::
. Vous pouvez exécuter toutes les opérations permises par les autorisations affectées à ce rôle.123456789012
:role/marketingadminrole
[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 IAM rôle spécifié. Il CLI utilise l'AssumeRoleopération sts : en arrière-plan pour ce faire. 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'IAMautorisation 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 (AmazonEC2) ou un conteneur Amazon Elastic Container Service (AmazonECS), vous pouvez utiliser un IAM rôle 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 :
-
Environment
— Récupère les informations d'identification de la source à partir des variables d'environnement. -
Ec2InstanceMetadata
— Utilise le IAM rôle associé au profil d'EC2instance Amazon. -
EcsContainer
— Utilise le IAM rôle associé au ECS conteneur Amazon.
L'exemple suivant montre le même marketingadminrole
rôle que celui utilisé pour référencer un profil d'EC2instance 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 IAM rôle, 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 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 IAM utilisateur dans le Guide de AWS Identity and Access Management l'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:AssumeRole
utilisateur.
{ "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 IAM l'utilisateur.
{ "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 IAM d'un utilisateur dans le Guide de l'IAMutilisateur.
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 la section IAMIdentités (utilisateurs, groupes d'utilisateurs et rôles) et IAMrôles dans le Guide de IAM l'utilisateur.
Utilisation de l'authentification multi-facteurs
Pour plus de sécurité, vous pouvez demander aux utilisateurs de fournir une clé à usage unique générée à partir d'un appareil d'authentification multifactorielle (MFA), d'un appareil U2F ou d'une application mobile lorsqu'ils tentent de passer un appel à l'aide du profil de rôle.
Tout d'abord, vous pouvez choisir de modifier la relation de confiance associée au IAM rôle requisMFA. Cela empêche quiconque d'utiliser le rôle sans s'authentifier au préalable en utilisantMFA. Pour obtenir un exemple, consultez la ligne Condition
dans l'exemple suivant. Cette politique permet anika
à l'utilisateur nommé d'assumer le rôle auquel la politique est attachée, mais uniquement s'il s'authentifie en utilisantMFA.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/anika" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:multifactorAuthPresent": true } } } ] }
Ensuite, ajoutez une ligne au profil de rôle qui spécifie l'MFAappareil ARN 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 mfa_serial
réglage peut prendre unARN, comme indiqué, ou le numéro de série d'un MFA jeton matériel.
Le premier profilrole-without-mfa
, ne nécessite pasMFA. Cependant, étant donné que l'exemple précédent de politique de confiance associé au rôle l'exigeMFA, toute tentative d'exécution d'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 role-with-mfa
profil identifie un MFA appareil à 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 MFA terminal. Si l'MFAauthentification réussit, la commande exécute l'opération demandée. Le n'OTPest pas affiché à 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 IAM utilisateur. Vous pouvez éventuellement sélectionner Exiger MFA. MFARequire configure les conditions appropriées dans la relation de confiance, comme décrit dansUtilisation 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 role_session_name
valeur est transmise à l'AssumeRole
opération et fait partie de la session ARN pour le 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
Il en résulte que la session de rôle présente les caractéristiques suivantesARN.
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 AssumeRoleWithWebIdentity
appel correspondant pour vous.
Note
Lorsque vous spécifiez un profil qui utilise un IAM rôle, il AWS CLI effectue les appels appropriés pour récupérer les informations d'identification temporaires. Ces informations d'identification sont stockées dans ~/.aws/cli/cache
. Les AWS CLI commandes suivantes qui spécifient le même profil utilisent les informations d'identification temporaires mises en cache jusqu'à leur expiration. À ce stade, les informations d'identification AWS CLI sont automatiquement actualisées.
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é :
- role_arn
-
Spécifie ARN le rôle à assumer.
- web_identity_token_file
-
Spécifie le chemin d'accès à un fichier contenant un jeton d'accès OAuth 2.0 ou un jeton d'identification OpenID Connect fourni par le fournisseur d'identité. L’ AWS CLI charge ce fichier et transmet son contenu en tant qu'argument
WebIdentityToken
de l'opérationAssumeRoleWithWebIdentity
. - role_session_name
-
Spécifie un nom facultatif appliqué à cette session assume-role.
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 :
- AWS_ROLE_ARN
-
Le ARN rôle à assumer.
- AWS_WEB_IDENTITY_TOKEN_FILE
-
Chemin d'accès au fichier de jeton d'identité web.
- AWS_ROLE_SESSION_NAME
-
Nom appliqué à cette session assume-role.
Note
Ces variables d'environnement s'appliquent actuellement uniquement au rôle « assume » avec le fournisseur d'identité web. Ils ne s'appliquent pas à la configuration générale du fournisseur de rôle.
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