Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des rôles IAM - AWS Identity and Access Management

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.

Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des rôles IAM

Ce tutoriel vous explique comment utiliser un rôle pour déléguer l'accès aux ressources situées dans différents Comptes AWS vous appartenant, un rôle appelé Production et Development (Développement). 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.

Note

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.

Dans ce tutoriel, le compte production gère les applications en direct. Les développeurs et les testeurs utilisent le compte développement comme environnement de test (sandbox) pour tester librement les applications. Dans chaque compte, vous stockez les informations de l'application dans des compartiments Amazon S3. Vous gérez des utilisateurs IAM dans le compte développement, où vous disposez de deux groupes d'utilisateurs IAM : les développeurs et les testeurs. Les utilisateurs des deux groupes d'utilisateurs ont des autorisations pour travailler dans le compte Développement et y accéder aux ressources qui s'y trouvent. De temps à autre, un développeur doit mettre à jour les applications en direct dans le compte production. Les développeurs stockent ces applications dans un compartiment Amazon S3 appelé productionapp.

Au terme de ce tutoriel, vous disposerez des éléments suivants :

  • Utilisateurs du compte développement (le compte approuvé) autorisés à endosser un rôle spécifique dans le compte production.

  • Rôle du compte production (le compte d'approbation) autorisé à accéder à un compartiment Amazon S3 spécifique.

  • Le compartiment productionapp dans le compte production.

Les développeurs peuvent utiliser le rôle indiqué dans le AWS Management Console pour accéder au productionapp compartiment dans le compte Production. 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 testeurs pour utiliser le rôle échouent.

Ce flux de travail se compose de trois étapes de base :

Créer un rôle dans le compte production

Tout d'abord, vous utilisez le AWS Management Console pour établir un lien de confiance entre le compte de production (numéro d'identification 999999999999) et le compte de développement (numéro d'identification 111111111111). Vous commencez par créer un rôle IAM nommé UpdateApp. Lorsque vous créez le rôle, vous définissez le compte développement en tant qu'entité approuvée et spécifiez une politique d'autorisations qui autorise les utilisateurs de confiance à mettre à jour le compartiment productionapp.

Accorder l'accès au rôle

Dans cette section, vous modifiez la politique de groupe d'utilisateurs IAM pour refuser aux testeurs l'accès au rôle UpdateApp. Parce que les testeurs 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

Enfin, en tant que développeur, vous utilisez le rôle UpdateApp pour mettre à jour le compartiment productionapp dans le compte production. Vous allez voir comment accéder au rôle via la AWS console, le AWS CLI, et l'API.

Prérequis

Le didacticiel présume que vous avez déjà ce qui suit en place :

  • Deux éléments distincts Comptes AWS que vous pouvez utiliser, l'un pour représenter le compte de développement et l'autre pour le compte de production.

  • Les utilisateurs et les groupes d'utilisateurs du compte développement créés et configurés comme suit :

    Utilisateur Groupe d'utilisateurs Autorisations
    David Développeurs Les deux utilisateurs peuvent se connecter et utiliser AWS Management Console le compte de développement.
    Jane Testeurs
  • Vous n'avez pas besoin d'avoir des utilisateurs ou des groupes d'utilisateurs créés dans le compte production.

  • Un compartiment Amazon S3 créé dans le compte production. Vous pouvez l'appeler ProductionApp 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éer un rôle dans le compte production

Vous pouvez autoriser les utilisateurs de l'un Compte AWS à accéder aux ressources d'un autre Compte AWS. Pour ce faire, créez 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 tutoriel, vous créez le rôle dans le compte production et spécifiez le compte développement comme entité approuvée. Vous limitez également les autorisations du rôle à un accès en lecture seule et en écriture au compartiment productionapp. Toute personne ayant autorisation d'utiliser le rôle peut lire et écrire dans le compartiment productionapp.

Avant de créer un rôle, vous avez besoin de l'ID de compte du développement Compte AWS. Chacun Compte AWS possède un identifiant de compte unique qui lui est attribué.

Pour obtenir l' Compte AWS ID de développement
  1. Connectez-vous au compte de développement en AWS Management Console tant qu'administrateur et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.

  2. Dans la barre de navigation, sélectionnez Support, puis Support Center (Centre de support). Le numéro de compte (ID) à 12 chiffres avec lequel vous êtes actuellement connecté apparaît dans le panneau de navigation Support Center (Centre de support). Pour ce scénario, vous pouvez utiliser l'ID 111111111111 pour le compte développement. 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 de production qui peut être utilisé par le compte de développement
  1. Connectez-vous en AWS Management Console tant qu'administrateur du compte de production et ouvrez la console IAM.

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

  3. 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:::productionapp) par celui qui correspond véritablement à votre compartiment Amazon S3.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] }

    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 productionapp. Les autorisations GetObject, PutObject, DeleteObject permettent aux utilisateurs d'afficher, de mettre à jour et de supprimer le contenu du compartiment productionapp.

  4. 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, puis choisissez Suivant.

    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 plus d’informations, consultez Restructuration de politique.

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

  6. Dans le panneau de navigation, choisissez Roles (Rôles), puis Create role (Créer un rôle).

  7. Choisissez le type de rôle Un Compte AWS.

  8. Pour l'ID de compte, saisissez l'ID du compte développement.

    Ce tutoriel utilise l'exemple d'ID de compte 111111111111 pour le compte développement. 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 Utilisation de l'authentification multifactorielle (MFA) dans AWS.

  9. Choisissez suivant : autorisations pour configurer les autorisations associées au rôle.

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

  11. (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 Balisage des ressources IAM.

  12. (Facultatif) Pour Description, saisissez une description pour le nouveau rôle.

  13. Après avoir procédé à la révision du rôle, sélectionnez Créer un rôle.

    Le rôle UpdateApp 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 la politique de groupe d'utilisateurs développeurs et testeurs, vous spécifiez l'ARN du rôle pour accorder ou refuser les autorisations.

Pour obtenir l'ARN pour UpdateApp
  1. Dans le panneau de navigation de la console IAM, sélectionnez Roles (Rôles).

  2. Dans la liste des rôles, sélectionnez le rôle UpdateApp.

  3. Dans la section Récapitulatif du panneau des détails, copiez la valeur du champ ARN de rôle.

    Le compte Production ayant pour ID de compte 999999999999, l'ARN du rôle est donc arn:aws:iam::999999999999:role/UpdateApp. Assurez-vous de fournir le véritable Compte AWS identifiant du compte de production.

À ce stade, vous avez établi la confiance entre les comptes production et développement. Pour ce faire, créez un rôle dans le compte production qui identifie le compte développement en tant que principal compte de confiance. Vous avez également défini ce que les utilisateurs qui basculent vers le rôle UpdateApp peuvent faire.

Ensuite, modifiez les autorisations pour les groupes d'utilisateurs.

Accorder l'accès au rôle

À ce stade, les membres des groupes d'utilisateurs testeurs et développeurs disposent d'autorisations leur permettant de tester librement des applications dans le compte développement. Utilisez la procédure requise pour ajouter des autorisations visant à autoriser le changement de rôle.

Pour modifier le groupe d'utilisateurs des développeurs afin de leur permettre de passer au UpdateApp rôle
  1. Connectez-vous en tant qu'administrateur dans le compte développement, puis ouvrez la console IAM.

  2. Sélectionnez User groups (Groupes d'utilisateurs), puis Developers (Développeurs).

  3. Sélectionnez l'onglet Permissions (Autorisations), puis Add permissions (Ajouter des autorisations), et enfin Create inline policy (Créer une politique en ligne).

  4. Sélectionnez l’onglet JSON.

  5. Ajoutez l'instruction de politique suivante pour autoriser l'action AssumeRole sur le rôle UpdateApp dans le compte Production. Assurez-vous de remplacer PRODUCTION-ACCOUNT-ID dans l'Resourceélément par l' Compte AWS ID réel du compte de production.

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    L'effet Allow autorise explicitement l'accès du groupe Développeurs au rôle UpdateApp dans le compte Production. Tout développeur qui essaie d'accéder à ce rôle y parvient.

  6. Choisissez Examiner une politique.

  7. Tapez un Nom, tel que allow-assume-S3-role-in-production.

  8. Choisissez 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 Testeurs 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 groupe d'utilisateurs testeurs afin de lui refuser l'autorisation d'endosser le rôle UpdateApp
  1. Choisissez User groups (groupes d'utilisateurs), puis Testers (testeurs).

  2. Sélectionnez l'onglet Permissions (Autorisations), puis Add permissions (Ajouter des autorisations), et enfin Create inline policy (Créer une politique en ligne).

  3. Sélectionnez l’onglet JSON.

  4. Ajoutez l'instruction de politique suivante pour refuser l'action AssumeRole sur le rôle UpdateApp. Assurez-vous de remplacer PRODUCTION-ACCOUNT-ID dans l'Resourceélément par l' Compte AWS ID réel du compte de production.

    { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

    L'effet Deny refuse explicitement l'accès du groupe Testeurs au rôle UpdateApp dans le compte Production. Tout testeur qui essaiera d'accéder au rôle recevra un message d'accès refusé.

  5. Choisissez Examiner une politique.

  6. Tapez un Nom comme deny-assume-S3-role-in-production.

  7. Sélectionnez Créer une politique.

Le groupe d'utilisateurs Développeurs a maintenant l'autorisation d'utiliser le rôle UpdateApp dans le compte Production. Le groupe d'utilisateurs Testeurs ne peut pas utiliser le rôle UpdateApp.

Ensuite, vous pouvez voir comment David, un développeur, peut accéder au compartiment productionapp dans le compte production. 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 tutoriel, vous disposez d'un rôle qui accorde l'accès à une ressource du compte production. Vous disposez également d'un groupe d'utilisateurs dans le compte développement 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.

Important

Il est possible de passer à un rôle uniquement si vous vous connectez en tant qu'utilisateur IAM ou en tant qu'utilisateur fédéré. En outre, si vous lancez une instance Amazon EC2 pour exécuter une application, l'application peut endosser un rôle via son profil d'instance. Il n'est pas possible de passer à un rôle si vous vous connectez en tant qu' Utilisateur racine d'un compte AWS.

Changer de rôle (console)

Si David doit travailler dans l'environnement de production du 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 productionapp, mais il ne peut pas utiliser d'autres ressources de l'environnement production. Bien que David utilise le rôle, il ne peut pas non plus utiliser ses privilèges d'utilisateur avancé dans le compte développement. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois.

Important

Le changement de rôle à l'aide du AWS Management Console ne fonctionne qu'avec les comptes qui ne nécessitent pas deExternalId. 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 ne peut pas fournir de valeur pour ExternalId. Pour plus d'informations sur ce scénarioComment utiliser un identifiant externe lorsque vous accordez l'accès à vos AWS ressources à un tiers, consultez la section « Comment activer l'accès entre comptes » AWS Management Console dans le blog sur la AWS sécurité.

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 Switch Role (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 normal dans le groupe d'utilisateurs de développement.

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

  3. Ensuite, pour accéder au rôle, David doit saisir manuellement le numéro d'ID (999999999999) et le nom du rôle (UpdateApp) du compte Production.

    En outre, David souhaite contrôler les rôles et les autorisations associées actuellement actifs dans IAM. Pour suivre ces informations, il saisit PRODUCTION dans la zone de texte Display Name (nom complet), choisit l'option de couleur rouge, puis choisit Switch Role (changer de rôle).

  4. David peut maintenant utiliser la console Amazon S3 pour travailler avec le compartiment Amazon S3 ou toute autre ressource pour laquelle le rôle UpdateApp dispose d'autorisations.

  5. Quand c'est fait, David peut retourner dans ses autorisations d'origine. Pour cela, il choisit le nom complet du rôle PRODUCTION sur la barre de navigation, puis il sélectionne Back to David @ 111111111111 (Revenir à David @ 111111111111).

  6. La prochaine fois que David voudra changer de rôle et choisira le menu Identity (identité) dans la barre de navigation, il verra l'entrée PRODUCTION 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 production dans la ligne de commande, il peut y parvenir grâce à l'outil AWS 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 développement, 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 dans le guide de l'utilisateur de l'outil AWS Command Line Interface .

  2. Il commence le processus de changement de rôle en exécutant la commande suivante pour passer au rôle UpdateApp dans le compte production. 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/UpdateApp" --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" } }
  3. 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. 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.

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

    Note

    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 Passer à un rôle IAM (Outils pour Windows PowerShell)

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

  5. Exécutez la commande pour accéder aux ressources du compte Production. Dans cet exemple, David répertorie simplement le contenu de son compartiment S3 avec la commande suivante.

    aws s3 ls s3://productionapp

    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 production depuis le code, il réalise un appel AssumeRole pour endosser le rôle UpdateApp. L'appel renvoie des informations d'identification temporaires qu'il peut utiliser pour accéder au compartiment productionapp dans le compte production. Grâce à ces informations d'identification, David peut réaliser des appels d'API pour mettre à jour le compartiment productionapp. Cependant, il ne peut pas réaliser des appels d'API pour accéder aux autres ressources du compte production, même s'il a des autorisations d'utilisateur avancé dans le compte développement.

Pour endosser un rôle
  1. David appelle AssumeRole dans le cadre d'une application. Il doit spécifier l'ARN UpdateApp : arn:aws:iam::999999999999:role/UpdateApp.

    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.

  2. Grâce aux informations d'identification de sécurité temporaires, David réalise un appel s3:PutObject pour mettre à jour le compartiment productionapp. 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 productionapp, toute autre action dans le compte Production est refusée.

Pour obtenir un exemple de code (à l'aide de Python), veuillez consulter Passage à un rôle IAM (AWS API).

Récapitulatif

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 groupe d'utilisateurs pour contrôler les utilisateurs IAM qui peuvent accéder au rôle. Par conséquent, les développeurs du compte développement peuvent faire des mises à jour dans le compartiment productionapp du compte production à l'aide d'informations d'identification temporaires.