IAMtutoriel : Déléguer l'accès entre les AWS comptes à l'aide de IAM rôles - AWS Identity and Access Management
ConsidérationsPrérequisCréation d'un rôle dans le compte de destinationAccorder l'accès au rôleTester l'accès en changeant de rôlesRessources supplémentairesRécapitulatif

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.

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

Important

IAMles meilleures pratiques recommandent d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à l' AWS aide d'informations d'identification temporaires plutôt que d'utiliser des IAM utilisateurs dotés d'informations d'identification à long terme. Nous vous recommandons de n'utiliser des IAM utilisateurs que pour des cas d'utilisation spécifiques non pris en charge par les utilisateurs fédérés.

Ce didacticiel vous apprend à utiliser un rôle pour déléguer l'accès à des ressources dans différents domaines Comptes AWS appelés Destination et Origine. Vous partagez 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 IAM utilisateurs 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 duAPI.

Dans ce didacticiel, le compte Destination gère les données d'application auxquelles accèdent différentes applications et équipes. Dans chaque compte, vous stockez les informations de l'application dans des compartiments Amazon S3. Vous gérez IAM les utilisateurs dans le compte Originating, dans lequel vous avez deux rôles IAM d'utilisateur : développeurs et analystes. Les développeurs et les analystes utilisent le compte Originating pour générer des données partagées par plusieurs microservices. Les deux rôles sont autorisés à travailler dans le compte Originating et à accéder aux ressources qui s'y trouvent. De temps à autre, un développeur doit mettre à jour les données partagées dans le compte Destination. Les développeurs stockent ces données dans un compartiment Amazon S3 appeléshared-container.

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

  • Les utilisateurs du compte d'origine (le compte de confiance) sont autorisés à assumer un rôle spécifique dans le compte de destination.

  • Rôle dans le compte de destination (le compte de confiance) autorisé à accéder à un compartiment Amazon S3 spécifique.

  • Le shared-container compartiment du compte Destination.

Les développeurs peuvent utiliser le rôle indiqué dans le AWS Management Console pour accéder au shared-container compartiment dans le compte Destination. Ils peuvent également accéder au bucket en utilisant des API appels authentifiés par des informations d'identification temporaires fournies par le rôle. Les tentatives similaires d'un analyste pour utiliser le rôle échouent.

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

Création d'un rôle dans le compte de destination

Tout d'abord, vous utilisez le AWS Management Console pour établir un lien de confiance entre le compte de destination (numéro d'identification 999999999999) et le compte d'origine (numéro d'identification 111111111111). Vous commencez par créer un IAM rôle nommé UpdateData. Lorsque vous créez le rôle, vous définissez le compte d'origine comme une entité de confiance et vous spécifiez une politique d'autorisation qui permet aux utilisateurs de confiance de mettre à jour le shared-container compartiment.

Accorder l'accès au rôle

Dans cette section, vous modifiez la politique de rôle afin de refuser aux analystes l'accès au UpdateData rôle. Parce que les analystes 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 UpdateData rôle pour mettre à jour le shared-container bucket dans le compte Destination. Vous voyez comment accéder au rôle via la AWS console, le AWS CLI, et leAPI.

Considérations

Avant d'utiliser IAM des rôles pour déléguer l'accès aux ressources Comptes AWS, il est important de prendre en compte les points suivants :

  • Il n'est pas possible de passer à un rôle si vous vous connectez en tant qu' Utilisateur racine d'un compte AWS.

  • IAMles rôles et les politiques basées sur les ressources délèguent l'accès entre les comptes uniquement au sein d'une même 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.

  • Vous pouvez l'utiliser AWS IAM Identity Center pour faciliter l'authentification unique (SSO) pour les comptes externes Comptes AWS (comptes extérieurs au vôtre AWS Organizations) à l'aide du langage de balisage d'assertions de sécurité (SAML). Pour plus de détails, voir Intégrer des données externes Comptes AWS dans AWS IAM Identity Center pour une gestion centralisée des accès avec facturation indépendante à l'aide de la SAML version 2.0

  • Vous pouvez associer des rôles à des AWS ressources telles que des EC2 instances ou des AWS Lambda fonctions Amazon. Pour plus de détails, consultez Création d'un rôle pour déléguer des autorisations à un AWS service.

  • Si vous souhaitez qu'une application joue un rôle dans une autre Compte AWS, vous pouvez utiliser l'hypothèse de rôle AWS SDK pour plusieurs comptes. Pour plus d'informations, reportez-vous à la section Authentification et accès dans le guide de référence AWS SDKs et Tools.

  • 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'en utilisant l'outil AWS API ou en ligne de commande. Le tiers ne peut pas utiliser la console car il doit fournir une valeur pourExternalId. Pour plus d'informations sur ce scénarioAccès à des Comptes AWS sites appartenant à des tiers, consultez la section « Comment activer l'accès entre comptes » AWS Management Console dans le blog sur la AWS sécurité.

