AWS Identity and Access Management
Guide de l'utilisateur

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

Ce didacticiel vous explique comment utiliser un rôle pour déléguer l'accès aux ressources situées dans différents comptes AWS que vous possédez (Production et Développement). Vous partagerez les ressources d'un compte avec les utilisateurs d'un autre compte. En configurant l'accès entre 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 pour pouvoir accéder aux ressources situées dans des comptes AWS différents. Après avoir configuré le rôle, vous apprendrez comment utiliser celui-ci dans AWS Management Console, l'AWS CLI et l'API.

Dans ce didacticiel, imaginez que le compte Production soit l'emplacement où les applications dynamiques sont gérées et que le compte Développement est un environnement de test (sandbox) où les développeurs et les testeurs peuvent tester librement les applications. Dans chaque compte, les informations de l'application sont stockées dans des compartiments Amazon S3. Vous gérez des utilisateurs IAM dans le compte Développement, où vous disposez de deux groupes IAM : les Développeurs et les Testeurs. Les utilisateurs des deux groupes 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 dynamiques dans le compte Production. Ces applications sont stockées dans un compartiment Amazon S3 appelé productionapp.

À la fin de ce didacticiel, vous disposerez d'un rôle dans le compte Production (le compte d'approbation) qui permet aux utilisateurs du compte Développement (le compte approuvé) d'accéder au compartiment productionapp du compte Production. Les développeurs peuvent se servir du rôle d'AWS Management Console pour accéder au compartiment productionapp dans le compte Production. Ils peuvent également accéder au compartiment à l'aide des appels d'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.

Étape 1 : Créer un rôle