Prérequis

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

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

  • Les utilisateurs et les rôles du compte Originating ont été créés et configurés comme suit :

    Intitulé du poste Utilisateur Autorisations
    Developer David Les deux utilisateurs peuvent se connecter et utiliser le compte AWS Management Console In the Originating.
    Analyste Jane

  • Il n'est pas nécessaire de créer des utilisateurs dans le compte Destination.

  • Un compartiment Amazon S3 créé dans le compte Destination. Vous pouvez l'appeler shared-container 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éation d'un rôle dans le compte de destination

Vous pouvez autoriser les utilisateurs de l'un Compte AWS à accéder aux ressources d'un autre Compte AWS. Dans ce didacticiel, nous allons le faire en créant un rôle qui définit qui peut y accéder et quelles autorisations il accorde aux utilisateurs qui passent à ce rôle.

Dans cette étape du didacticiel, vous créez le rôle dans le compte de destination et vous spécifiez le compte d'origine en tant qu'entité de confiance. Vous limitez également les autorisations du rôle à un accès en lecture seule et en écriture au compartiment shared-container. Toute personne ayant autorisation d'utiliser le rôle peut lire et écrire dans le compartiment shared-container.

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

Pour obtenir l' Compte AWS identifiant d'origine

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

  2. Dans la IAM console, choisissez votre nom d'utilisateur dans la barre de navigation en haut à droite. Cela ressemble généralement à ceci : username@account_ID_number_or_alias.

    Dans ce scénario, vous pouvez utiliser l'identifiant de compte 111111111111 pour le compte d'origine. 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 Destination qui peut être utilisé par le compte d'origine

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

  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 shared-container. 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'JSONonglet et copiez le texte du document de JSON politique suivant. Collez ce texte dans la zone de JSONtexte, en remplaçant la ressource ARN (arn:aws:s3:::shared-container) par la vraie ressource pour 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:::shared-container"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::shared-container/*"
    }
  ]
}

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

    Note

    Vous pouvez basculer entre les options Visual et celles de JSONl'éditeur à tout moment. Toutefois, si vous apportez des modifications ou si vous choisissez Suivant dans l'éditeur visuel, vous IAM pouvez restructurer votre politique afin de l'optimiser pour l'éditeur visuel. Pour de plus amples informations, veuillez consulter Restructuration de politique.

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

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

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

  7. Dans le champ ID de compte, saisissez l'ID du compte d'origine.

    Ce didacticiel utilise l'exemple d'ID de compte 111111111111 pour le compte d'origine. Vous devez utiliser un ID de compte valide. Si vous utilisez un identifiant de compte non valide, par exemple111111111111, IAM cela ne vous permet pas de créer le nouveau rôle.

    Pour l'instant, vous n'avez pas besoin d'un identifiant externe, ni d'obliger les utilisateurs à disposer d'une authentification MFA multifactorielle () pour assumer ce rôle. Laissez ces options décochées. Pour plus d’informations, veuillez consulter AWS Authentification multifactorielle dans IAM.

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

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

  10. (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 de balises dansIAM, consultezTags pour les AWS Identity and Access Management ressources.

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

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

    Le rôle UpdateData s'affiche dans la liste des rôles.

Vous devez maintenant obtenir le nom de ressource Amazon (ARN) du rôle, un identifiant unique pour le rôle. Lorsque vous modifiez le rôle du développeur dans le compte d'origine, vous spécifiez le rôle ARN à partir du compte de destination pour accorder ou refuser des autorisations.

Pour obtenir le ARN pour UpdateData

  1. Dans le volet de navigation de la IAM console, sélectionnez Rôles.

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

  3. Dans la section Résumé du volet de détails, copiez la ARN valeur du rôle.

    Le compte de destination possède un ID de compte 999999999999, le rôle est donc. ARN arn:aws:iam::999999999999:role/UpdateData Assurez-vous de fournir le véritable Compte AWS identifiant du compte Destination.

À ce stade, vous avez établi un lien de confiance entre les comptes de destination et d'origine. Pour ce faire, vous avez créé un rôle dans le compte Destination qui identifie le compte d'origine en tant que principal fiable. Vous avez également défini ce que les utilisateurs qui basculent vers le rôle UpdateData peuvent faire.

Modifiez ensuite les autorisations pour le rôle de développeur.

Accorder l'accès au rôle

À ce stade, les analystes et les développeurs disposent d'autorisations leur permettant de gérer les données du compte Originating. Utilisez la procédure requise pour ajouter des autorisations visant à autoriser le changement de rôle.

Pour modifier le rôle des développeurs afin de leur permettre de passer au UpdateData rôle

  1. Connectez-vous en tant qu'administrateur dans le compte Originating et ouvrez la IAM console.

  2. Choisissez Rôles, puis Developers.

  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. Choisissez l'JSONonglet.

  5. Ajoutez la déclaration de politique suivante pour autoriser l'AssumeRoleaction sur le UpdateData rôle dans le compte de destination. Assurez-vous de changer DESTINATION-ACCOUNT-ID dans l'Resourceélément correspondant à l' Compte AWS identifiant réel du compte de destination.

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

    L'Alloweffet permet explicitement au groupe de développeurs d'accéder au UpdateData rôle dans le compte Destination. Tout développeur qui essaie d'accéder à ce rôle y parvient.

  6. Choisissez Review policy (Examiner une politique).

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

  8. Choisissez Create Policy (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. La procédure suivante montre comment ajouter une "Deny" autorisation au groupe d'analystes afin de s'assurer qu'ils ne peuvent pas assumer ce 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 rôle d'analyste afin de refuser l'autorisation d'assumer ce UpdateData rôle

  1. Choisissez Rôles, puis Analystes.

  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. Choisissez l'JSONonglet.

  4. Ajoutez l'instruction de politique suivante pour refuser l'action AssumeRole sur le rôle UpdateData. Assurez-vous de changer DESTINATION-ACCOUNT-ID dans l'Resourceélément correspondant à l' Compte AWS identifiant réel du compte de destination.

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

    L'Denyeffet refuse explicitement au groupe d'analystes l'accès au UpdateData rôle dans le compte Destination. Tout analyste qui tente d'accéder au rôle reçoit un message de refus d'accès.

  5. Choisissez Review policy (Examiner une politique).

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

  7. Choisissez Create Policy (Créer une politique).

Le rôle Développeurs est désormais autorisé à utiliser le UpdateData rôle dans le compte Destination. Le rôle Analystes ne peut pas utiliser le UpdateData rôle.

Ensuite, vous pouvez voir comment David, un développeur, peut accéder au shared-container bucket dans le compte Destination. David peut accéder au bucket depuis le AWS Management Console, le AWS CLI, ou le AWS API.

Tester l'accès en changeant de rôles

Après avoir effectué les deux premières étapes de ce didacticiel, vous disposez d'un rôle qui autorise l'accès à une ressource dans le compte Destination. Vous avez également un rôle dans le compte Originating, les utilisateurs étant autorisés à utiliser ce rôle. Cette étape explique comment tester le passage de AWS Management Console, le AWS CLI, et le à ce rôle à partir du AWS API.

Pour obtenir de l'aide sur les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec IAM des rôles, consultezRésoudre les problèmes liés aux rôles IAM.

Changer de rôle (console)

Si David a besoin de mettre à jour les données du compte Destination dans le 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 shared-container bucket, mais ne peut travailler avec aucune autre ressource dans Destination. Bien que David utilise ce rôle, il ne peut pas non plus utiliser ses privilèges d'utilisateur avancé sur le compte Originating. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois.

IAMfournit deux méthodes que David peut utiliser pour accéder à la page Switch Role :

  • 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 habituel dans le compte Originating.

  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'identification du compte de destination (999999999999) et le nom du rôle (UpdateData).

    David souhaite également surveiller les rôles et les autorisations associées actuellement actifsIAM. Pour suivre ces informations, il saisit Destination 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 UpdateData dispose d'autorisations.

  5. Quand c'est fait, David peut retourner dans ses autorisations d'origine. Pour ce faire, ils choisissent le nom d'affichage du rôle de destination dans la barre de navigation, puis choisissent Back to David @ 111111111111.

  6. La prochaine fois que David souhaite changer de rôle et choisit le menu Identité dans la barre de navigation, il verra l'entrée Destination toujours présente. 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 doit travailler dans l'environnement de destination en ligne de commande, il peut le faire en utilisant le AWS CLI. Il exécute la aws sts assume-role commande et transmet le rôle ARN pour obtenir des informations d'identification de sécurité temporaires pour 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. Lorsque David utilise ce rôle, il ne peut pas utiliser ses privilèges d'utilisateur avancé dans le compte Originating, car un seul ensemble d'autorisations peut être en vigueur à 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 UpdateData rôle dans le compte Destination. Il a reçu le rôle ARN de l'administrateur qui l'a créé. 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/UpdateData" --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é.

    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 Basculer vers un IAM rôle (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 UpdateData.

    Important

    Vous pouvez enregistrer vos paramètres de configuration utilisés fréquemment et vos informations d'identification dans les fichiers qui sont gérés par l' AWS CLI. Pour plus d'informations, consultez la section Utilisation des fichiers de configuration et d'identification existants dans le Guide de AWS Command Line Interface l'utilisateur.

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

    aws s3 ls s3://shared-container

    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.

En utilisant AssumeRole (AWS API)

Lorsque David doit mettre à jour le compte Destination à partir du code, il passe un AssumeRole appel pour assumer le UpdateData rôle. L'appel renvoie des informations d'identification temporaires qu'il peut utiliser pour accéder au shared-container compartiment dans le compte Destination. Avec ces informations d'identification, David peut API passer des appels pour mettre à jour le shared-container bucket. Cependant, il ne peut pas passer d'APIappels pour accéder à d'autres ressources du compte Destination, même s'il possède des autorisations d'utilisateur avancé dans le compte Originating.

Pour endosser un rôle

  1. David appelle AssumeRole dans le cadre d'une application. Ils doivent spécifier le UpdateData ARN :arn:aws:iam::999999999999:role/UpdateData.

    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. Lorsque vous configurez le chaînage des rôles avec le AWS SDK, de nombreux fournisseurs d'informations d'identification actualisent automatiquement les informations d'identification avant leur expiration.

  2. Grâce aux informations d'identification de sécurité temporaires, David réalise un appel s3:PutObject pour mettre à jour le compartiment shared-container. Ils transmettraient les informations d'identification à l'APIappel en tant que AuthParams paramètre. Étant donné que les informations d'identification du rôle temporaire n'ont qu'un accès en lecture et en écriture au shared-container compartiment, toute autre action dans le compte Destination est refusée.

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

Les ressources suivantes peuvent vous aider à en savoir plus sur les sujets abordés dans ce didacticiel :

  • Pour plus d'informations sur IAM les utilisateurs, consultezIAMIdentités .

  • Pour plus d'informations sur les compartiments Amazon S3, veuillez consulter créer un compartiment dans le Amazon Simple Storage Service User Guide (guide de l'utilisateur du service de stockage simple de Amazon).

  • Pour savoir si les responsables de comptes situés en dehors de votre zone de confiance (organisation de confiance ou compte) ont accès à vos rôles, voir Qu'est-ce qu'IAMAccess Analyzer ? .

Récapitulatif

Vous avez terminé le didacticiel sur l'APIaccès entre 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. Vous avez ensuite modifié une politique de rôle pour contrôler les IAM utilisateurs autorisés à accéder au rôle. Par conséquent, les développeurs du compte Originary peuvent mettre à jour le shared-container bucket dans le compte Destination en utilisant des informations d'identification temporaires.