D'abord, vous utilisez AWS Management Console pour établir la confiance entre le compte Production (numéro d'ID 999999999999) et le compte Développement (numéro d'ID 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écifier une stratégie d'autorisations qui autorise les utilisateurs à mettre à jour le compartiment productionapp.

Étape 2 : Accorder l'accès au rôle

Dans cette étape du didacticiel, vous modifiez la stratégie de groupe IAM de sorte que l'accès des testeurs au rôle UpdateApp soit refusé. Du fait que les testeurs ont un accès PowerUser dans ce scénario, nous devons refuser explicitement la capacité d'utiliser le rôle.

Étape 3 : 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 voyez comment accéder au rôle à l'aide de la console AWS, de l'AWS CLI ou de l'API.

Prérequis

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

  • Deux comptes AWS distincts que vous pouvez utiliser, l'un pour représenter le compte Développement, et l'autre pour représenter le compte Production.

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

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

  • Un compartiment Amazon S3 créé dans le compte Production. Nous l'appelons ProductionApp dans ce didacticiel, mais du fait que les noms de compartiment S3 doivent être globalement uniques, vous devrez utiliser un compartiment avec un nom différent.

Étape 1 : Créer un rôle

Pour autoriser les utilisateurs d'un compte AWS à accéder aux ressources d'un autre compte AWS, créez un rôle définissant qui peut y accéder et quelles autorisations il accorde aux utilisateurs qui basculent vers lui.

Dans cette étape du didacticiel, vous créez le rôle dans le compte Production et spécifiez le compte Développement compte entité approuvée. Vous limitez également les autorisations du rôle à un accès en lecture et en écriture seules 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 compte AWS Développement. L'ID de compte est un identifiant unique attribué à chaque compte AWS.

Pour obtenir l'ID du compte AWS Développement

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

  2. Dans la barre de navigation, choisissez Support, puis Centre de support. Le Numéro de compte se situe dans le coin supérieur droit immédiatement sous le menu Support. L'ID de compte est un numéro à 12 chiffres. Dans ce scenario, imaginons que l'ID du compte Développement est 111111111111. Toutefois, vous devez utiliser un ID de compte valide si vous reproduisez le scenario dans votre environnement de test.

Pour créer un rôle dans le compte Production qui peut être utilisé par le compte Développement

  1. Connectez-vous à AWS Management Console en tant qu'administrateur du compte Production, et ouvrez la console IAM.

  2. Avant de créer le rôle, préparez la stratégie gérée qui définit les autorisations qu'exige le rôle. Vous attachez cette stratégie au rôle dans une étape ultérieure.

    Vous devez définir l'accès en lecture et en écriture au compartiment productionapp. Bien qu'AWS fournisse des stratégies gérées Amazon S3, il n'en existe pas qui offre un accès en lecture et en écriture à un seul compartiment Amazon S3. Créez votre propre stratégie à la place.

    Dans le panneau de navigation à gauche, choisissez Stratégies, puis Créer une stratégie.

  3. Choisissez l'onglet JSON et copiez le texte du document de stratégie 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 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'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. Lorsque vous avez terminé, choisissez Examiner une stratégie. Le programme de validation de stratégie signale les éventuelles erreurs de syntaxe.

    Note

    Vous pouvez basculer à tout moment entre les onglets Éditeur visuel et JSON. Toutefois, si vous apportez des modifications ou sélectionnez Examiner une stratégie dans l'onglet Éditeur visuel, IAM peut restructurer votre stratégie pour optimiser son affichage dans l'éditeur visuel. Pour plus d'informations, consultez Restructuration de stratégie.

  5. Sur la page Vérification, tapez read-write-app-bucket pour le nom de la stratégie. Passez en revue le Récapitulatif de la stratégie pour voir les autorisations accordées par votre stratégie, puis choisissez Créer une stratégie pour enregistrer votre travail.

    La nouvelle stratégie apparaît dans la liste des stratégies gérées.

  6. Dans le panneau de navigation gauche, choisissez Rôles, puis Créer un rôle.

  7. Choisissez le type de rôle Autre compte AWS.

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

    Ce didacticiel 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 assumer le rôle. Laissez ces options décochées. Pour plus d'informations, consultez Utilisation de Multi-Factor Authentication (MFA) dans AWS

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

  10. Sélectionnez la zone située en regard de la stratégie que vous avez créée précédemment.

    Conseil

    Pour Filtre, choisissez Stratégies gérées par le client pour filtrer la liste afin d'inclure uniquement les stratégies que vous avez créées. Cela masque les stratégies créées par AWS et permet de rechercher plus facilement celle que vous recherchez.

    Ensuite, choisissez Next : Tags (Suivant : Balises).

  11. (Facultatif) Ajoutez des métadonnées à l'utilisateur en associant les balises sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez Balisage des entités IAM.

  12. Choisissez Next: Review (Suivant : Vérification) et tapez UpdateApp pour le nom du rôle.

  13. (Facultatif) Dans le champ Description du rôle, saisissez la description du nouveau rôle.

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

    Le rôle UpdateApp est 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 stratégie du groupe Développeurs et Testeurs, vous devez spécifier l'ARN du rôle afin d'accorder ou de refuser des autorisations.

Pour obtenir l'ARN d'UpdateApp

  1. Dans le panneau de navigation de la console IAM, choisissez Rôles.

  2. Dans la liste des rôles, choisissez le rôle UpdateApp.

  3. Dans la section Récapitulatif du volet 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 l'ID de compte AWS réel pour votre compte « production ».

À ce stade, vous avez établi une relation de confiance entre les comptes Production et Développement en créant un rôle dans le compte Production qui identifie le compte Développement en tant que mandataire approuvé. Vous avez également défini ce que les utilisateurs qui basculent vers le rôle UpdateApp peuvent faire.

Ensuite, modifiez les autorisations les groupes.

Étape 2 : Accorder l'accès au rôle

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

Pour modifier le groupe Développeurs afin de les autoriser à basculer vers le rôle UpdateApp

  1. Connectez-vous en tant qu'administrateur dans le compte Développement, et ouvrez la console IAM.

  2. Choisissez Groupes, puis choisissez Developers (Développeurs).

  3. Choisissez l'onglet Autorisations, développez la section Stratégies en ligne, puis choisissez Créer une stratégie de groupe. S'il existe encore aucune stratégie en ligne, le bouton ne s'affiche pas. À la place, choisissez le lien situé à la fin de « To create one, click here. »

  4. Choisissez Stratégie personnalisée, puis cliquez sur le bouton Sélectionner.

  5. Entrez un nom de stratégie comme allow-assume-S3-role-in-production.

  6. Ajoutez la déclaration de stratégie suivante pour autoriser l'action AssumeRole sur le rôle UpdateApp dans le compte Production. Veillez à modifier PRODUCTION-ACCOUNT-ID dans l'élément Resource pour ajouter l'ID du compte AWS réel du compte 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. Tous les développeurs qui essaieront d'accéder au rôle y parviendront.

  7. Choisissez Appliquer la stratégie pour ajouter la stratégie au groupe des développeurs.

Dans la plupart des environnements, la procédure suivante n'est probablement pas nécessaire. En revanche, si vous utilisez les autorisations de l'Utilisateur avancé, certains groupes ont alors peut-être déjà la capacité de changer de rôles. Les procédures suivantes indiquent comment ajouter une autorisation « Deny » au groupe Testeurs pour s'assurer qu'ils ne peuvent pas assumer le rôle. Si cette procédure n'est pas requise 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 lorsqu'il n'y a pas de meilleure option.

Pour modifier le groupe Testeurs afin de lui refuser l'autorisation d'assumer le rôle UpdateApp

  1. Choisissez Groupes, puis choisissez Testers (Testeurs).

  2. Choisissez l'onglet Autorisations, développez la section Stratégies en ligne, puis choisissez Créer une stratégie de groupe.

  3. Choisissez Stratégie personnalisée, puis cliquez sur le bouton Sélectionner.

  4. Entrez un nom de stratégie comme deny-assume-S3-role-in-production.

  5. Ajoutez la déclaration de stratégie suivante pour refuser l'action AssumeRole sur le rôle UpdateApp. Veillez à modifier PRODUCTION-ACCOUNT-ID dans l'élément Resource pour ajouter l'ID du compte AWS réel du compte 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. Tous les testeurs qui essaieront d'accéder au rôle recevront un message d'accès refusé.

  6. Choisissez Appliquer la stratégie pour ajouter la stratégie au groupe des testeurs.

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

Ensuite, vous allez découvrir comment David, un développeur, peut accéder au compartiment productionapp dans le compte Production à l'aide d'AWS Management Console, des commandes de l'AWS CLI et de l'appel d'API AssumeRole.

Étape 3 : Tester l'accès en changeant de rôles

Après avoir terminé les deux premières étapes de ce didacticiel, vous disposez d'un rôle qui accorde l'accès à une ressource du compte Production. Vous disposez également d'un groupe dans le compte Développement dont les utilisateurs sont autorisés à utiliser ce rôle. Le rôle est maintenant prêt à être utilisé. Cette étape indique comment tester le changement pour ce rôle dans AWS Management Console, l'AWS CLI, et l'API AWS.

Important

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

Changer de rôle (Console)

Si David a besoin d'utiliser l'environnement Production dans AWS Management Console, il peut y parvenir à l'aide de Switch Role (Changer de rôle). 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 également 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 d'AWS Management Console fonctionne uniquement avec les comptes ne nécessitant pas de ExternalId. Si vous accordez l'accès à votre compte à un tiers et que vous avez besoin d'un ExternalId dans un élément Condition de votre stratégie d'autorisation, le tiers peut accéder à votre compte uniquement à l'aide de l'API AWS 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énario, consultez Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à un tiers et How to Enable Cross-Account Access to the AWS Management Console dans le Blog sur la sécurité AWS.

David dispose de deux procédures 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) et il a terminé.

  • 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. David doit les entrer manuellement pour changer de rôle. La procédure suivante en est l'illustration.

Pour assumer un rôle

  1. David se connecte à la console AWS avec son utilisateur normal situé dans le groupe Développement.

  2. Il choisit le lien que son administrateur lui a envoyé par e-mail. Cela le dirige vers la page Switch Role (Changer de rôle) avec les informations d'ID de compte ou d'alias et de nom de rôle déjà fournies.

    —ou—

    Il choisit son nom (menu Identité) dans la barre de navigation, puis sélectionne Switch Role (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 sera dirigé vers la page Switch Role (Changer de rôle) de mise en route. Cette page fournit des informations supplémentaires sur la manière dont le changement de rôle peut permettre aux utilisateurs de gérer des ressources entre des comptes AWS. David doit choisir le bouton Switch Role (Changer de rôle) de cette page pour effectuer 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.

    De plus, pour lui permettre de savoir quel rôle (et les autorisations associées) est actuellement actif, il saisit PRODUCTION dans la zone de texte Display Name (Nom d'affichage), sélectionne 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. Une fois qu'il a terminé ses tâches quotidiennes, David peut restaurer ses autorisations d'origine. Pour cela, il choisit le nom complet du rôle PRODUCTION sur la barre de navigation, puis Back to David @ 111111111111 (Revenir à David @ 111111111111).

  6. La prochaine fois que David voudra changer de rôle et choisira le menu Identity 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 à l'aide de l'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 environnement afin que les commandes AWS CLI suivantes fonctionnent à l'aide des autorisations du rôles. 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 assumer un rôle

  1. David ouvre la fenêtre d'invite de commande et confirme que le client de l'AWS CLI 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 de plus amples informations, veuillez consulter Configuration de l'AWS Command Line Interface dans le AWS Command Line Interface Guide de l'utilisateur.

  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 obtenu 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 la sortie :

    { "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 de la sortie.

    • AccessKeyId

    • SecretAccessKey

    • SessionToken

    David a besoin de configurer l'environnement de l'AWS CLI pour utiliser ces paramètres dans les appels suivants. Pour plus d'informations sur les différentes manières de configurer vos informations d'identification, consultez Configuration de l' 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 à environnement de votre session de ligne de commande actuel.

  4. Pour ajouter les valeurs à l'environnement, David coupe et colle la sortie de l'étape précédente dans les commandes suivantes. Notez que vous voulez peut-être couper et coller dans un simple éditeur de texte pour régler les problèmes de retour à la ligne d'adresse dans la sortie du jeton de session. Elle doit être ajoutée sous la forme d'une simple chaîne longue, même si elle s'affiche 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 Mac, vous devez plutôt utiliser la commande « export ». Toutes les autres sections de l'exemple sont valides dans les trois environnements.

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

    A 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 services AWS, consultez la documentation de l'AWS CLI de ce service pour connaître les commandes et la syntaxe requises pour faire référence à ses ressources.

Utilisation d'AssumeRole (API AWS)

Lorsque David a besoin de faire une mise à jour dans le compte Production depuis le code, il réalise un appel AssumeRole pour prendre 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éalise 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 assumer 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, une SecretAccessKey et un délai d'Expiration qui indique à quel moment les informations d'identification expireront et vous devrez 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), consultez Passer à un rôle IAM (API AWS).

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 stratégie de groupe 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.