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. # Rôles IAM Un *rôle* IAM est une identité IAM que vous pouvez créer dans votre compte et qui dispose d’autorisations spécifiques. Un rôle IAM est similaire à un utilisateur IAM, car il s'agit d'une identité AWS avec des politiques d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle. Vous pouvez utiliser des rôles pour déléguer l'accès à des utilisateurs, à des applications ou à des services qui n'ont normalement pas accès à vos AWS ressources. Par exemple, vous pouvez autoriser les utilisateurs de votre AWS compte à accéder à des ressources dont ils ne disposent pas habituellement, ou autoriser les utilisateurs d'un compte à Compte AWS accéder aux ressources d'un autre compte. Vous pouvez également autoriser une application mobile à utiliser AWS des ressources, mais ne pas intégrer de AWS clés dans l'application (où elles peuvent être difficiles à mettre à jour et où les utilisateurs peuvent éventuellement les extraire). Parfois, vous souhaitez donner AWS accès à des utilisateurs dont l'identité est déjà définie à l'extérieur AWS, par exemple dans le répertoire de votre entreprise. Ou, vous pouvez accorder l'accès à votre compte à des tiers afin de leur permettre de réaliser un audit de vos ressources. Pour ces scénarios, vous pouvez déléguer l'accès aux AWS ressources à l'aide d'un *rôle IAM*. Cette section présente les rôles et les différentes façons de les utiliser. Elle explique également quand et comment choisir les diverses approches et comment créer, gérer, prendre (endosser) et supprimer des rôles. **Note** Lorsque vous créez votre Compte AWS, aucun rôle n'est créé par défaut. Au fur et à mesure que vous ajoutez des services à votre compte, ils peuvent ajouter des rôles liés à un service pour répondre à leurs cas d'utilisation. Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service. Avant de pouvoir supprimer les rôles liés à un service, vous devez d'abord supprimer les ressources qui leur sont associées. Vos ressources sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources. Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service. **Topics** + [Quand créer un utilisateur IAM (au lieu d'un rôle)](#id_which-to-choose) + [Termes et concepts relatifs aux rôles](#id_roles_terms-and-concepts) + [Ressources supplémentaires](#id_roles_additional-resources) + [Le problème de l'adjoint confus](confused-deputy.md) + [Scénarios courants de rôles IAM](id_roles_common-scenarios.md) + [Création d’un rôle IAM](id_roles_create.md) + [Gestion des rôles IAM](id_roles_manage.md) + [Méthodes pour assumer un rôle](id_roles_manage-assume.md) ## Quand créer un utilisateur IAM (au lieu d'un rôle) Nous vous recommandons de n’utiliser les utilisateurs IAM que pour les cas d’utilisation non pris en charge par la fédération d’identité. Voici certaines des fonctionnalités les plus utilisées : + **Charges de travail qui ne peuvent pas utiliser de rôles IAM** — Vous pouvez exécuter une charge de travail à partir d'un emplacement qui a besoin d'accéder à AWS. Dans certains cas, vous ne pouvez pas utiliser les rôles IAM pour fournir des informations d'identification temporaires, par exemple pour les WordPress plug-ins. Dans ces situations, utilisez les clés d'accès à long terme de l'utilisateur IAM pour cette charge de travail afin de vous authentifier auprès de AWS. + ** AWS Clients tiers** : si vous utilisez des outils qui ne prennent pas en charge l'accès avec IAM Identity Center, tels que des AWS clients tiers ou des fournisseurs qui ne sont pas hébergés sur le site AWS, utilisez les clés d'accès à long terme des utilisateurs IAM. + **AWS CodeCommit accès** — Si vous avez l'habitude de CodeCommit stocker votre code, vous pouvez utiliser un utilisateur IAM doté de clés SSH ou d'informations d'identification spécifiques au service pour vous authentifier CodeCommit auprès de vos référentiels. Nous vous recommandons de procéder ainsi en plus de vous servir d'un utilisateur dans IAM Identity Center pour une authentification ordinaire. Les utilisateurs d'IAM Identity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Pour permettre aux utilisateurs d'accéder à vos CodeCommit référentiels sans configurer les utilisateurs IAM, vous pouvez configurer l'**git-remote-codecommit**utilitaire. Pour plus d'informations sur IAM et CodeCommit, consultez[Informations d'identification IAM pour CodeCommit : informations d'identification Git, clés SSH et AWS clés d'accès](id_credentials_ssh-keys.md). Pour plus d'informations sur la configuration de l'**git-remote-codecommit**utilitaire, consultez la section [Connexion aux AWS CodeCommit référentiels avec des informations d'identification rotatives](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials) dans le *Guide de AWS CodeCommit l'utilisateur*. + **Amazon Keyspaces (for Apache Cassandra) access** (Accès Amazon Keyspaces (pour Apache Cassandra)) : dans une situation où vous n'êtes pas en mesure de vous servir des utilisateurs dans IAM Identity Center, par exemple à des fins de test de compatibilité avec Cassandra, vous pouvez utiliser un utilisateur IAM avec des informations d'identification spécifiques au service pour vous authentifier auprès d'Amazon Keyspaces. Les utilisateurs d'IAM Identity Center sont les membres de votre personnel qui ont besoin d'accéder à vos applications cloud Comptes AWS ou à celles de celles-ci. Vous pouvez également vous connecter à Amazon Keyspaces à l'aide d'informations d'identification temporaires. Pour de plus d'informations, veuillez consulter [Utilisation d'informations d'identification temporaires pour se connecter à Amazon Keyspaces à l'aide d'un rôle IAM et du plugin Sigv4](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM) dans le *Guide du développeur Amazon Keyspaces (pour Apache Cassandra)*. + **Accès d’urgence** : dans une situation où vous n’avez pas accès à votre fournisseur d’identité et où vous devez prendre des mesures sur votre Compte AWS. La création d'utilisateurs IAM bénéficiant d'un accès d'urgence peut faire partie de votre plan de résilience. Nous vous recommandons de veiller à ce que les informations d'identification des utilisateurs d'urgence soient étroitement contrôlées et sécurisées à l'aide de l'authentification multifactorielle (MFA). ## Termes et concepts relatifs aux rôles Voici quelques termes de base pour vous aider à vous familiariser avec les rôles. ****Rôle**** Une identité IAM que vous pouvez créer dans votre compte et qui dispose d'autorisations spécifiques. Un rôle IAM présente des similitudes avec un utilisateur IAM. Les rôles et les utilisateurs sont tous deux des identités AWS avec des politiques d'autorisations qui déterminent ce que l'identité peut ou ne peut pas faire dans AWS. En revanche, au lieu d'être associé de manière unique à une personne, un rôle est conçu pour être endossé par tout utilisateur qui en a besoin. En outre, un rôle ne dispose pas d’informations d’identification standard à long terme comme un mot de passe ou des clés d’accès associées. Au lieu de cela, lorsque vous adoptez un rôle, il vous fournit des informations d’identification de sécurité temporaires pour votre session de rôle. Les rôles peuvent être endossés par : + Un utilisateur IAM dans le même domaine Compte AWS ou dans un autre Compte AWS + Rôles IAM dans le même compte + Principes de service, à utiliser avec des AWS services et des fonctionnalités tels que : + Services qui vous permettent d'exécuter du code sur des services informatiques, tels qu'Amazon EC2 ou AWS Lambda + Fonctionnalités qui exécutent des actions sur vos ressources en votre nom, comme la réplication d’objets Amazon S3 + Services fournissant des informations d'identification de sécurité temporaires à vos applications exécutées en dehors de AWS, telles que IAM Roles Anywhere ou Amazon ECS Anywhere + Un utilisateur externe authentifié par un service de fournisseur d’identité (IdP) externe, compatible avec SAML 2.0 ou OpenID Connect. ****AWS rôle de service**** Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*. ****AWS rôle lié au service**** Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service. Si vous utilisez déjà un service lorsqu'il commence à prendre en charge des rôles liés à un service, vous pouvez recevoir un e-mail vous informant de l'existence d'un nouveau rôle sur votre compte. Dans ce cas, le service crée automatiquement le rôle lié à un service sur votre compte. Aucune action de votre part n'est requise pour prendre ce rôle en charge et il est préférable de ne pas le supprimer manuellement. Pour plus d’informations, veuillez consulter [Un nouveau rôle est apparu dans mon AWS compte](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared). Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service. Pour de plus amples informations, veuillez consulter [Créer un rôle lié à un service](id_roles_create-service-linked-role.md). ****Création de chaînes de rôles**** La création de chaînes de rôles se produit lorsque vous utilisez un rôle pour assumer un second rôle. Vous pouvez effectuer un chaînage des rôles via le AWS Management Console en changeant de rôle AWS CLI, de ou d'API. Par exemple, `RoleA` dispose de l'autorisation d'assumer `RoleB`. Vous pouvez autoriser User1 à assumer `RoleA` en utilisant ses informations d'identification utilisateur à long terme dans le cadre du fonctionnement de l' AssumeRoleAPI. Cette opération renvoie les informations d'identification à court terme de `RoleA`. Avec le chaînage de rôles, vous pouvez utiliser les informations d'identification à court terme de `RoleA` pour permettre à User1 d'assumer `RoleB`. Lorsque vous endossez un rôle, vous pouvez passer une balise de session et la définir comme transitive. Les balises de session transitives sont transmises à toutes les sessions suivantes d'une chaîne de rôles. Pour en savoir plus sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md). Le chaînage des rôles limite votre AWS Management Console session de rôle AWS CLI ou celle de l' AWS API à une heure maximum. Elle s’applique quelle que soit la durée maximale de session configurée pour les rôles individuels. Lorsque vous utilisez l'opération [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)d'API pour assumer un rôle, vous pouvez spécifier la durée de votre session de rôle à l'aide du `DurationSeconds` paramètre. Vous pouvez spécifier une valeur de paramètre jusqu'à 43200 secondes (12 heures), en fonction du paramètre de [durée de session maximale](id_roles_update-role-settings.md#id_roles_update-session-duration) de votre rôle. Toutefois, si vous endossez un rôle à l'aide de la création de chaînes de rôles et que vous définissez une valeur de paramètre `DurationSeconds` supérieure à une heure, l'opération échoue. Pour plus d'informations sur le passage à un rôle dans le AWS Management Console, consultez[Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md). ****Délégation**** L'octroi à une personne d'autorisations lui permettant d'accéder aux ressources que vous contrôlez. La délégation implique la mise en place d'une confiance entre deux comptes. Le premier est le compte propriétaire de la ressource (le compte de confiance). Le second est le compte qui contient les utilisateurs qui doivent accéder à la ressource (le compte approuvé). Les comptes d'approbation et approuvés peuvent être : + Un même compte. + Comptes distincts se trouvant tous deux sous le contrôle de votre organisation. + Deux comptes appartenant à des organisations différentes. Pour déléguer l’autorisation d’accès à une ressource, vous [créez un rôle IAM](id_roles_create_for-user.md) dans le compte d’approbation auquel sont attachées deux politiques. La *politique d'autorisation* accorde à l'utilisateur du rôle les autorisations nécessaires pour exécuter les tâches prévues sur la ressource. La *politique d'approbation* détermine les membres du compte autorisés à endosser le rôle. Lorsque vous créez une politique d'approbation, vous ne pouvez pas spécifier de caractère générique (\$1) comme ARN dans l'élément de principal. La politique d'approbation est attachée au rôle dans le compte d'approbation, et représente la moitié des autorisations. L'autre moitié est une politique d'autorisation attachée à l'utilisateur dans le compte approuvé qui [autorise cet utilisateur à prendre ou endosser le rôle](id_roles_use_permissions-to-switch.md). Un utilisateur qui endosse un rôle temporairement abandonne ses propres autorisations, de manière à adopter celles du rôle. Lorsque l'utilisateur quitte le rôle ou cesse de l'utiliser, ses autorisations d'origine sont restaurées. Un paramètre supplémentaire appelé [ID externe](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) permet de sécuriser l'utilisation de rôles entre des comptes qui ne sont pas contrôlés par la même organisation. ****Politique d'approbation**** [Document de politique JSON](reference_policies_grammar.md) dans lequel vous définissez les principaux en lesquels vous avez *confiance* pour endosser le rôle. Une politique d'approbation de rôle est une [politique basée sur les ressources](access_policies.md#policies_resource-based) requise qui est attachée à un rôle dans IAM. Les [principaux](reference_policies_elements_principal.md) que vous pouvez spécifier dans la politique d'approbation comprennent les utilisateurs, les rôles, les comptes et les services. Pour plus d’informations, consultez [Comment utiliser les politiques de confiance avec les rôles IAM](https://aws.amazon.com/blogs//security/how-to-use-trust-policies-with-iam-roles/) dans le *Blog de sécuritéAWS *. ****Rôle pour l'accès entre comptes**** Un rôle qui octroie l'accès aux ressources d'un compte à un principal approuvé d'un autre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Cependant, certains AWS services vous permettent d'associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). C'est ce que l'on appelle des politiques basées sur les ressources, et vous pouvez les utiliser pour accorder aux principaux un autre Compte AWS accès à la ressource. Ces ressources incluent notamment les compartiments Amazon Simple Storage Service (S3), les coffres Amazon Glacier, les rubriques Amazon Simple Notification Service (SNS) et les files d’attente Amazon Simple Queue Service (SQS). Pour connaître les services qui prennent en charge les politiques basées sur les ressources, veuillez consulter [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour plus d'informations sur les politiques basées sur les ressources, consultez [Accès intercompte aux ressources dans IAM](access_policies-cross-account-resource-access.md). ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à en savoir plus sur la terminologie IAM relative aux rôles IAM. + Les **principaux sont des** entités AWS qui peuvent effectuer des actions et accéder aux ressources. Un principal peut être un Utilisateur racine d'un compte AWS utilisateur IAM ou un rôle. Un principal qui représente l'identité d'un AWS service est un [principal de service](reference_policies_elements_principal.md#principal-services). Utilisez l’élément Principal dans les politiques d’approbation des rôles pour définir les principaux auxquels vous faites confiance pour assumer le rôle. Pour plus d’informations et des exemples de principaux que vous pouvez autoriser à assumer un rôle, consultez [AWS Éléments de politique JSON : Principal](reference_policies_elements_principal.md). + **La fédération d'identité** crée une relation de confiance entre un fournisseur d'identité externe et AWS. Vous pouvez utiliser votre fournisseur OpenID Connect (OIDC) ou Security Assertion Markup Language (SAML) 2.0 pour gérer les utilisateurs autorisés à accéder aux ressources AWS . Lorsque vous utilisez OIDC et SAML 2.0 pour configurer une relation de confiance entre ces fournisseurs d'identité externes AWS , un rôle IAM est attribué à l'utilisateur. L'utilisateur reçoit également des informations d'identification temporaires qui lui permettent d'accéder à vos ressources AWS . Pour plus d’informations sur les principaux fédérés, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md). + Les **principes fédérés sont des** identités existantes provenant de l'annuaire Directory Service des utilisateurs de votre entreprise ou d'un fournisseur OIDC. AWS attribue un rôle à un principal fédéré lorsque l'accès est demandé par le biais d'un fournisseur d'[identité](id_roles_providers.md). Pour plus d’informations sur les principaux fédérés SAML ou OIDC, consultez [sessions d’utilisateur fédéré et rôle](introduction_access-management.md#intro-access-roles). + Les **politiques d’autorisation** sont des politiques basées sur l’identité qui définissent les actions et les ressources que le rôle peut utiliser. Le document est écrit conformément aux règles du langage de politique IAM. Pour de plus amples informations, veuillez consulter [Référence de politique JSON IAM](reference_policies.md). + Les **limites des autorisations** sont une fonctionnalité avancée dans laquelle vous utilisez des politiques pour limiter les autorisations maximales qu’une politique basée sur l’identité peut accorder à un rôle. Vous ne pouvez pas appliquer une limite d'autorisations à un rôle lié à un service. Pour de plus amples informations, veuillez consulter [Limites d'autorisations pour les entités IAM](access_policies_boundaries.md). # Le problème de l'adjoint confus Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. Pour éviter cela, AWS fournit des outils qui vous aident à protéger votre compte si vous fournissez à des tiers (*comptes croisés*) ou à d'autres AWS services (appelés *interservices) un* accès aux ressources de votre compte. Il peut arriver que vous deviez accorder à un tiers l'accès à vos AWS ressources (accès délégué). Par exemple, vous décidez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres Comptes AWS pour d'autres clients. Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre compte Compte AWS et le compte Example Corp. Un aspect important de ce scénario est l’*ID externe*, un identifiant facultatif que vous pouvez utiliser dans une politique d’approbation des rôles IAM afin de désigner l’utilisateur autorisé à endosser le rôle. La fonction principale de l’ID externe est de traiter et de prévenir le problème du délégué confus. Certains AWS services (services d'appel) utilisent leur principal de AWS service pour accéder aux AWS ressources d'autres AWS services (appelés services). Dans certaines de ces interactions de service, vous pouvez configurer les services d'appel pour communiquer avec les ressources d'un service appelé dans un autre pays Compte AWS. C'est le cas, par exemple, AWS CloudTrail de la configuration pour écrire dans un compartiment Amazon S3 central situé dans un autre compartiment Compte AWS. Le service d'appel CloudTrail est autorisé à accéder à votre compartiment S3 conformément à la politique du compartiment S3 en ajoutant une instruction d'autorisation pour`cloudtrail.amazonaws.com`. Lorsqu'un principal de AWS service d'un service appelant accède à une ressource à partir d'un service appelé, la politique de ressources du service appelé autorise uniquement le principal de AWS service, et non l'acteur qui a configuré le service d'appel. Par exemple, un compartiment S3 qui fait confiance au principal du CloudTrail service sans aucune condition peut recevoir CloudTrail des journaux de la Comptes AWS part d'un administrateur de confiance configuré, mais également CloudTrail des journaux d'un acteur non autorisé Compte AWS, s'il connaît le nom du compartiment S3. Le problème des adjoints confus se pose lorsqu'un acteur utilise la confiance du directeur de AWS service d'un service pour accéder à des ressources auxquelles il n'est pas censé avoir accès. ## Prévention du problème de l'adjoint confus entre comptes Le diagramme suivant illustre le problème de l'adjoint confus entre comptes. ![\[Description d'un problème de député confus.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/confuseddeputyproblem2.png) Ce scénario suppose que : + **AWS 1** est votre Compte AWS. + **AWS 1 : ExampleRole** est un rôle dans votre compte. La politique d'approbation du rôle approuve Example Corp en désignant le compte AWS d'Example Corp comme celui qui peut endosser le rôle. Voici ce qui se produit : 1. Lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN **AWS 1 : ExampleRole** à Example Corp. 1. Example Corp utilise cet ARN de rôle pour obtenir des informations d'identification de sécurité temporaires afin d'accéder aux ressources de votre Compte AWS. Ainsi, vous approuvez Example Corp en tant que « député » autorisé à agir pour votre compte. 1. Un autre AWS client commence également à utiliser le service d'Example Corp, et ce client fournit également l'ARN **AWS 1 : ExampleRole** for Example Corp à utiliser. On peut supposer que l'autre client a appris ou deviné le **AWS 1 : ExampleRole**, ce qui n'est pas un secret. 1. Lorsque l'autre client demande à Example Corp d'accéder aux AWS ressources (qu'il prétend être) de son compte, Example Corp utilise **AWS 1 : ExampleRole** pour accéder aux ressources de votre compte. C'est ainsi que l'autre client peut obtenir un accès non autorisé à vos ressources. Du fait que cet autre client a été en mesure de tromper Example Corp pour agir involontairement sur vos ressources, Example Corp est à présent un « député confus ». Exemple Corp peut résoudre le problème de l'adjoint confus en exigeant que vous incluiez la vérification de la condition `ExternalId` dans la politique d'approbation du rôle. Exemple Corp génère une valeur `ExternalId` unique pour chaque client et utilise cette valeur dans sa demande de prise en charge du rôle. La valeur `ExternalId` doit être unique parmi les clients d'Example Corp et contrôlée par Example Corp, et non par ses clients. C'est pourquoi vous l'obtenez d'Example Corp et que vous ne créez pas le vôtre. Cela évite à Example Corp d'être un adjoint confus et d'accorder l'accès aux AWS ressources d'un autre compte. Dans notre scénario, imaginez que l'identifiant unique d'Example Corp pour vous soit 12345, et que son identifiant pour l'autre client soit 67890. Ces identifiants sont simplifiés pour ce scénario. En général, ces identifiants sont GUIDs. Supposons que ces identifiants sont uniques pour chaque client d'Example Corp, ils constituent des valeurs sensibles à utiliser pour l'ID externe. Example Corp vous attribue la valeur d'ID externe 12345. Vous devez ensuite ajouter un élément `Condition` à la politique d’approbation du rôle qui nécessite que la valeur de [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts) soit 12345, comme suit : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "Example Corp's AWS Account ID" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "12345" } } } } ``` ------ L'élément Condition de cette politique permet à Example Corp d'assumer le rôle uniquement lorsque l'appel d' AssumeRole API inclut la valeur d'ID externe 12345. Example Corp s'assure que chaque fois qu'elle assume un rôle au nom d'un client, elle inclut toujours la valeur d'identifiant externe de ce client dans l' AssumeRole appel. Même si un autre client fournit votre ARN à Example Corp, il ne peut pas contrôler l'ID externe qu'Example Corp inclut dans sa demande AWS. Cela permet d'éviter qu'un client non autorisé obtienne l'accès à vos ressources. Le schéma suivant illustre ce processus. ![\[Procédure pour résoudre un problème de député confus.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/confuseddeputymitigation2.png) 1. Comme précédemment, lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN **AWS 1 : ExampleRole à Example** Corp. 1. Lorsque Example Corp utilise ce rôle ARN pour assumer le rôle **AWS 1 : ExampleRole**, Example Corp inclut votre ID externe (12345) dans l'appel d' AssumeRole API. L'ID externe correspond à la politique de confiance du rôle. Ainsi, l'appel d' AssumeRole API aboutit et Example Corp obtient des informations de sécurité temporaires pour accéder aux ressources de votre. Compte AWS 1. Un autre AWS client commence également à utiliser le service d'Example Corp et, comme auparavant, ce client fournit également l'ARN **AWS 1 : ExampleRole** for Example Corp à utiliser. 1. Mais cette fois, lorsque Example Corp tente d'assumer le rôle **AWS 1 : ExampleRole**, elle fournit l'ID externe associé à l'autre client (67890). L'autre client est dans l'impossibilité de changer cela. Example Corp procède ainsi, car la demande pour utiliser le rôle provient de l'autre client, 67890 indique donc les circonstances dans lesquelles Example Corp agit. Comme vous avez ajouté une condition avec votre propre ID externe (12345) à la politique de confiance de **AWS 1 : ExampleRole**, l'appel d' AssumeRole API échoue. L'autre client se voit refuser l'autorisation d'accéder aux ressources de votre compte (indiqué par la croix « X » rouge dans le diagramme). L'ID externe empêche tout autre client de forcer Example Corp de manière trompeuse à accéder involontairement à vos ressources. ## Prévention du problème de l’adjoint confus entre services Le schéma suivant illustre le problème de confusion entre les services adjoints en utilisant l' CloudTrail exemple d'interaction avec Amazon S3, dans lequel un acteur non autorisé écrit CloudTrail des journaux dans un compartiment Amazon S3 auquel il n'est pas autorisé à accéder. ![\[Un acteur non autorisé est autorisé à accéder à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/cross-service-confused-deputy1.png) Pour éviter qu'un acteur non autorisé n'utilise la confiance d'un AWS mandant pour accéder à vos ressources, les responsables de AWS service incluent des informations sur la AWS ressource et AWS l'organisation pour laquelle ils agissent pour le compte. Compte AWS Ces informations sont disponibles sous forme de valeurs de clé de condition globale qui peuvent être utilisées dans une politique de ressources ou dans une politique de contrôle des ressources pour les demandes effectuées par les principaux AWS fournisseurs de service. Nous vous recommandons d'utiliser [aws:SourceArn](reference_policies_condition-keys.md#condition-keys-sourcearn)[aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount),[aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid), ou [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths) dans vos politiques de ressources chaque fois qu'un directeur de AWS service est autorisé à accéder à l'une de vos ressources. Ces clés de condition vous permettent de tester dans vos politiques de ressources, ou vos politiques de contrôle des ressources, que les responsables de AWS service accédant à vos ressources le font au nom des AWS ressources Comptes AWS, ou comme AWS Organizations vous vous y attendez. + `aws:SourceArn`À utiliser pour autoriser un directeur de AWS service à accéder à vos ressources au nom d'une ressource spécifique, telle qu'un AWS CloudTrail sentier ou une AppStream flotte spécifique. + `aws:SourceAccount`À utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'une personne en particulier Compte AWS. + `aws:SourceOrgID`À utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'un particulier AWS Organizations. + `aws:SourceOrgPaths`À utiliser pour autoriser le principal de AWS service à accéder à vos ressources au nom d'un AWS Organizations chemin spécifique. Le schéma suivant illustre le scénario d'un adjoint confus entre services lorsqu'une ressource est configurée avec la clé de contexte de condition `aws:SourceAccount` globale et qu'un acteur non autorisé d'un autre compte tente d'accéder à AWS des ressources auxquelles il n'est pas censé avoir accès. ![\[Un acteur non autorisé se voit refuser l'accès à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/cross-service-confused-deputy2.png) L’utilisation des clés de condition globales `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID` et `aws:SourceOrgPaths` dans une politique vous aide à vous assurer que les principaux de service accèdent à vos ressources en votre nom. Nous recommandons d'utiliser ces clés de condition chaque fois que l'accès à l'une de vos ressources est accordé à un principal AWS de service. **Note** Certaines Service AWS interactions comportent des contrôles supplémentaires qui permettent de se protéger contre les problèmes liés à la confusion entre les services qui mettent à l'épreuve l'accès des utilisateurs à une ressource. Par exemple, lorsqu'une attribution de clé KMS est accordée à un Service AWS, AWS KMS utilise le contexte de chiffrement associé à la ressource et l'attribution de clé pour éviter les problèmes de confusion entre les services auxiliaires. Veuillez consulter la documentation des services que vous utilisez pour plus d’informations sur les mécanismes spécifiques à chaque service qui peuvent aider à éviter les risques d’adjoint confus entre les services, et pour savoir si `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID`, et `aws:SourceOrgPaths` sont pris en charge. ## Protection des adjoints confus entre les services avec des politiques basées sur les ressources L'exemple de politique suivant accorde au principal de service l'`cloudtrail.amazonaws.com`accès au compartiment Amazon S3, arn:aws:s3 : ::amzn-s3-demo-bucket1, uniquement lorsque le principal de service agit pour le compte de 111122223333. Compte AWS ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CloudTrailAclCheck", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } }, { "Sid": "AWSCloudTrailWrite", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } } ] } ``` ------ Cet exemple de politique de compartiment accorde au principal du service l'`appstream.amazonaws.com`accès au script PowerShell examplefile.psh sur le site s3://amzn-s3-demo-bucket2 uniquement lorsqu'il agit pour le compte de la AppStream flotte Amazon spécifiée, en spécifiant l'ARN de la flotte avec. `aws:SourceArn` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "appstream.amazonaws.com" ] }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName" } } } ] } ``` ------ ## Protection des adjoints confus entre les services avec des politiques de contrôle des ressources Vous pouvez utiliser les politiques de contrôle des ressources (RCP) pour appliquer des contrôles adjoints interservices confus aux ressources prises en charge. Services AWS RCPs vous permettent d'appliquer de manière centralisée des contrôles adjoints interservices confus sur vos ressources. Vous pouvez utiliser des clés de condition telles que `aws:SourceOrgId` `aws:SourceOrgPaths` celles RCPs associées à vos AWS Organizations unités organisationnelles (UO) ou Comptes AWS au sein de votre organisation sans ajouter d'instructions à des politiques spécifiques basées sur les ressources. Pour plus d'informations sur les services pris en charge RCPs et les services pris en charge, consultez la section [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*. Dans l'exemple suivant, le RCP refuse aux principaux de AWS service l'accès aux compartiments Amazon S3 de vos comptes membres lorsque la valeur n'`aws:SourceOrgID`est pas égale à o-. ExampleOrg Une autorisation correspondante doit être présente dans la politique basée sur les ressources du compartiment S3 pour autoriser Service AWS les principaux ayant une `SourceOrgID` valeur égale à o-. ExampleOrg Cette politique n’applique le contrôle que sur les demandes des principaux de service (`"Bool": {"aws:PrincipalIsAWSService": "true"}`) qui ont la clé `aws:SourceAccount` présente (`"Null": {"aws:SourceAccount": "false"}`), de sorte que les intégrations de services qui ne nécessitent pas l’utilisation de la clé de condition et les appels de vos principaux ne sont pas impactés. Si la clé de condition `aws:SourceAccount` est présente dans le contexte de la demande, la condition Null sera évaluée comme vraie, ce qui entraînera l’application de `aws:SourceOrgID`. Nous utilisons `aws:SourceAccount` au lieu de `aws:SourceOrgID` dans l’opérateur de condition Null afin que le contrôle s’applique toujours si la demande provient d’un compte qui n’appartient pas à une organisation. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "RCPEnforceConfusedDeputyProtectionForS3", "Effect": "Deny", "Principal": "*", "Action": [ "s3:*" ], "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:SourceOrgID": "o-ExampleOrg" }, "Null": { "aws:SourceAccount": "false" }, "Bool": { "aws:PrincipalIsAWSService": "true" } } } ] } ``` ------ # Scénarios courants de rôles IAM Comme pour la plupart des AWS fonctionnalités, vous pouvez généralement utiliser un rôle de deux manières : de manière interactive dans la console IAM ou par programmation avec les outils pour Windows PowerShell ou l' AWS CLI API. + Les utilisateurs IAM de votre compte qui utilisent la console IAM peuvent *basculer* vers un rôle leur permettant d'utiliser temporairement les autorisation du rôle dans la console. Les utilisateurs abandonnent leurs autorisations d'origine et acceptent les autorisations attribuées au rôle. Lorsque les utilisateurs quittent le rôle, leurs autorisations d'origine sont restaurées. + Une application ou un service proposé par AWS (comme Amazon EC2) peut *assumer* un rôle en demandant des informations d'identification de sécurité temporaires pour un rôle auquel envoyer des demandes programmatiques. AWS Vous utilisez ce rôle ainsi pour éviter de partager ou de conserver des informations d'identification de sécurité à long terme (par exemple, en créant un utilisateur IAM) pour chaque entité qui doit accéder à une ressource. **Note** Ce manuel utilise les phrases *passer à un rôle* et *endosser un rôle* de manière interchangeable. La forme d'utilisation des rôles la plus simple consiste à accorder à vos utilisateurs IAM l'autorisation de basculer vers des rôles que vous créez au sein de votre propre entreprise ou d'une autre Compte AWS. Ils peuvent changer de rôles facilement à l'aide de la console IAM pour utiliser des autorisations dont vous ne souhaitez pas qu'ils disposent d'ordinaire et il leur suffit de quitter le rôle pour renoncer à ces autorisations. Cela permet d'empêcher un accès *accidentel* à des ressources sensibles ou leur modification involontaire. Pour utiliser les rôles de manière plus complexe, comme accorder l'accès à des applications et des services, ou à des utilisateurs externes fédérés, vous pouvez appeler l'API `AssumeRole`. Cet appel d'API renvoie un ensemble d'informations d'identification temporaires que l'application peut utiliser dans les appels d'API suivants. Les tentatives d'actions avec les informations d'identification temporaires ne disposent que des autorisations accordées par le rôle associé. Une application n'a pas besoin de « quitter » le rôle de la même manière qu'un utilisateur dans la console. L'application arrête simplement d'utiliser les informations d'identification temporaires et reprend ses appels avec les informations d'identification d'origine. Les utilisateurs fédérés se connectent à l'aide des informations d'identification d'un fournisseur d'identité (IdP). AWS fournit ensuite des informations d'identification temporaires à l'IdP de confiance à transmettre à l'utilisateur pour les inclure dans les demandes de AWS ressources ultérieures. Ces informations d'identification fournissent des autorisations accordées au rôle attribué. Cette section présente les scénarios suivants : + [Donnez accès à un utilisateur IAM dans un compte Compte AWS que vous possédez pour accéder aux ressources d'un autre compte que vous possédez](id_roles_common-scenarios_aws-accounts.md) + [Fournir un accès aux charges de travail qui n'appartiennent pas à AWS](id_roles_common-scenarios_non-aws.md) + [Octroyer un accès aux utilisateurs IAM dans des Comptes AWS appartenant à des tierces parties](id_roles_common-scenarios_third-party.md) + [Fournir un accès aux services offerts par AWS deux AWS ressources](id_roles_common-scenarios_services.md) + [Octroi de l'accès à des utilisateurs authentifiés en externe (fédération d'identité)](id_roles_common-scenarios_federated-users.md) # Accès pour un utilisateur IAM à un autre utilisateur Compte AWS dont vous êtes le propriétaire Vous pouvez autoriser vos utilisateurs IAM à passer à des rôles au sein de vous Compte AWS ou à des rôles définis dans d'autres rôles Comptes AWS que vous possédez. **Note** Si vous souhaitez accorder l'accès à un compte que ne vous appartenant pas ou que vous ne contrôlez pas, consultez [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md) ultérieurement dans cette rubrique. Imaginons que vous disposez d'instances Amazon EC2 qui sont critiques pour votre organisation. Au lieu d'accorder directement à vos utilisateurs l'autorisation de supprimer les instances, vous pouvez créer un rôle avec ces privilèges. Ensuite, autorisez les administrateurs à passer au rôle lorsqu'ils ont besoin de supprimer une instance. Cela ajoute les couches de protection suivantes aux instances : + Vous devez accorder explicitement à vos utilisateurs l'autorisation d'endosser le rôle. + Vos utilisateurs doivent passer activement au rôle à l'aide de l'API AWS Management Console or ou assumer le rôle à l'aide de l' AWS API AWS CLI or. + Vous pouvez ajouter une protection d'authentification multi-facteur (MFA) au rôle afin que seuls les utilisateurs qui se connectent avec un dispositif MFA puissent endosser le rôle. Pour apprendre à configurer un rôle afin que les utilisateurs qui l'endossent doivent d'abord être authentifiés à l'aide de l'authentification multi-facteur (MFA), consultez [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md). Nous vous recommandons d'utiliser cette approche pour appliquer le *principe du moindre privilège*. Cela implique de restreindre l'utilisation des autorisations d'un niveau élevé aux seules fois où elles sont requises pour des tâches spécifiques. Grâce aux rôles, vous pouvez empêcher les modifications accidentelles apportées aux environnements sensibles, en particulier si vous les combinez à des [audits](cloudtrail-integration.md) pour vous assurer que les rôles sont utilisés uniquement quand ils sont requis. Lorsque vous créez un rôle à cette fin, vous spécifiez les comptes en fonction de l'ID des utilisateurs ayant besoin d'accéder à l'élément `Principal` de la politique d'approbation du rôle. Vous pouvez ensuite accorder à des utilisateurs spécifiques de ces autres comptes des autorisations à passer au rôle. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez [Qu'est-ce qu'IAM Access Analyzer ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Un utilisateur d'un compte peut passer à un rôle dans le même compte ou dans un autre compte. Lorsqu'il utilise le rôle, l'utilisateur peut exécuter uniquement les actions et accéder uniquement aux ressources autorisées par le rôle. Leurs autorisations utilisateur d'origine sont suspendues. Lorsque l'utilisateur quitte le rôle, ses autorisations utilisateur d'origine sont restaurées. ## Exemple de scénario utilisant des comptes de développement et de production distincts Imaginez que votre entreprise en dispose de plusieurs Comptes AWS pour isoler un environnement de développement d'un environnement de production. Les utilisateurs du compte de développement peuvent parfois avoir besoin d'accéder aux ressources du compte de production. Par exemple, vous pouvez avoir besoin d'un accès entre comptes lorsque vous promouvez une mise à jour depuis l'environnement de développement vers l'environnement de production. Même si vous pouvez créer des identités (et mots de passe) distinctes pour les utilisateurs qui travaillent dans les deux comptes, la gestion des informations d'identification pour plusieurs comptes rend la gestion des identités difficile. Dans l'illustration suivante, tous les utilisateurs sont gérés dans le compte de développement, mais certains développeurs nécessitent un accès limité au compte de production. Le compte de développement se compose de deux groupes : les Développeurs et les Testeurs, chacun disposant de sa propre politique. ![\[Utiliser un rôle pour déléguer des autorisations à un utilisateur dans un autre compte\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-usingroletodelegate.png) 1. Dans le compte de production, un administrateur utilise IAM pour créer le rôle `UpdateApp` dans ce compte. Dans le rôle, l'administrateur définit une politique d'approbation qui spécifie le compte de développement en tant que `Principal`, ce qui signifie que les utilisateurs autorisés du compte de développement peuvent utiliser le rôle `UpdateApp`. L'administrateur définit également une politique d'autorisations pour le rôle qui spécifie les autorisations de lecture et d'écriture sur le compartiment Amazon S3 appelé `productionapp`. L'administrateur partage ensuite les informations appropriées avec toute personne qui doit endosser le rôle. Ces informations sont le numéro de compte et le nom du rôle (pour les utilisateurs de AWS console) ou le nom de ressource Amazon (ARN) (pour AWS CLI AWS l'accès à l'API). L'ARN du rôle peut ressembler à `arn:aws:iam::123456789012:role/UpdateApp`, où le rôle est appelé `UpdateApp`. Le rôle a été créé dans le compte dont le numéro est 123456789012. **Note** L'administrateur peut, facultativement, configurer le rôle afin que les utilisateurs qui endossent le rôle doivent d'abord être authentifiés à l'aide de l'authentification multi-facteur (MFA). Pour plus d’informations, veuillez consulter [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md). 1. Dans le compte de développement, un administrateur accorde aux membres du groupe Développeurs l'autorisation de changer de rôle. Cela se fait en accordant au groupe de développeurs l'autorisation d'appeler l'`AssumeRole`API AWS Security Token Service (AWS STS) pour le `UpdateApp` rôle. Tout utilisateur IAM appartenant au groupe Développeurs dans le compte de développement peut à présent basculer vers le rôle `UpdateApp` du compte de production. Les autres utilisateurs n'appartenant pas au groupe de développeurs n'ont pas l'autorisation de passer au rôle et ne peuvent, donc, pas accéder au compartiment S3 dans le compte de production. 1. L'utilisateur demande les changements de rôle : + AWS console : l'utilisateur choisit le nom du compte dans la barre de navigation et choisit **Switch Role**. L'utilisateur spécifie l'ID (ou l'alias) du compte, ainsi que le nom du rôle. Sinon, l'utilisateur peut cliquer sur un lien envoyé par e-mail par l'administrateur. Le lien dirige l'utilisateur vers la page **Changer de rôle** avec les détails déjà remplis. + AWS API/AWS CLI : Un utilisateur du groupe Développeurs du compte de développement appelle la `AssumeRole` fonction pour obtenir les informations d'identification du `UpdateApp` rôle. L'utilisateur spécifie l'ARN du rôle `UpdateApp` dans le cadre de l'appel. Si un utilisateur du groupe Testeurs fait la même demande, la demande échoue, car les Testeurs ne sont pas autorisés à appeler `AssumeRole` pour l'ARN de rôle `UpdateApp`. 1. AWS STS renvoie des informations d'identification temporaires : + AWS console : AWS STS vérifie la demande avec la politique de confiance du rôle pour s'assurer que la demande provient d'une entité de confiance (il s'agit du compte de développement). Après vérification, AWS STS renvoie les [informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à la AWS console. + API/CLI : AWS STS vérifie la demande par rapport à la politique de confiance du rôle pour s'assurer que la demande provient d'une entité de confiance (il s'agit du compte de développement). Après vérification, AWS STS renvoie les [informations de sécurité temporaires](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html) à l'application. 1. Les informations d'identification temporaires permettent d'accéder à la AWS ressource : + AWS console : la AWS console utilise les informations d'identification temporaires au nom de l'utilisateur pour toutes les actions de console suivantes, dans ce cas, pour lire et écrire dans le `productionapp` compartiment. La console ne peut pas accéder à d'autres ressources du compte de production. Lorsque l'utilisateur quitte le rôle, les autorisations dont ils disposait avant de changer de rôle sont restaurées. + API/CLI : L'application utilise les informations d'identification de sécurité temporaires pour mettre à jour le compartiment `productionapp`. Avec les informations d'identification de sécurité temporaires, l'application peut uniquement lire et écrire dans le compartiment `productionapp`, mais ne peut pas accéder à d'autres ressources du compte Production. L'application n'a pas besoin de quitter le rôle. Au contraire, elle arrête d'utiliser les informations d'identification temporaires et utilise les informations d'identification d'origine dans les appels d'API suivants. ## Ressources supplémentaires Pour plus d’informations, consultez les ressources suivantes : + [Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md) # Accès pour les applications autres que les charges AWS de travail [Un [rôle IAM](id_roles.md) est un objet dans Gestion des identités et des accès AWS (IAM) auquel des autorisations sont attribuées.](access_policies.md) Lorsque vous [assumez ce rôle](id_roles_manage-assume.md) en utilisant une identité IAM ou une identité extérieure AWS, cela vous fournit des informations d'identification de sécurité temporaires pour votre session de rôle. Il se peut que des charges de travail s'exécutent dans votre centre de données ou dans d'autres infrastructures extérieures AWS qui doivent accéder à vos AWS ressources. Au lieu de créer, de distribuer et de gérer des clés d'accès à long terme, vous pouvez utiliser Gestion des identités et des accès AWS Roles Anywhere (IAM Roles Anywhere) pour authentifier vos applications non AWS liées à des charges de travail. IAM Roles Anywhere utilise les certificats X.509 de votre autorité de certification (CA) pour authentifier les identités et fournir un accès sécurisé à l' Services AWS aide des informations d'identification temporaires fournies par un rôle IAM. **Pour utiliser Rôles Anywhere IAM** 1. Configurez une autorité de certification à l’aide de [AWS Autorité de certification privée](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) ou utilisez une autorité de certification issue de votre propre infrastructure PKI. 1. Après avoir configuré une autorité de certification, vous créez un objet dans Rôles Anywhere IAM appelé *ancre d’approbation*. Ce point d’ancrage établit une approbation entre Rôles Anywhere IAM et votre autorité de certification pour l’authentification. 1. Vous pouvez ensuite configurer vos rôles IAM existants ou créer de nouveaux rôles qui font confiance au service IAM Roles Anywhere. 1. Authentifiez vos tâches non liées aux AWS charges de travail avec IAM Roles Anywhere à l'aide de l'ancre de confiance. AWS accorde les informations d'identification temporaires non liées à la AWS charge de travail au rôle IAM qui a accès à vos AWS ressources. ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux charges de travail non AWS . + Pour plus d'informations sur IAM Roles Anywhere, consultez [Présentation de Gestion des identités et des accès AWS Rôle Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) dans le *Guide de l'utilisateur d'IAM Roles Anywhere*. + Pour savoir comment configurer une infrastructure à clé publique (PKI) pour Rôles Anywhere IAM, consultez la section [Rôles Anywhere IAM avec une autorité de certification externe](https://aws.amazon.com/blogs/) sur le *Blog de sécuritéAWS *. # Accès à des Comptes AWS sites appartenant à des tiers Lorsque des tiers ont besoin d'accéder aux AWS ressources de votre organisation, vous pouvez utiliser des rôles pour leur déléguer l'accès. Par exemple, un tiers peut fournir un service de gestion de vos ressources AWS . Avec les rôles IAM, vous pouvez accorder à ces tiers l'accès à vos AWS ressources sans partager vos informations d'identification AWS de sécurité. Au lieu de cela, le tiers peut accéder à vos AWS ressources en assumant un rôle que vous créez dans votre Compte AWS. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez [Qu'est-ce qu'IAM Access Analyzer ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Les tiers doivent vous fournir les informations suivantes pour vous permettre de créer un rôle qu'ils peuvent endosser : + **L' Compte AWS identifiant du tiers**. Vous spécifiez leur ID d' Compte AWS en tant que principal lorsque vous définissez la politique d'approbation pour le rôle. + **Un ID externe à attacher uniquement à ce rôle**. L'ID externe peut être n'importe quel identifiant qui n'est connu que de vous et de la tierce partie. Par exemple, vous pouvez utiliser un ID de facture entre les tiers et vous-même, mais n'utilisez aucun élément pouvant être deviné, tels que le nom ou le numéro de téléphone du tiers. Vous devez spécifier cet ID lorsque vous définissez la politique d'approbation pour le rôle. Les tiers doivent fournir cette ID lorsqu'ils endosser le rôle. + **Les autorisations dont le tiers a besoin pour utiliser vos ressources  AWS **. Vous devez spécifier ces autorisations lors de la définition de la politique d'autorisation du rôle. Cette politique définit les actions que les utilisateurs tiers peuvent entreprendre et les ressources auxquelles ils peuvent accéder. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle au tiers. Il a besoin de l'ARN de votre rôle pour endosser le rôle. **Important** Lorsque vous accordez à des tiers l'accès à vos AWS ressources, ils peuvent accéder à toutes les ressources que vous spécifiez dans la politique. L'utilisation de vos ressources par ces tiers vous est facturée. Veillez à limiter leur utilisation de vos ressources de façon appropriée. ## IDs Externe pour accès par des tiers Un identifiant externe permet à l’utilisateur qui assume le rôle d’affirmer les circonstances dans lesquelles il travaille. Il permet également au titulaire du compte d'autoriser que le rôle soit endossé uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe consiste à traiter et à prévenir [Le problème de l'adjoint confus](confused-deputy.md). **Important** AWS ne traite pas l'identifiant externe comme un secret. Une fois que vous avez créé un secret, tel qu'une paire de clés d'accès ou un mot de passe AWS, vous ne pouvez plus le consulter. L'ID externe d'un rôle peut être vu par toute personne autorisée à consulter le rôle. ## Quand est-il conseillé d'utiliser un ID externe ? Utilisez un ID externe dans les situations suivantes : + Vous êtes Compte AWS propriétaire et vous avez configuré un rôle pour un tiers qui accède Comptes AWS à d'autres rôles que le vôtre. Vous devez demander à ce tiers un ID externe qu'il inclura lorsqu'il endossera votre rôle. Ensuite, vous vérifiez cet ID externe dans la politique d'approbation de votre rôle. Ainsi, la tierce partie peut endosser votre rôle uniquement lorsqu'elle agit en votre nom. + Vous êtes en position d'endosser des rôles pour le compte de différents clients comme Exemple Corp dans notre précédent scénario. Vous devez attribuer un ID externe unique à chaque client et leur demander de l'ajouter à leur politique d'approbation du rôle. Vous devez ensuite vous assurer de toujours inclure l'ID externe correct dans vos demandes pour endosser des rôles. Vous disposez probablement déjà d'un identifiant unique pour chacun de vos clients, et cet ID unique est suffisant pour être utilisé comme ID externe. L'ID externe n'est pas une valeur spéciale que vous devez créer de manière explicite, ou suivre séparément, juste à cette fin. Vous devez toujours spécifier l'ID externe dans vos appels d'API `AssumeRole`. De plus, lorsqu'un client vous fournit un ARN de rôle, vérifiez que vous pouvez endosser le rôle avec et sans l'ID externe correct. Si vous pouvez endosser le rôle sans l'ID externe approprié, ne stockez pas l'ARN du rôle du client dans votre système. Attendez que le client mette à jour la politique d'approbation du rôle pour demander l'ID externe. Ainsi, vous aidez vos clients à faire ce qu'il faut, ce qui vous permet de vous protéger tous les deux contre le problème du député confus. ## Exemple de scénario utilisant un ID externe Supposons, par exemple, que vous décidiez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres comptes AWS pour d'autres clients. Ne donnez pas à Exemple Corp l'accès à un utilisateur IAM et à ses informations d'identification à long terme dans votre compte AWS . Utilisez plutôt un rôle IAM et ses informations d'identification de sécurité temporaires. Un rôle IAM fournit un mécanisme permettant à un tiers d'accéder à vos AWS ressources sans avoir à partager des informations d'identification à long terme (telles qu'une clé d'accès utilisateur IAM). Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre Compte AWS et le compte Exemple Corp. Une fois cette relation établie, un membre du compte Example Corp peut appeler l' AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API pour obtenir des informations d'identification de sécurité temporaires. Les membres d'Example Corp peuvent ensuite utiliser les informations d'identification pour accéder aux AWS ressources de votre compte. **Note** Pour plus d'informations sur les opérations d' AWS API AssumeRole et sur les autres opérations que vous pouvez appeler pour obtenir des informations d'identification de sécurité temporaires, consultez[Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). Voici comment s'articule ce scénario : 1. Vous embauchez Example Corp qui crée un identifiant client unique pour vous. Ils vous fournissent cet identifiant client unique et leur Compte AWS numéro. Vous avez besoin de ces informations pour créer un rôle IAM à l'étape suivante. **Note** Example Corp peut utiliser n'importe quelle valeur de chaîne pour le ExternalId, à condition qu'elle soit unique pour chaque client. Il peut s'agir d'un numéro de compte client ou encore d'une chaîne aléatoire de caractères, à condition que chaque client ait une valeur différente. Elle n'est pas censée être « secrète ». Example Corp doit fournir la ExternalId valeur à chaque client. Ce qui compte, c'est qu'elle soit générée par Example Corp et ***non*** par ses clients afin de garantir que chaque ID externe est unique. 1. Vous vous connectez AWS et créez un rôle IAM qui permet à Example Corp d'accéder à vos ressources. Comme tout autre rôle IAM, celui-ci dispose de deux politiques, une politique d'autorisation et une politique d'approbation. La politique d'approbation du rôle spécifie qui peut endosser le rôle. Dans notre exemple de scénario, la politique spécifie le Compte AWS nombre d'Example Corp comme étant le`Principal`. Cela permet aux identités de ce compte d'endosser le rôle. En outre, vous ajoutez un élément `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` à la politique d'approbation. Cette `Condition` teste la clé de contexte `ExternalId` afin de s'assurer qu'elle correspond à l'ID client unique issu d'Exemple Corp. Exemple : ``` "Principal": {"AWS": "Example Corp's Compte AWS ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}} ``` 1. La politique d'autorisation du rôle spécifie ce que le rôle permet à un utilisateur de faire. Par exemple, vous pouvez spécifier que le rôle permet à un utilisateur de gérer uniquement vos ressources Amazon EC2 et Amazon RDS, mais pas vos utilisateurs ou groupes IAM. Dans notre exemple de scénario, vous utilisez la politique d'autorisation pour accorder à Example Corp un accès en lecture seule à toutes les ressources de votre compte. 1. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle à Example Corp. 1. Lorsque Example Corp a besoin d'accéder à vos AWS ressources, un membre de l'entreprise appelle l' AWS `sts:AssumeRole`API. L'appel inclut l'ARN du rôle à assumer et le ExternalId paramètre correspondant à leur identifiant client. Si la demande provient d'une personne utilisant Example Corp Compte AWS, et si l'ARN du rôle et l'ID externe sont corrects, la demande aboutit. Il fournit ensuite des informations de sécurité temporaires qu'Example Corp peut utiliser pour accéder aux AWS ressources autorisées par votre rôle. Autrement dit, quand une politique de rôle inclut un ID externe, tous ceux qui souhaitent endosser le rôle doivent non seulement être spécifiés comme principaux dans le rôle, mais également inclure l'ID externe correct. ## Points clés pour les acteurs externes IDs + Dans un environnement mutualisé où vous prenez en charge plusieurs clients avec différents AWS comptes, nous vous recommandons d'utiliser un identifiant externe par Compte AWS client. Cet ID doit être une chaîne aléatoire générée par le tiers. + Pour exiger que le tiers fournisse un ID externe lors de la prise en charge d'un rôle, mettez à jour la politique d'approbation du rôle avec l'ID externe de votre choix. + Pour fournir un identifiant externe lorsque vous assumez un rôle, utilisez l' AWS API AWS CLI or pour assumer ce rôle. Pour plus d'informations, consultez l'opération de l'[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API STS ou l'opération de la [CLI STS assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html). + La valeur `ExternalId` peut avoir un minimum de 2 caractères et un maximum de 1 224 caractères. La valeur doit être alphanumérique sans espaces. Elle peut également inclure les symboles suivants : signe plus (\$1), signe égal (=), virgule (,), point (.), arobase (@), deux points (:), barre oblique (/) et tiret (-). ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à en savoir plus sur la fourniture d’un accès aux Comptes AWS appartenant à des tiers. + Pour savoir comment autoriser d'autres personnes à effectuer des actions dans le vôtre Compte AWS, consultez[Création d’un rôle à l’aide de politiques d’approbation personnalisées](id_roles_create_for-custom.md). + Pour savoir comment accorder l’autorisation de basculer vers un rôle, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md) + Pour savoir comment créer et fournir à des utilisateurs de confiance des informations d’identification de sécurité temporaires, [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md). # Accès à un AWS service De nombreux AWS services nécessitent que vous utilisiez des rôles pour contrôler les accès auxquels ils peuvent accéder. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un [rôle de service](id_roles.md#iam-term-service-role). Lorsqu’un rôle de service remplit un objectif spécial pour un service, il peut être défini comme [rôle lié à un service](id_roles.md#iam-term-service-linked-role). Consultez la [documentation AWS](https://docs.aws.amazon.com/) spécifique à chaque service pour vérifier s'il utilise des rôles et apprendre à attribuer un rôle au service afin qu'il l'utilise. Pour plus de détails sur la création d'un rôle permettant de déléguer l'accès à un service proposé par AWS, consultez[Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md). # Accès aux utilisateurs authentifiés en externe (fédération d’identité) Vos utilisateurs ont peut-être déjà une identité extérieure AWS, par exemple dans votre annuaire d'entreprise. Si ces utilisateurs doivent utiliser des AWS ressources (ou utiliser des applications qui accèdent à ces ressources), ils ont également besoin d'informations d'identification AWS de sécurité. A l'aide d'un rôle IAM, vous pouvez définir des autorisations pour des utilisateurs dont l'identité est fédérée par votre organisation ou un fournisseur d'identité (IdP) tiers. **Note** En tant que bonne pratique de sécurité, nous vous recommandons de gérer l'accès des utilisateurs dans [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) à l'aide de la fédération d'identité plutôt que de créer des utilisateurs IAM. Pour en savoir plus sur les situations spécifiques dans lesquelles un utilisateur IAM est nécessaire, veuillez consulter [Quand créer un utilisateur IAM (au lieu d'un rôle)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose). ## Fédération d'utilisateurs d'une application mobile ou web à l'aide d'Amazon Cognito Si vous créez une application mobile ou Web qui accède aux AWS ressources, l'application a besoin d'informations d'identification de sécurité pour pouvoir envoyer des demandes programmatiques à. AWS Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons d'utiliser [Amazon Cognito](https://aws.amazon.com/cognito/). Vous pouvez utiliser ce service avec le [SDK AWS mobile pour iOS et AWS le SDK mobile pour](https://aws.amazon.com/sdkforios/) [Android et Fire OS afin de créer des identités uniques pour les utilisateurs et](https://aws.amazon.com/sdkforandroid/) de les authentifier afin de sécuriser l'accès à vos ressources. AWS Amazon Cognito prend en charge les mêmes fournisseurs d'identité que ceux répertoriés dans la section suivante, ainsi que les [identités authentifiées par le développeur](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) et les accès non authentifiés (invité). Amazon Cognito fournit également des opérations d'API pour la synchronisation des données utilisateur afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour plus d’informations, veuillez consulter [Amazon Cognito pour les applications mobiles](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito). ## Fédération d'utilisateurs à l'aide de fournisseurs d'identité publics ou d'OpenID Connect Dans la mesure du possible, utilisez Amazon Cognito pour les scénarios d'applications mobiles et Web. Amazon Cognito effectue la majeure partie du behind-the-scenes travail avec les services des fournisseurs d'identité publics pour vous. Il fonctionne avec les mêmes services tiers et prend également en charge les connexions anonymes. Toutefois, dans le cas de scénarios plus complexes, vous pouvez avoir directement recours à un service tiers tel que Login with Amazon, Facebook, Google, ou tout autre IdP compatible avec OpenID Connect (OIDC). Pour plus d’informations sur l’utilisation de la fédération OIDC avec l’un de ces services, consultez [Fédération OIDC](id_roles_providers_oidc.md). ## Fédération d'utilisateurs avec SAML 2.0 Si votre organisation utilise déjà un progiciel de fournisseur d'identité compatible avec le SAML 2.0 (Security Assertion Markup Language 2.0), vous pouvez créer un climat de confiance entre votre organisation en tant que fournisseur d'identité (IdP) et en AWS tant que fournisseur de services. Vous pouvez ensuite utiliser SAML pour fournir à vos utilisateurs une authentification unique (SSO) fédérée AWS Management Console ou un accès fédéré aux opérations d'API d'appel. AWS Par exemple, si votre entreprise utilise Microsoft Active Directory et Active Directory Federation Services, vous pouvez utiliser la fédération à l'aide de SAML 2.0. Pour plus d'informations sur l'utilisation des utilisateurs fédérés avec SAML 2.0, consultez [Fédération SAML 2.0](id_roles_providers_saml.md). ## Fédération d'utilisateurs via la création d'une application de broker d'identité personnalisé Si votre base d'identités n'est pas compatible avec SAML 2.0, vous pouvez créer une application de broker d'identité personnalisé capable d'exécuter une fonction similaire. L'application broker authentifie les utilisateurs, leur demande des informations d'identification temporaires AWS, puis les fournit à l'utilisateur pour qu'il accède aux AWS ressources. Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes qui accèdent aux AWS ressources de l'entreprise. Ils disposent déjà d'identités dans le système d'identité et d'authentification de l'entreprise et, par conséquent, Example Corp. ne souhaite pas créer un utilisateur IAM séparé pour chacun de ses employés. Bob est développeur chez Example Corp. Pour permettre aux applications internes d'Example Corp. d'accéder aux AWS ressources de l'entreprise, Bob développe une application personnalisée de courtier d'identité. L'application vérifie que les employés sont connectés au système d'identité et d'authentification existant d'Example Corp., par exemple LDAP, Active Directory ou un autre système. L'application de broker d'identité obtient ensuite des informations d'identification de sécurité temporaires pour les employés. Ce scénario est similaire au précédent (une application mobile utilisant un système d'authentification personnalisé), sauf que les applications qui ont besoin d'accéder aux AWS ressources s'exécutent toutes sur le réseau de l'entreprise et que l'entreprise dispose d'un système d'authentification existant. Pour obtenir les informations d'identification de sécurité temporaires, l'application de broker d'identité appelle `AssumeRole` ou `GetFederationToken`, selon la façon dont Bob veut gérer les politiques des utilisateurs et le délai d'expiration des informations d'identification. Pour plus d'informations sur les différences entre ces opérations d'API, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md) et [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md).) L'appel renvoie des informations de sécurité temporaires composées d'un identifiant de clé d' AWS accès, d'une clé d'accès secrète et d'un jeton de session. L'application de broker d'identité rend ensuite ces informations d'identification de sécurité temporaires accessibles à l'application interne de l'entreprise. L'application peut alors utiliser ces informations d'identification de sécurité temporaires pour appeler directement AWS . L'application met en cache les informations d'identification jusqu'à ce qu'elles parviennent à expiration, puis demande un nouvel ensemble d'informations d'identification temporaires. L'illustration suivante décrit ce scénario. ![\[Exemple de flux avec une application de broker d'identité personnalisé\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png) Ce scénario utilise les attributs suivants : + L'application de broker d'identité dispose d'autorisations d'accès à l'API du service de jeton (STS) d'IAM pour créer des informations d'identification de sécurité temporaires. + L'application de broker d'identité peut vérifier que les employés sont authentifiés dans le système d'authentification existant. + Les utilisateurs peuvent obtenir une URL temporaire qui leur donne accès à la console de AWS gestion (appelée authentification unique). Pour plus d'informations sur la création d'informations d'identification de sécurité temporaires, consultez [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md). Pour plus d'informations sur l'accès des principaux fédérés SAML à la console de AWS gestion, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) # Création d’un rôle IAM Pour créer un rôle, vous pouvez utiliser les AWS Management Console AWS CLI outils pour Windows ou PowerShell l'API IAM. Si vous utilisez le AWS Management Console, un assistant vous guide tout au long des étapes de création d'un rôle. Les étapes de l'assistant varient légèrement selon que vous créez un rôle pour un AWS service, pour un ou pour un Compte AWS principal fédéré SAML ou OIDC. **Rôles pour les utilisateurs IAM** Créez ce rôle pour déléguer des autorisations au sein de votre Compte AWS ou à des rôles définis dans d'autres rôles Comptes AWS que vous possédez. Un utilisateur d'un compte peut passer à un rôle dans le même compte ou dans un autre compte. Lorsqu'il utilise le rôle, l'utilisateur peut exécuter uniquement les actions et accéder uniquement aux ressources autorisées par le rôle. Leurs autorisations utilisateur d'origine sont suspendues. Lorsque l'utilisateur quitte le rôle, ses autorisations utilisateur d'origine sont restaurées. Pour de plus amples informations, veuillez consulter [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md). Pour de plus amples informations sur la création de rôles avec un accès intercompte, consultez [Création d’un rôle à l’aide de politiques d’approbation personnalisées](id_roles_create_for-custom.md). **Rôles des AWS services** Créez ce rôle pour déléguer des autorisations à un service qui peut effectuer des actions en votre nom. Un [rôle de service](id_roles.md#iam-term-service-role) que vous transmettez à un service doit avoir une politique IAM avec les autorisations qui permettent au service d’effectuer les actions associées à ce service. Différentes autorisations sont requises pour chaque service AWS . Pour plus d’informations sur la création de rôles de service, consultez [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md). Pour plus d’informations sur la création de rôles liés à un service, consultez [Créer un rôle lié à un service](id_roles_create-service-linked-role.md). **Rôles pour la fédération d’identité** Créez ce rôle pour déléguer des autorisations aux utilisateurs qui ont déjà des identités en dehors d’ AWS. Lorsque vous utilisez un fournisseur d'identité , vous n'avez pas à créer de code de connexion personnalisé ni à gérer vos propres identités utilisateur. Vos utilisateurs externes se connectent via un IdP, et vous pouvez autoriser ces identités externes à utiliser les AWS ressources de votre compte. Les fournisseurs d'identité contribuent à la sécurité de votre AWS compte car vous n'avez pas à distribuer ou à intégrer des informations de sécurité à long terme, telles que des clés d'accès, dans votre application. Pour de plus amples informations, veuillez consulter [Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md). # Créer un rôle pour attribuer des autorisations à un utilisateur IAM Vous pouvez utiliser les rôles IAM pour accéder à vos AWS ressources. Avec les rôles IAM, vous pouvez établir des relations de confiance entre votre compte de *confiance* et d'autres comptes de AWS *confiance*. Le compte d'approbation est propriétaire des ressources auxquelles les utilisateurs ont accès , tandis que le compte approuvé contient les utilisateurs devant accéder aux ressources. Toutefois, il est possible qu'un autre compte détienne une ressource dans votre compte. Par exemple, le compte de confiance peut autoriser le compte approuvé à créer de nouvelles ressources, telles que la création de nouveaux objets dans un compartiment Amazon S3. Dans ce cas, le compte qui crée la ressource la détient et contrôle les personnes pouvant y accéder. Une fois que vous avez créé la relation de confiance, un utilisateur IAM ou une application du compte sécurisé peut utiliser l'opération d'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API AWS Security Token Service (AWS STS). Cette opération fournit des informations de sécurité temporaires qui permettent d'accéder aux AWS ressources de votre compte. Les deux comptes peuvent être contrôlés par vous-même, ou le compte contenant les utilisateurs peut être contrôlé par un tiers. Si l'autre compte associé aux utilisateurs est un compte Compte AWS que vous ne contrôlez pas, vous pouvez utiliser l'`externalId`attribut. L'ID externe peut être n'importe quel mot ou nombre convenu avec l'administrateur du compte tiers. Cette option ajoute automatiquement une condition à la politique d'approbation. Cette condition permet à l'utilisateur d'endosser le rôle uniquement si la demande inclut l'élément approprié `sts:ExternalID`. Pour de plus amples informations, veuillez consulter [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md). Pour plus d'informations sur la façon d'utiliser les rôles pour déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts). Pour en savoir plus sur l'utilisation d'un rôle de service afin de permettre aux services l'accès aux ressources de votre compte, consultez [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md). ## Création d'un rôle IAM (console) Vous pouvez utiliser le AWS Management Console pour créer un rôle qu'un utilisateur IAM peut assumer. Supposons, par exemple, que votre organisation en dispose Comptes AWS de plusieurs pour isoler un environnement de développement d'un environnement de production. Pour des informations générales sur la création d'un rôle autorisant les utilisateurs du compte de développement à accéder aux ressources du compte de production, consultez [Exemple de scénario utilisant des comptes de développement et de production distincts](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example). **Autorisations minimales** Pour effectuer les étapes suivantes, vous devez au moins disposer des autorisations IAM suivantes : `access-analyzer:ValidatePolicy` `iam:AttachRolePolicy` `iam:CreatePolicy` `iam:CreateRole` `iam:GetAccountSummary` `iam:GetPolicy` `iam:GetPolicyVersion` `iam:GetRole` `iam:ListAccountAliases` `iam:ListAttachedRolePolicies` `iam:ListOpenIDConnectProviders` `iam:ListPolicies` `iam:ListRolePolicies` `iam:ListRoles` `iam:ListRoleTags` `iam:ListSAMLProviders` ------ #### [ Console ] 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console, choisissez **Rôles**, puis **Créer un rôle**. 1. Choisissez le type du rôle de l'**Compte AWS**. 1. Pour créer un rôle pour votre compte, choisissez **This account** (Ce compte). Pour créer un rôle pour un autre compte, choisissez **Another Compte AWS** (Autre ) et saisissez l'**Account ID** (ID de compte) auquel vous voulez octroyer l'accès à vos ressources. L'administrateur du compte spécifié peut accorder l'autorisation d'endosser ce rôle à n'importe quel utilisateur IAM de ce compte. Pour ce faire, l'administrateur attache une politique à l'utilisateur ou à un groupe qui donne l'autorisation pour l'action `sts:AssumeRole`. Cette politique doit spécifier l'ARN du rôle comme `Resource`. 1. Si vous accordez des autorisations aux utilisateurs d'un compte que vous ne contrôlez pas et si les utilisateurs ont l'intention d'assumer ce rôle par programmation, alors sélectionnez **Require external ID** (Demander un ID externe). L'ID externe peut être n'importe quel mot ou nombre convenu avec l'administrateur du compte tiers. Cette option ajoute automatiquement une condition à la politique d'approbation. Cette condition permet à l'utilisateur d'endosser le rôle uniquement si la demande inclut l'élément approprié `sts:ExternalID`. Pour de plus amples informations, veuillez consulter [Accès à des Comptes AWS sites appartenant à des tiers](id_roles_common-scenarios_third-party.md). **Important** Le choix de cette option restreint l'accès au rôle uniquement par le biais AWS CLI des outils pour Windows PowerShell ou de l' AWS API. Cela est dû au fait que vous ne pouvez pas utiliser la AWS console pour passer à un rôle dont la politique de confiance est assortie d'une `externalId` condition. Vous pouvez néanmoins créer ce type d'accès par programmation, en écrivant un script ou une application à l'aide du kit SDK approprié. Pour plus d'informations et un exemple de script, consultez [How to Enable Cross-Account Access to the AWS Management Console](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) sur AWS Security Blog. 1. Si vous souhaitez restreindre le rôle aux utilisateurs qui se connectent via une authentification MFA, sélectionnez **Demander l'authentification MFA**. Cela ajoute une condition à la politique d'approbation du rôle qui exige une authentification MFA. Un utilisateur qui veut endosser le rôle doit se connecter avec un mot de passe unique temporaire à partir d'un dispositif MFA configuré. Sans authentification MFA, les utilisateurs ne peuvent pas endosser le rôle. Pour plus d'informations sur l'authentification MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md) 1. Choisissez **Suivant**. 1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Créer une politique** pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer à toute personne endossant le rôle. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation. 1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée. Ouvrez la section **Set permissions boundary (Définir une limite d'autorisations)** et choisissez **Use a permissions boundary to control the maximum role permissions (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle)**. Sélectionnez la politique à utiliser comme limite d'autorisations. 1. Choisissez **Suivant**. 1. Dans le champ **Role name** (Nom de rôle), saisissez un nom pour votre rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Lorsqu'un nom de rôle est utilisé dans une politique ou dans le cadre d'un ARN, il est sensible à la casse. Lorsque le nom d'un rôle apparaît aux clients dans la console, par exemple lors du processus de connexion, il n'est pas sensible à la casse. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création. 1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle. 1. Choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Add permissions** (Étape 2 : ajouter des autorisations) pour modifier les cas d'utilisation et les autorisations pour le rôle. Vous serez renvoyé aux pages précédentes pour effectuer les modifications. 1. (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 [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. **Important** N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder aux utilisateurs individuels du compte approuvé des autorisations permettant de basculer vers le rôle dans la console ou d'endosser le rôle par programmation. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). ------ ## Création d'un rôle IAM (AWS CLI) La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle. **Pour créer un rôle pour l'accès entre comptes (AWS CLI)** 1. Créez un rôle : [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 1. Associez une politique d'autorisations gérées au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) or Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) 1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. L'exemple suivant illustre les deux premières étapes les plus courantes pour créer un rôle entre comptes dans un environnement simple. Cet exemple permet à tout utilisateur du compte `123456789012` d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. Cet exemple suppose également que vous utilisiez un ordinateur client exécutant Windows et que vous ayez déjà configuré votre interface de ligne de commande à l'aide des informations d'identification et de la région de votre compte. Pour plus d'informations, voir [Configuration de l'interface de ligne de AWS commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). Dans cet exemple, incluez la politique de confiance suivante dans la première commande lors de la création du rôle. Cette politique de confiance permet aux utilisateurs du compte `123456789012` d'endosser le rôle à l'aide de l'opération `AssumeRole`, mais uniquement s'ils fournissent l'authentification MFA à l'aide des paramètres `SerialNumber` et `TokenCode`. Pour plus d'informations sur l'authentification MFA, consultez [AWS Authentification multifactorielle dans IAM](id_credentials_mfa.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole", "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } } } ] } ``` ------ **Important** Si votre élément `Principal` contient l'ARN d'un rôle ou utilisateur IAM spécifique, alors cet ARN devient un ID du principal unique lorsque la politique est enregistrée. Cela permet de réduire le risque d'escalade des autorisations par la suppression et la nouvelle création du rôle ou de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN, lorsque la politique d'approbation est affichée. Toutefois, si vous supprimez le rôle ou l'utilisateur, l'ID principal apparaît dans la console car il n'est plus AWS possible de le mapper à un ARN. Par conséquent, si vous supprimez et recréez un utilisateur ou rôle référencé dans l'élément `Principal` d'une politique de confiance, vous devez modifier le rôle afin de remplacer l'ARN. Lorsque vous utilisez la deuxième commande, vous devez attacher au rôle une politique gérée existante. La politique d'autorisations suivante permet à toute personne endossant le rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } ] } ``` ------ Pour créer ce rôle `Test-UserAccess-Role`, vous devez d'abord enregistrer la précédente politique de confiance avec le nom `trustpolicyforacct123456789012.json` dans le dossier `policies` de votre disque local `C:`. Enregistrez ensuite la politique d'autorisation précédente en tant que politique gérée par le client dans votre Compte AWS nom`PolicyForRole`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle et attacher la politique gérée. ``` # Create the role and attach the trust policy file that allows users in the specified account to assume the role. $ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json # Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do. $ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole ``` **Important** N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder à des utilisateurs individuels du compte approuvé les autorisations permettant de changer de rôle. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). Une fois que vous avez créé le rôle et que vous lui avez accordé les autorisations nécessaires pour effectuer des AWS tâches ou accéder aux AWS ressources, tous les utilisateurs du `123456789012` compte peuvent assumer le rôle. Pour de plus amples informations, veuillez consulter [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md). ## Création d'un rôle IAM (AWS API) La création d'un rôle à partir de l' AWS API implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont exécutées automatiquement pour vous, mais avec l'API vous devez exécuter explicitement chaque étape vous-même. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle. **Pour créer un rôle dans le code (AWS API)** 1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) Vous pouvez spécifier un emplacement de fichier pour la politique d'approbation du rôle. 1. Associez une politique d'autorisation gérée au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) or Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) **Important** N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous devez également accorder à des utilisateurs individuels du compte approuvé les autorisations permettant de changer de rôle. Pour plus d’informations sur cette étape, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. Une fois que vous avez créé le rôle et que vous lui avez accordé les autorisations nécessaires pour effectuer des AWS tâches ou accéder aux AWS ressources, vous devez accorder des autorisations aux utilisateurs du compte pour leur permettre d'assumer le rôle. Pour plus d'informations sur l'endossement d'un rôle, consultez [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md). ## Création d'un rôle IAM (AWS CloudFormation) Pour plus d'informations sur la création d'un rôle IAM dans AWS CloudFormation, consultez la [référence sur les ressources et les propriétés](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) et les [exemples](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) dans le *guide de l'AWS CloudFormation utilisateur*. *Pour plus d'informations sur les modèles IAM dans AWS CloudFormation, consultez les [extraits de Gestion des identités et des accès AWS modèles](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html) dans le Guide de l'AWS CloudFormation utilisateur.* # Création d'un rôle pour déléguer des autorisations à un AWS service De nombreux AWS services nécessitent que vous utilisiez des rôles pour permettre au service d'accéder aux ressources d'autres services en votre nom. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un [rôle de service](id_roles.md#iam-term-service-role). Lorsqu’un rôle de service remplit un objectif spécial pour un service, il est défini comme [rôle lié à un service](id_roles.md#iam-term-service-linked-role). Pour savoir quels services prennent en charge par les rôles de service liés à un service ou déterminer si un service prend en charge une forme d'informations d'identification temporaires, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour découvrir comment un service individuel utilise des rôles, choisissez son nom dans le tableau pour afficher la documentation de ce service. Lors de la définition de l’autorisation `PassRole`, vous devez vous assurer qu’un utilisateur ne transfère pas un rôle ayant plus d’autorisations que ce que vous souhaitez pour l’utilisateur. Par exemple, Alice n’est peut-être pas autorisée à effectuer des actions Amazon S3. Si Alice pouvait transmettre un rôle à un service autorisant les actions Amazon S3, le service pourrait effectuer des actions Amazon S3 pour le compte d’Alice lors de l’exécution de la tâche. Pour plus d'informations sur la façon dont les rôles aident à déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts). ## Autorisations de fonction de service Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur ou un rôle) de créer ou modifier un rôle lié à un service. **Note** L'ARN d'un rôle lié à un service comprend un principal de service indiqué dans les politiques suivantes comme `SERVICE-NAME.amazonaws.com`. N'essayez pas de deviner le principal de service, car il est sensible à la casse et le format peut varier entre les services AWS . Pour afficher le principal de service d'un service, consultez la documentation de son rôle lié à un service. **Pour permettre à une entité IAM de créer un rôle spécifique lié à un service** Ajoutez la politique suivante à l'entité IAM qui doit créer le rôle lié à un service. Cette politique vous permet de créer un rôle lié au service spécifié et avec un nom spécifique. Vous pouvez ensuite attacher des politiques en ligne ou gérées à ce rôle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" } ] } ``` ------ **Pour permettre à une entité IAM de créer n"importe quel rôle lié à un service** AWS recommande de n'autoriser que les utilisateurs administratifs à créer un rôle de service. Une personne disposant des autorisations nécessaires pour créer un rôle et attacher n'importe quelle politique peut augmenter ses propres autorisations. Au lieu de cela, créez une politique qui l’autorise à créer uniquement les rôles dont elle a besoin ou de demander à un administrateur de créer la fonction du service en son nom. Pour associer une politique permettant à un administrateur d'accéder à votre intégralité Compte AWS, utilisez la politique [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gérée. **Pour permettre à une entité IAM de modifier un rôle lié à un service** Ajoutez la politique suivante à l'entité IAM qui doit modifier le rôle lié à un service. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "EditSpecificServiceRole", "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:GetRole", "iam:GetRolePolicy", "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "iam:PutRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" }, { "Sid": "ViewRolesAndPolicies", "Effect": "Allow", "Action": [ "iam:GetPolicy", "iam:ListRoles" ], "Resource": "*" } ] } ``` ------ **Pour permettre à une entité IAM de supprimer un rôle spécifique lié à un service** Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit supprimer le rôle lié à un service spécifié. ``` { "Effect": "Allow", "Action": "iam:DeleteRole", "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME" } ``` **Pour permettre à une entité IAM de supprimer un rôle de service** AWS recommande de n'autoriser que les utilisateurs administratifs à supprimer un rôle de service. Au lieu de cela, créez une politique qui leur permet de supprimer uniquement les rôles dont ils ont besoin ou de demander à un administrateur de supprimer le rôle de service en leur nom. Pour associer une politique permettant à un administrateur d'accéder à votre intégralité Compte AWS, utilisez la politique [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS gérée. ## Création d'un rôle pour un AWS service (console) Vous pouvez utiliser le AWS Management Console pour créer un rôle pour un service. Puisque certains services prennent en charge plus d'un rôle de service, consultez la documentation [AWS](https://docs.aws.amazon.com/) de votre service pour savoir quel cas d'utilisation choisir. Vous pouvez apprendre à attribuer les politiques d'approbation et d'autorisation nécessaires au rôle, afin que le service puisse endosser le rôle à votre place. Les étapes que vous pouvez utiliser pour contrôler les autorisations de votre rôle peuvent varier, selon la façon dont le service définit les cas d'utilisation et si vous créez un rôle lié à un service. ------ #### [ Console ] **Pour créer un rôle pour une Service AWS (console IAM)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le volet de navigation de la console IAM, sélectionnez **Roles** (Rôles), puis **Create role** (Créer un rôle). 1. Pour **Trusted entity** (Entité de confiance), choisissez **Service AWS**. 1. Pour **Service ou cas d’utilisation**, choisissez un service, puis choisissez le cas d’utilisation. Les cas d'utilisation sont définis par le service pour inclure la politique d'approbation nécessaire au service. 1. Choisissez **Suivant**. 1. Pour **Politiques d’autorisations**, les options dépendent du cas d’utilisation que vous avez sélectionné : + Si le service définit les autorisations pour le rôle, il n’est pas possible de sélectionner les politiques d’autorisation. + Choisissez parmi un ensemble limité de politiques d’autorisation. + Choisissez parmi toutes les politiques d’autorisation. + Ne sélectionnez aucune politique d’autorisation, créez les politiques une fois le rôle créé, puis attachez-les au rôle. 1. (Facultatif) Définissez une [limite d'autorisations](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Il s’agit d’une fonctionnalité avancée disponible pour les fonctions de service, mais pas pour les rôles liés à un service. 1. Ouvrez la section **Définir une limite des autorisations** et choisissez **Utiliser une limite des autorisations pour contrôler le nombre maximum d’autorisations de rôle**. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. 1. Sélectionnez la politique à utiliser comme limite d'autorisations. 1. Choisissez **Suivant**. 1. Pour **Nom du rôle**, les options dépendent du service : + Si le service définit le nom du rôle, vous ne pouvez pas modifier le nom du rôle. + Si le service définit un préfixe pour le nom du rôle, vous pouvez saisir un suffixe facultatif. + Si le service ne définit pas le nom du rôle, vous pouvez le nommer. **Important** Lorsque vous nommez un rôle, notez ce qui suit : Les noms de rôles doivent être uniques au sein du Compte AWS vôtre et ne peuvent pas être rendus uniques au cas par cas. Par exemple, ne créez pas deux rôles nommés **PRODROLE** et **prodrole**. Lorsqu’un nom de rôle est utilisé dans une politique ou dans le cadre d’un ARN, le nom de rôle est sensible à la casse. Cependant, lorsqu’un nom de rôle apparaît aux clients dans la console, par exemple lors de la procédure d’ouverture de session, le nom de rôle est insensible à la casse. Vous ne pouvez pas modifier le nom du rôle après sa création, car d’autres entités pourraient y faire référence. 1. (Facultatif) Pour **Description**, saisissez la description du rôle. 1. (Facultatif) Pour modifier les cas d’utilisation et les autorisations du rôle, dans les sections **Étape 1 : sélectionner les entités de confiance** ou **Étape 2 : ajouter des autorisations**, sélectionnez **Modifier**. 1. (Facultatif) Pour identifier, organiser ou rechercher le rôle, ajoutez des identifications sous forme de paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, consultez la section [Balises pour les Gestion des identités et des accès AWS ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) dans le Guide de l'*utilisateur d'IAM*. 1. Passez en revue les informations du rôle, puis choisissez **Create role** (Créer un rôle). ------ ## Création d'un rôle pour un service (AWS CLI) La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Si le service concerné est Amazon EC2 vous devez également créer un profil d'instance et lui ajouter le rôle. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle. **Pour créer un rôle pour un AWS service à partir du AWS CLI** 1. La commande `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` suivante crée un rôle nommé *Rôle test* et lui attache une politique de confiance : `aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json` 1. Associez une politique d'autorisations gérées au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Par exemple, la commande `attach-role-policy` suivante attache la politique gérée par AWS , nommée `ReadOnlyAccess`, au rôle IAM nommé `ReadOnlyRole` : `aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole` or Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) Pour ajouter une politique d'autorisations en ligne, reportez-vous à l'exemple suivant : `aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json` 1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. Si vous comptez utiliser le rôle avec Amazon EC2 ou un autre AWS service utilisant Amazon EC2, vous devez le stocker dans un profil d'instance. Un profil d'instance est un conteneur pour un rôle que vous pouvez attacher à une instance Amazon EC2 lorsqu'elle est lancée. Un profil d'instance peut contenir un rôle uniquement et cette limite ne peut pas être augmentée. Si vous créez le rôle à l'aide du AWS Management Console, le profil d'instance est créé pour vous sous le même nom que le rôle. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). Pour de plus amples informations sur le lancement d’une instance EC2 avec un rôle, consultez [Contrôle de l’accès aux ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) dans le *Guide de l’utilisateur Amazon EC2*. **Pour créer un profil d'instance et y stocker le rôle (AWS CLI)** 1. Création d'un profil d'instance : [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) 1. Ajoutez le rôle au profil d'instance : [aws iam add-role-to-instance -profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) L' AWS CLI exemple de commande ci-dessous illustre les deux premières étapes de création d'un rôle et d'attribution d'autorisations. Il présente également les deux étapes de la création d'un profil d'instance et de l'ajout du rôle au profil. Cet exemple de politique de confiance permet au service Amazon EC2 d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. L'exemple suppose également que vous utilisiez un ordinateur client exécutant Windows et que vous ayez déjà configuré votre interface de ligne de commande avec vos informations d'identification et votre région. Pour plus d'informations, voir [Configuration de l'interface de ligne de AWS commande](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). Dans cet exemple, incluez la politique de confiance suivante dans la première commande lors de la création du rôle. Cette politique de confiance permet au service Amazon EC2 d'endosser le rôle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole" } } ``` ------ Lorsque vous utilisez la deuxième commande, vous devez attacher une politique d'autorisations au rôle. L'exemple de politique d'autorisations suivant permet au rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } } ``` ------ Pour créer ce rôle `Test-Role-for-EC2`, vous devez d'abord enregistrer la politique de confiance précédente avec le nom `trustpolicyforec2.json` et la politique d'autorisations précédente avec le nom `permissionspolicyforec2.json` dans le répertoire `policies` de votre disque local `C:`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle, attacher la politique, créer le profil d'instance et ajouter le rôle au profil d'instance. ``` # Create the role and attach the trust policy that allows EC2 to assume this role. $ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json # Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do. $ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json # Create the instance profile required by EC2 to contain the role $ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3 # Finally, add the role to the instance profile $ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2 ``` Lorsque vous lancez l'instance EC2, spécifiez le nom du profil de l'instance sur la page **Configurer les détails de l'instance** si vous utilisez la AWS console. Si vous utilisez la commande CLI `aws ec2 run-instances`, précisez le paramètre `--iam-instance-profile`. ## Création d'un rôle pour un service (AWS API) La création d'un rôle à partir de l' AWS API implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont exécutées automatiquement pour vous, mais avec l'API vous devez exécuter explicitement chaque étape vous-même. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Si le service concerné est Amazon EC2 vous devez également créer un profil d'instance et lui ajouter le rôle. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle. **Pour créer un rôle pour un AWS service (AWS API)** 1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) Vous pouvez spécifier un emplacement de fichier pour la politique d'approbation du rôle. 1. Associez une politique d'autorisations gérées au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) or Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) 1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. Si vous comptez utiliser le rôle avec Amazon EC2 ou un autre AWS service utilisant Amazon EC2, vous devez le stocker dans un profil d'instance. Un profil d'instance est un conteneur pour un rôle. Chaque profil d'instance peut contenir un rôle uniquement et cette limite ne peut pas être augmentée. Si vous créez le rôle dans le AWS Management Console, le profil d'instance est créé pour vous sous le même nom que le rôle. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). Pour de plus amples informations sur le lancement d’une instance Amazon EC2 avec un rôle, consultez [Contrôle de l’accès aux ressources Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances) dans le *Guide de l’utilisateur Amazon EC2*. **Pour créer un profil d'instance et y stocker le rôle (AWS API)** 1. Créez un profil d'instance : [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) 1. Ajoutez le rôle au profil d'instance : [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) # Créer un rôle lié à un service Un rôle lié à un service est un type unique de rôle IAM directement lié à un service AWS . Les rôles liés au service sont prédéfinis par le service et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom. Le service lié définit aussi la manière dont vous créez, modifiez et supprimez un rôle lié à un service. Un service peut créer ou supprimer automatiquement le rôle. Il peut vous permettre de créer, modifier ou supprimer le rôle dans le cadre des opérations d'un assistant ou d'un processus du service. Ou il peut vous demander d'utiliser IAM pour créer ou supprimer le rôle. Quelle que soit la méthode, les rôles liés à un service simplifient le processus de configuration d'un service étant donné que vous n'avez pas besoin d'ajouter manuellement les autorisations requises pour que le service effectue des actions en votre nom. **Note** N'oubliez pas que les fonctions du service sont différentes des rôles liés à un service. Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*. Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service. Le service lié définit les autorisations de ses rôles liés à un service et, sauf définition contraire, seul ce service peut endosser les rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM. Avant que vous ne puissiez supprimer les rôles, vous devez d'abord supprimer les ressources qui leur sont associées. Ainsi, vous ne risquez pas de supprimer involontairement l’autorisation d’accéder aux ressources. **Astuce** Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Choisissez un **Yes** (Oui) ayant un lien permettant de consulter les détails du rôle pour ce service. ## Autorisations de rôles liés à un service Vous devez configurer les autorisations d'une entité IAM (utilisateur ou rôle) de manière à permettre à l'utilisateur ou au rôle de créer ou modifier le rôle lié à un service. **Note** L'ARN d'un rôle lié à un service comprend un principal de service indiqué dans les stratégies ci-dessous comme `SERVICE-NAME.amazonaws.com`. N'essayez pas de deviner le principal du service, car il distingue les majuscules et minuscules et le format peut varier d'un AWS service à l'autre. Pour afficher le principal de service d'un service, consultez la documentation de son rôle lié à un service. **Pour permettre à une entité IAM de créer un rôle spécifique lié à un service** Ajoutez la politique suivante à l'entité IAM qui doit créer le rôle lié à un service. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*", "Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}} }, { "Effect": "Allow", "Action": [ "iam:AttachRolePolicy", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*" } ] } ``` ------ **Pour permettre à une entité IAM de créer un rôle lié à un service** Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit créer un rôle lié à un service, ou un rôle de service incluant les politiques requises. Cette instruction de politique n'autorise pas l'entité IAM à attacher une politique à ce rôle. ``` { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Pour permettre à une entité IAM de modifier la description de rôles liés à un service** Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit modifier la description d'un rôle lié à un service ou d'un rôle de service. ``` { "Effect": "Allow", "Action": "iam:UpdateRoleDescription", "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Pour permettre à une entité IAM de supprimer un rôle spécifique lié à un service** Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit supprimer le rôle lié à un service. ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*" } ``` **Pour permettre à une entité IAM de supprimer un rôle lié à un service** Ajoutez l'instruction suivante à la politique d'autorisation de l'entité IAM qui doit supprimer un rôle lié à un service, mais pas le rôle de service. ``` { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws:iam::*:role/aws-service-role/*" } ``` **Pour permettre à une entité IAM de transmettre un rôle existant au service** Certains AWS services vous permettent de transmettre un rôle existant au service, au lieu de créer un nouveau rôle lié au service. Pour ce faire, un utilisateur doit disposer des autorisations nécessaires pour *transmettre le rôle* au service. Ajoutez l'instruction suivante à la politique d'autorisations de l'entité IAM qui doit transmettre un rôle. Cette instruction de politique autorise également l'entité à afficher une liste des rôles à partir de laquelle ils peuvent choisir le rôle à transmettre. Pour de plus amples informations, veuillez consulter [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md). ``` { "Sid": "PolicyStatementToAllowUserToListRoles", "Effect": "Allow", "Action": ["iam:ListRoles"], "Resource": "*" }, { "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ" } ``` ## Autorisations indirectes avec rôles liés à un service Les autorisations accordées par un rôle lié à un service peuvent être transférées indirectement à d'autres utilisateurs et rôles. Lorsqu'un rôle lié à un service est utilisé par un AWS service, ce rôle lié au service peut utiliser ses propres autorisations pour appeler d'autres services. AWS Cela signifie que les utilisateurs et les rôles ayant l'autorisation d'appeler un service qui utilise un rôle lié à un service peuvent avoir un accès indirect aux services auxquels ce rôle lié à un service peut accéder. Par exemple, lorsque vous créez une instance de base données Amazon RDS, [un rôle lié à un service pour RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html) est automatiquement créé s'il n'existe pas déjà. Ce rôle lié au service permet à RDS d'appeler Amazon EC2, Amazon SNS, Amazon CloudWatch Logs et Amazon Kinesis en votre nom. Si vous autorisez les utilisateurs et les rôles de votre compte à modifier ou à créer des bases de données RDS, ils pourront peut-être interagir indirectement avec Amazon EC2, Amazon SNS, les journaux Amazon Logs et les ressources CloudWatch Amazon Kinesis en appelant RDS, car RDS utiliserait son rôle lié au service pour accéder à ces ressources. ### Méthodes pour créer un rôle lié à un service La méthode que vous utilisez pour créer un rôle lié à un service dépend dudit service. Dans certains cas, vous n'avez pas besoin de créer manuellement un rôle lié à un service. Par exemple, lorsque vous terminez une action donnée (comme créer une ressource) dans le service, le service peut créer le rôle lié au service à votre place. Ou, si vous utilisiez un service avant qu'il ne prenne en charge les rôles liés à un service, alors le service peut avoir créé automatiquement le rôle dans votre compte. Pour en savoir plus, veuillez consulter la section [Un nouveau rôle est apparu dans mon AWS compte](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared). Dans d'autres cas, le service peut prendre en charge la création manuelle d'un rôle lié à un service à l'aide la console, l'API ou de la CLI. Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Pour savoir si le service prend en charge la création du rôle lié à un service, choisissez le lien **Oui** pour afficher la documentation du rôle lié à ce service. Si le service ne prend pas en charge la création du rôle, alors vous pouvez utiliser IAM pour créer le rôle lié à un service. **Important** Les rôles liés à un service comptent dans votre limite de [rôles IAM dans un Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities), mais si vous avez atteint cette limite, vous pouvez toujours créer des rôles liés à un service dans votre compte. Seuls les rôles liés à un service peuvent dépasser la limite sans conséquence. ### Création d'un rôle lié à un service (console) Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis la console, l'API ou la CLI du service. **Pour créer un rôle lié à un service (console)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. Puis, choisissez **Create role** (Créer un rôle). 1. Choisissez le type de fonction du **service AWS **. 1. Choisissez le cas d'utilisation de votre service. Les cas d'utilisation sont définis par le service pour inclure la politique d'approbation requise par le service. Ensuite, choisissez **Suivant**. 1. Choisissez une ou plusieurs politiques d'autorisation à attacher au rôle. En fonction du cas d'utilisation sélectionné, le service peut effectuer n'importe laquelle des options suivantes : + Définissez les autorisations utilisées par le rôle. + Vous permet de choisir parmi un ensemble limité d'autorisations. + Vous permet de choisir parmi toutes les autorisations. + Vous permet de choisir de ne sélectionner aucune stratégie pour le moment, mais de créer les politiques plus tard et de les attacher au rôle. Cochez la case en regard de la politique qui affecte les autorisations que vous voulez octroyer au rôle, puis choisissez **Suivant**. **Note** Les autorisations que vous spécifiez sont disponibles à toutes les entités qui utilisent le rôle. Par défaut, un rôle ne dispose d'aucune autorisation. 1. Pour **Nom du rôle**, le degré de la personnalisation du nom du rôle est défini par le service. Si le service définit le nom du rôle, alors cette option n'est pas modifiable. Dans d'autres cas, le service peut définir un préfixe pour le rôle ou vous laisser saisir un suffixe facultatif. Si possible, saisissez un suffixe de nom de rôle à ajouter au nom par défaut. Ce suffixe vous aide à identifier l'objectif de ce rôle. Les noms de rôle de votre compte AWS doivent être uniques. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **\$1SAMPLE** et **\$1sample**. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création. 1. (Facultatif) Dans le champ **Description**, modifiez la description du nouveau rôle lié à un service. 1. Vous ne pouvez pas attacher des balises à des rôles liés à un service lors de la création. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. ### Création d'un rôle lié à un service (AWS CLI) Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis la CLI du service. Si la CLI du service n'est pas prise en charge, vous pouvez employer les commandes IAM pour créer un rôle lié à un service avec la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle. **Pour créer un rôle lié à un service (AWS CLI)** Exécutez la commande suivante : ``` aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com ``` ### Création d'un rôle lié à un service (API)AWS Avant de créer un rôle lié à un service dans IAM, sachez si le service lié crée automatiquement des rôles liés au service et si vous pouvez créer le rôle depuis l'API du service. Si l'API de service n'est pas prise en charge, vous pouvez utiliser l' AWS API pour créer un rôle lié au service avec la politique de confiance et les politiques intégrées dont le service a besoin pour assumer ce rôle. **Pour créer un rôle lié à un service (API)AWS ** Utilisez l'appel d'API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Dans la demande, spécifiez un nom de service sous la forme `SERVICE_NAME_URL.amazonaws.com`. Par exemple, pour créer le rôle lié à un service **Robots Lex**, utilisez `lex.amazonaws.com`. # Créer un rôle pour un fournisseur d’identité tiers Vous pouvez utiliser des fournisseurs d'identité au lieu de créer des utilisateurs IAM dans votre Compte AWS. Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et les fournisseurs d'identité, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md). ## Création d’un rôle pour les principaux fédérés OIDC et SAML (console) Les procédures permettant de créer un rôle dépendent des fournisseurs tiers choisis : + Pour OpenID Connect (OIDC), consultez [Création d’un rôle pour la fédération OpenID Connect (console)](id_roles_create_for-idp_oidc.md). + Pour SAML 2.0, consultez [Création d’un rôle pour la fédération SAML 2.0 (console)](id_roles_create_for-idp_saml.md). ## Création d'un rôle pour l'accès fédéré (AWS CLI) Les étapes à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC ou SAML) à partir de la AWS CLI sont identiques. La différence porte sur le contenu de la politique d'approbation que vous créez dans les étapes préalables requises. Commencez par suivre les étapes de la section **Prérequis** pour le type de fournisseur que vous utilisez : + Pour un fournisseur OIDC, consultez [Prérequis pour la création d’un rôle pour OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites). + Pour un fournisseur SAML, consultez [Prérequis pour la création d'un rôle pour SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites). La création d'un rôle à partir de AWS CLI implique plusieurs étapes. Lorsque vous utilisez la console pour créer un rôle, la plupart des étapes sont effectuées pour vous, mais AWS CLI vous devez effectuer chaque étape vous-même de manière explicite. Vous devez créer le rôle et lui attribuer une politique d'autorisations. Vous pouvez également définir la [limite d'autorisations](access_policies_boundaries.md) pour votre rôle. **Pour créer un rôle (AWS CLI)** 1. Créez un rôle : [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 1. Associez une politique d'autorisation au rôle : [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) or Créez une politique d'autorisation intégrée pour le rôle : [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) 1. (Facultatif) Ajoutez des attributs personnalisés au rôle en associant des balises : [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les rôles IAM (AWS CLI ou AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. L'exemple suivant illustre les deux premières étapes les plus courantes pour créer un rôle de fournisseur d'identité dans un environnement simple. Cet exemple permet à tout utilisateur du compte `123456789012` d'endosser le rôle et d'afficher le compartiment Amazon S3 `example_bucket`. Cet exemple suppose également que vous exécutez le AWS CLI sur un ordinateur exécutant Windows et que vous l'avez déjà configuré AWS CLI avec vos informations d'identification. Pour plus d’informations, consultez [Configuration de l’ AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html). L'exemple de politique de confiance suivant est conçu pour une application mobile si l'utilisateur se connecte à l'aide d'Amazon Cognito. Dans cet exemple, *us-east:12345678-ffff-ffff-ffff-123456* représente l'ID du pool d'identités attribué par Amazon Cognito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}} } } ``` ------ La politique d'autorisations suivante permet à toute personne endossant le rôle d'exécuter uniquement l'action `ListBucket` sur le compartiment Amazon S3 `example_bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket" } } ``` ------ Pour créer ce rôle `Test-Cognito-Role`, vous devez d'abord enregistrer la politique de confiance précédente avec le nom `trustpolicyforcognitofederation.json` et la politique d'autorisations précédente avec le nom `permspolicyforcognitofederation.json` dans le dossier `policies` de votre disque local `C:`. Vous pouvez ensuite utiliser les commandes suivantes pour créer le rôle et attacher la politique en ligne. ``` # Create the role and attach the trust policy that enables users in an account to assume the role. $ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json # Attach the permissions policy to the role to specify what it is allowed to do. aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json ``` ## Création d'un rôle pour l'accès fédéré (AWS API) Les étapes à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC ou SAML) à partir de la AWS CLI sont identiques. La différence porte sur le contenu de la politique d'approbation que vous créez dans les étapes préalables requises. Commencez par suivre les étapes de la section **Prérequis** pour le type de fournisseur que vous utilisez : + Pour un fournisseur OIDC, consultez [Prérequis pour la création d’un rôle pour OIDC](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites). + Pour un fournisseur SAML, consultez [Prérequis pour la création d'un rôle pour SAML](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites). **Pour créer un rôle (AWS API)** 1. Créez un rôle : [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) 1. Associez une politique d'autorisation au rôle : [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) or Créez une politique d'autorisation intégrée pour le rôle : [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) 1. (Facultatif) Ajoutez des attributs personnalisés à l'utilisateur en attachant des balises : [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html) Pour de plus amples informations, veuillez consulter [Gestion des balises sur les utilisateurs IAM (AWS CLI ou AWS API)](id_tags_users.md#id_tags_users_procs-cli-api). 1. (Facultatif) Définissez la [limite des autorisations](access_policies_boundaries.md) pour le rôle : [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Une limite d'autorisations contrôle les autorisations maximum dont un rôle peut disposer. Les limites d'autorisations constituent une AWS fonctionnalité avancée. # Création d’un rôle pour la fédération OpenID Connect (console) Vous pouvez utiliser les fournisseurs d'identité fédérés OpenID Connect (OIDC) au lieu de créer Gestion des identités et des accès AWS des utilisateurs dans votre. Compte AWS Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et IdPs, voir[Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md). ## Prérequis pour la création d’un rôle pour OIDC Avant de pouvoir créer un rôle pour la fédération OIDC, vous devez tout d’abord suivre les étapes requises suivantes. **Pour préparer la création d’un rôle pour la fédération OIDC** 1. Inscrivez-vous auprès d'un ou plusieurs services offrant une identité OIDC fédérée. Si vous créez une application qui a besoin d'accéder à vos AWS ressources, vous devez également configurer votre application avec les informations du fournisseur. Ainsi, le fournisseur vous communique un ID d'application ou de public unique pour votre application. (Les fournisseurs utilisent une terminologie différente pour ce processus. Ce guide utilise le terme *configurer* pour désigner le processus d'identification de votre application auprès du fournisseur.) Vous pouvez configurer plusieurs applications auprès de chaque fournisseur, ou plusieurs fournisseurs avec une seule application. Consultez les informations sur l'utilisation des fournisseurs d'identité comme suit : + [Login with Amazon Developer Center](https://login.amazon.com/) + [Add Facebook Login to Your App or Website](https://developers.facebook.com/docs/facebook-login/v2.1) sur le site des développeurs Facebook. + [Utilisation de la OAuth version 2.0 pour la connexion (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login) sur le site des développeurs de Google. 1. Après avoir reçu les informations requises de la part de l'IdP, créez un IdP dans IAM. Pour de plus amples informations, veuillez consulter [Création d’un fournisseur d’identité OpenID Connect (OIDC) dans IAM](id_roles_providers_create_oidc.md). **Important** Si vous utilisez un fournisseur d'identités OIDC de Google, Facebook ou Amazon Cognito, ne créez pas d'IdP IAM distinct dans l' AWS Management Console. Ces fournisseurs d'identité OIDC sont déjà intégrés AWS et sont à votre disposition. Ignorez cette étape et créez de nouveaux rôles à l'aide de votre IdP à l'étape suivante. 1. Préparez les politiques pour le rôle que les utilisateurs authentifiés auprès de l'IdP vont endosser. Comme n'importe quel rôle, celui d'une application mobile inclut deux politiques. L'une est la politique de confiance qui spécifie la personne capable d'endosser le rôle. L'autre est la politique d'autorisation qui spécifie les actions et les ressources AWS auxquelles l'application mobile peut accéder ou non. Pour le Web IdPs, nous vous recommandons d'utiliser [Amazon Cognito](https://aws.amazon.com/cognito/) pour gérer les identités. Dans ce cas, utilisez une politique de confiance semblable à cet exemple. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"}, "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"} } } } ``` ------ Remplacez `us-east-2:12345678-abcd-abcd-abcd-123456` par l'ID du groupe d'identités qu'Amazon Cognito vous assigne. Si vous configurez manuellement un fournisseur d’identité OIDC, lorsque vous créez la politique de confiance, vous devez utiliser trois valeurs pour garantir que seule votre application peut endosser le rôle : + Pour l'élément `Action`, utilisez l'action `sts:AssumeRoleWithWebIdentity`. + Pour l'élément `Principal`, utilisez la chaîne `{"Federated":providerUrl/providerArn}`. + Pour certains OIDC courants IdPs, il `providerUrl` s'agit d'une URL. Les exemples suivants incluent des méthodes permettant de spécifier le principal pour certaines méthodes courantes IdPs : `"Principal":{"Federated":"cognito-identity.amazonaws.com"}` `"Principal":{"Federated":"www.amazon.com"}` `"Principal":{"Federated":"graph.facebook.com"}` `"Principal":{"Federated":"accounts.google.com"}` + Pour les autres fournisseurs OIDC, utilisez l'Amazon Resource Name (ARN) du fournisseur d'identité OIDC créé dans [Step 2](#idpoidcstep2), comme dans l'exemple suivant : `"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}` + Pour l'élément `Condition`, utilisez une condition `StringEquals` pour limiter les autorisations. Testez l'ID du groupe d'identités pour Amazon Cognito ou l'ID d'application pour les autres fournisseurs. L'ID du groupe d'identité doit correspondre à l'ID d'application obtenu lors de la configuration de l'application avec le fournisseur d'identité. Cette correspondance entre les IDs garantit que la demande provient de votre application. **Note** Les rôles IAM pour les groupes d’identités Amazon Cognito font confiance au principal de service `cognito-identity.amazonaws.com` pour assumer ce rôle. Les rôles de ce type doivent contenir au moins une clé de condition pour limiter les principaux qui peuvent assumer le rôle. Des considérations supplémentaires s’appliquent aux groupes d’identités Amazon Cognito qui assument des [rôles IAM entre comptes](access_policies-cross-account-resource-access.md). Les politiques d’approbation associées à ces rôles doivent accepter le principal de service `cognito-identity.amazonaws.com` et contenir la clé de condition `aud` permettant de limiter l’attribution de rôles aux utilisateurs issus des groupes d’identités que vous souhaitez. Une politique qui fait confiance aux groupes d’identités Amazon Cognito sans cette condition crée un risque qu’un utilisateur d’un groupe d’identités non prévu puisse assumer le rôle. Pour plus d’informations, consultez la section [Politiques d’approbation pour les rôles IAM dans l’authentification de base (classique)](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies) dans le *Guide du développeur Amazon Cognito*. Créez un élément de condition semblable à un des exemples suivants, en fonction du fournisseur d'identité que vous utilisez : `"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}` `"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}` `"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}` `"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}` Pour les fournisseurs OIDC, utilisez l'URL complète du fournisseur d'identité OIDC avec la clé de contexte `aud`, comme dans exemple suivant : `"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}` **Note** Les valeurs du principal dans la politique de confiance pour le rôle sont propres à un fournisseur d'identité. Un rôle pour OIDC ne peut spécifier qu’un seul principal. Par conséquent, si l'application mobile autorise des utilisateurs à se connecter à partir de plusieurs fournisseurs d'identité, créez un rôle distinct pour chaque fournisseur d'identité que vous souhaitez prendre en charge. Créez des politiques de confiance distinctes pour chaque fournisseur d'identité. Si un utilisateur utilise une application mobile pour se connecter à partir de Login with Amazon (Connexion avec Amazon, l'exemple suivant de politique de confiance s'appliquerait. Dans l'exemple, *amzn1.application-oa2-123456* représente l'ID d'application attribué par Amazon lorsque vous avez configuré l'application à l'aide de Login with Amazon. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForLoginWithAmazon", "Effect": "Allow", "Principal": {"Federated": "www.amazon.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}} }] } ``` ------ Si un utilisateur utilise une application mobile pour se connecter à partir de Facebook, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, *111222333444555* représente l'ID d'application attribué par Facebook. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForFacebook", "Effect": "Allow", "Principal": {"Federated": "graph.facebook.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}} }] } ``` ------ Si un utilisateur utilise une application mobile pour se connecter à partir de Google, l'exemple suivant de politique de confiance s'appliquerait. Dans cet exemple, *666777888999000* représente l'ID d'application attribué par Google. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForGoogle", "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}} }] } ``` ------ Si un utilisateur utilise une application mobile pour se connecter depuis Amazon Cognito, l'exemple de politique de confiance suivant s'applique. Dans cet exemple, *us-east:12345678-ffff-ffff-ffff-123456* représente l'ID du pool d'identités attribué par Amazon Cognito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "RoleForCognito", "Effect": "Allow", "Principal": {"Federated": "cognito-identity.amazonaws.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}} }] } ``` ------ ## Création d’un rôle pour OIDC Après avoir exécuté les prérequis, vous pouvez créer le rôle dans IAM. *Pour les fournisseurs d'identité OpenID Connect (OIDC) partagés reconnus (IdPs), IAM exige une évaluation explicite des revendications spécifiques dans les jetons Web JSON (JWTs), connus sous le nom de contrôles des fournisseurs d'identité.* Pour plus d'informations sur les OIDC IdPs dotés de *contrôles par fournisseur d'identité*, consultez. [Contrôles des fournisseurs d’identité pour les fournisseurs OIDC partagés](id_roles_providers_oidc_secure-by-default.md) La procédure suivante décrit comment créer une le rôle pour la fédération OIDC dans la AWS Management Console. Pour créer un rôle à partir de l' AWS API AWS CLI or, consultez les procédures sur[Créer un rôle pour un fournisseur d’identité tiers](id_roles_create_for-idp.md). **Important** Si vous utilisez Amazon Cognito, utilisez la console Amazon Cognito pour configurer les rôles. Sinon, utilisez la console IAM pour créer un rôle pour la fédération OIDC. **Pour créer un rôle IAM pour la fédération OIDC** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation, choisissez **Roles** (Rôles), puis **Create role** (Créer un rôle). 1. Choisissez **l’identité Web** comme type d’entité d’approbation et sélectionnez **Suivant**. 1. Pour **Identity provider** (Fournisseur d'identité), choisissez l'IdP de votre rôle : + Si vous créez un rôle pour un fournisseur d'identité Web individuel, choisissez entre **Login with Amazon** (Connexion avec Amazon), **Facebook** ou **Google**. **Note** Vous devez créer un rôle distinct pour chaque IdP que vous souhaitez prendre en charge. + Si vous souhaitez créer un rôle de scénario avancé pour Amazon Cognito, choisissez **Amazon Cognito**. **Note** Vous ne devez créer manuellement un rôle à utiliser avec Amazon Cognito que lorsque vous travaillez sur un scénario avancé. Sinon, Amazon Cognito peut créer des rôles pour vous. Pour plus d'informations sur Amazon Cognito, consultez [Fournisseurs d'identité externes - Pools d’identités (identités fédérées)](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) dans le *Manuel du développeur Amazon Cognito*. + Si vous souhaitez créer un rôle pour GitHub Actions, vous devez commencer par ajouter le fournisseur GitHub OIDC à IAM. **Après avoir ajouté le fournisseur GitHub OIDC à IAM, choisissez token.actions.githubusercontent.com.** **Note** Pour plus d'informations sur la façon de AWS configurer le fournisseur OIDC GitHub de confiance en tant qu'identité fédérée, consultez [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Pour plus d'informations sur les meilleures pratiques en matière de limitation de l'accès aux rôles associés à l'IdP IAM GitHub pour, [Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC](#idp_oidc_Create_GitHub) consultez cette page. + Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, vous devez commencer par ajouter le fournisseur Terraform OIDC à IAM. Après avoir ajouté le fournisseur Terraform OIDC à IAM, choisissez **app.terraform.io.** **Important** Rôles IAM pour HashiCorp Cloud Platform (HCP) Le fournisseur Terraform OIDC doit évaluer la clé de condition IAM dans la politique de confiance des `app.terraform.io:sub` rôles. Cette clé de condition limite les organisations, les projets, les espaces de travail ou les phases d’exécution de HCP Terraform qui peuvent assumer le rôle. Sans cette clé de condition, votre politique de confiance accorde l'accès à votre rôle et à vos AWS ressources par des identités extérieures à votre organisation, ce qui n'est pas conforme au principe du moindre privilège. Si vous définissez ou modifiez une politique de confiance pour un rôle associé au fournisseur OIDC HCP Terraform dans votre AWS compte, mais que vous n'évaluez pas la clé de condition IAM`app.terraform.io:sub`, vous recevrez une erreur. De plus, AWS STS refusera les requêtes d’autorisation si votre politique d’approbation des rôles n’évalue pas cette clé de condition. 1. Les informations demandées varient en fonction du fournisseur OIDC que vous choisissez. + Saisissez l'identifiant de votre application. L'étiquette de l'identifiant varie selon le fournisseur que vous choisissez : + Si vous souhaitez créer un rôle pour Login with Amazon (Connexion avec Amazon), saisissez l'ID d'application dans le champ **Application ID** (ID d'application). + Si vous souhaitez créer un rôle pour Facebook, saisissez l'ID d'application dans le champ **Application ID** (ID d'application). + Si vous souhaitez créer un rôle pour Google, saisissez le nom du public cible dans le champ **Audience** (Public cible). + Si vous souhaitez créer un rôle pour Amazon Cognito, saisissez l'ID du groupe d'identités que vous avez créé pour vos applications Amazon Cognito dans le champ **Identity Pool ID** (ID du pool d'identités). + Si vous souhaitez créer un rôle pour GitHub Actions, entrez les informations suivantes : + Pour **Audience**, choisissez `sts.amazonaws.com`. + Pour **GitHub l'organisation**, entrez le nom de GitHub l'organisation. Le nom de GitHub l'organisation est obligatoire et doit être alphanumérique, y compris les tirets (-). Vous ne pouvez pas utiliser de caractères génériques (\$1 et ?) dans le nom GitHub de l'organisation. + (Facultatif) Pour le **GitHub référentiel**, entrez le nom du GitHub référentiel. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (`*`). + (Facultatif) Pour **GitHub la branche**, entrez le nom de la GitHub branche. Si vous ne précisez pas de valeur, la valeur par défaut devient un caractère de remplacement (`*`). + Si vous souhaitez créer un rôle pour HashiCorp Cloud Platform (HCP) Terraform, entrez les informations suivantes : + Pour **Audience**, choisissez `aws.workload.identity`. + Pour **Organisation**, saisissez le nom de l’organisation. Vous pouvez spécifier un caractère générique (`*`) pour toutes les organisations. + Pour **Projet**, saisissez le nom du projet. Vous pouvez spécifier un caractère générique (`*`) pour tous les projets. + Pour **Espace de travail**, saisissez le nom de l’espace de travail. Vous pouvez spécifier un caractère générique (`*`) pour tous les espaces de travail. + Pour **Phase d’exécution**, saisissez le nom de la phase d’exécution. Vous pouvez spécifier un caractère générique (`*`) pour toutes les phases d’exécution. 1. (Facultatif) Pour les **Conditions (facultatif)**, choisissez **Ajouter une condition** pour créer des conditions supplémentaires à réunir avant que les utilisateurs de votre application ne puissent utiliser les autorisations que le rôle accorde. Par exemple, vous pouvez ajouter une condition qui accorde l'accès aux AWS ressources uniquement pour un ID utilisateur IAM spécifique. Vous pouvez par ailleurs ajouter des conditions à la politique de confiance après la création du rôle. Pour de plus amples informations, veuillez consulter [Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md). 1. Vérifiez les informations OIDC que vous avez saisies, puis cliquez sur **Suivant**. 1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Create policy** (Créer une politique) pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer aux utilisateurs OIDC. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation. 1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée. Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). Sélectionnez la politique à utiliser comme limite d'autorisations. 1. Choisissez **Suivant**. 1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne dépendent pas de la casse. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois que vous l'avez créé. 1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle. 1. Pour modifier les cas d'utilisation et les autorisations pour le rôle, choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Select permissions** (Étape 2 : sélection d'autorisations). 1. (Facultatif) Pour ajouter des métadonnées au rôle, attachez des balises en tant que paires clé-valeur. Pour plus d'informations sur l'utilisation des balises dans IAM, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. ## Configuration d'un rôle pour le fournisseur d'identité GitHub OIDC Si vous utilisez un GitHub fournisseur d'identité (IdP) OpenID Connect (OIDC), la meilleure pratique consiste à limiter le nombre d'entités pouvant assumer le rôle associé à l'IdP IAM. Lorsque vous incluez une déclaration de condition dans la politique de confiance, vous pouvez limiter le rôle à une GitHub organisation, un référentiel ou une branche spécifique. Vous pouvez utiliser la clé de condition `token.actions.githubusercontent.com:sub` avec des opérateurs de condition de chaîne pour limiter l'accès. Nous vous recommandons de limiter cette condition à un ensemble spécifique de référentiels ou de succursales au sein de votre GitHub organisation. Pour plus d'informations sur la façon de AWS configurer GitHub l'OIDC de confiance en tant qu'identité fédérée, consultez [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services). Si vous utilisez GitHub des environnements dans des workflows d'action ou dans des politiques OIDC, nous vous recommandons vivement d'ajouter des règles de protection à l'environnement pour une sécurité accrue. Utilisez les branches et les balises de déploiement pour limiter les branches et les balises qui peuvent être déployées dans l’environnement. Pour plus d'informations sur la configuration des environnements dotés de règles de protection, consultez la section [Branches et balises GitHub de déploiement](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags) dans l'article *Utilisation des environnements pour le déploiement*. Quand GitHub l'IdP OIDC est le principal fiable pour votre rôle, IAM vérifie la condition de la politique de confiance des rôles pour vérifier que la `token.actions.githubusercontent.com:sub` clé de condition est présente et que sa valeur n'est pas uniquement un caractère générique (\$1 et ?) ou nul. IAM effectue cette vérification lors de la création ou de la mise à jour de la politique IAM. Si la clé de condition `token.actions.githubusercontent.com:sub` est absente ou la valeur clé ne répond pas aux critères de valeur mentionnés, la demande échouera et renverra une erreur. **Important** Si vous ne limitez pas la clé de condition `token.actions.githubusercontent.com:sub` à une organisation ou à un référentiel spécifique, GitHub les actions provenant d'organisations ou de référentiels indépendants de votre volonté peuvent assumer les rôles associés à l' GitHub IdP IAM dans votre compte. AWS L'exemple de politique de confiance suivant limite l'accès à l' GitHub organisation, au référentiel et à la succursale définis. La `token.actions.githubusercontent.com:sub` valeur de la clé de condition dans l'exemple suivant est le format de valeur d'objet par défaut documenté par GitHub. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch" } } } ] } ``` ------ L'exemple de condition suivant limite l'accès à l' GitHub organisation et au référentiel définis, mais accorde l'accès à n'importe quelle branche du référentiel. ``` "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*" } } ``` L'exemple de condition suivant limite l'accès à n'importe quel référentiel ou branche au sein de l' GitHub organisation définie. Nous vous recommandons de limiter la clé de condition `token.actions.githubusercontent.com:sub` à une valeur spécifique qui limite l'accès aux GitHub actions au sein de votre GitHub organisation. ``` "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*" } } ``` Pour plus d’informations sur les clés de fédération OIDC disponibles pour les contrôles de condition dans les politiques, consultez [Clés disponibles pour la AWS fédération OIDC](reference_policies_iam-condition-keys.md#condition-keys-wif). # Création d’un rôle pour la fédération SAML 2.0 (console) Vous pouvez utiliser la fédération SAML 2.0 au lieu de créer des utilisateurs IAM dans votre. Compte AWS Avec un fournisseur d'identité (IdP), vous pouvez gérer vos identités d'utilisateurs en dehors de l'extérieur AWS et leur donner les autorisations d'accéder aux AWS ressources de votre compte. Pour plus d'informations sur la fédération et les fournisseurs d'identité, consultez [Fournisseurs d'identité et fédération au sein de AWS](id_roles_providers.md). **Note** Pour améliorer la résilience de la fédération, nous vous recommandons de configurer votre IdP et votre fédération AWS pour prendre en charge plusieurs points de terminaison de connexion SAML. Pour plus de détails, consultez l'article du blog sur la AWS sécurité [Comment utiliser les points de terminaison SAML régionaux pour](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover) le basculement. ## Prérequis pour la création d'un rôle pour SAML Avant de pouvoir créer un rôle pour la fédération SAML 2.0, vous devez tout d'abord suivre les étapes requises suivantes. **Pour préparer la création d'un rôle pour la fédération SAML 2.0** 1. Avant de créer un rôle pour la fédération SAML, vous devez créer un fournisseur SAML dans IAM. Pour plus d’informations, veuillez consulter [Création d’un fournisseur d’identité SAML dans IAM](id_roles_providers_create_saml.md). 1. Préparez les politiques pour le rôle que les utilisateurs authentifiés SAML 2.0 vont endosser. Comme n'importe quel rôle, celui de la fédération SAML inclut deux politiques. L'une est la politique de confiance de rôle qui spécifie la personne capable d'endosser le rôle. L'autre est la politique d'autorisations IAM qui spécifie les AWS actions et les ressources auxquelles l'accès du principal fédéré SAML est autorisé ou refusé. Lorsque vous créez la politique de confiance pour votre rôle, vous devez utiliser trois valeurs pour vous assurer que seule votre application peut assumer le rôle : + Pour l'élément `Action`, utilisez l'action `sts:AssumeRoleWithSAML`. + Pour l'élément `Principal`, utilisez la chaîne `{"Federated":ARNofIdentityProvider}`. Remplacez `ARNofIdentityProvider` par l'ARN du [fournisseur d'identité SAML](id_roles_providers_saml.md) que vous avez créé dans [Step 1](#idpsamlstep1). + Pour l’élément `Condition`, utilisez une condition `StringEquals` pour vérifier que l’attribut `saml:aud` de la réponse SAML correspond à l’URL affichée par votre navigateur lorsque vous vous connectez à la console. Cette URL de point de terminaison de connexion correspond à l’attribut du destinataire SAML de votre fournisseur d’identité. Vous pouvez inclure la connexion URLs dans certaines régions. AWS recommande d'utiliser des points de terminaison régionaux plutôt que des points de terminaison mondiaux pour améliorer la résilience de la fédération. Pour obtenir la liste des *region-code* valeurs possibles, consultez la colonne **Région** dans les points de [terminaison de AWS connexion](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Si le chiffrement SAML est obligatoire, l’URL de connexion doit inclure l’identifiant unique qu’ AWS attribue à votre fournisseur SAML. Vous pouvez afficher l’identifiant unique en sélectionnant le fournisseur d’identité dans la console IAM afin d’afficher la page de détails. `https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID` L'exemple suivant de politique de confiance est conçu pour un utilisateur fédéré SAML : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRoleWithSAML", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME" }, "Condition": { "StringEquals": { "SAML:aud": "https://region-code.signin.aws.amazon.com/saml" } } } } ``` ------ Remplacez l'ARN principal par l'ARN réel pour le fournisseur SAML que vous avez créé dans IAM. Il utilisera votre propre ID de compte et nom du fournisseur. ## Création d'un rôle pour SAML Après avoir exécuté les étapes prérequises, vous pouvez créer le rôle pour la fédération basée sur SAML. **Pour créer un rôle pour la fédération basée sur SAML** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console IAM, sélectionnez **Roles** (Rôles), puis **Create role** (Créer un rôle). 1. Choisissez le type de rôle **Fédération SAML 2.0**. 1. Pour **Select a SAML provider** (Sélectionnez un fournisseur SAML), choisissez le fournisseur de votre rôle. 1. Choisissez la méthode de niveau d'accès SAML 2.0. + Choisissez **Autoriser l'accès par programmation uniquement** pour créer un rôle pouvant être assumé par programmation à partir de l' AWS API ou. AWS CLI + Choisissez **Autoriser la programmation et AWS Management Console l'accès** pour créer un rôle qui peut être assumé par programmation et à partir du. AWS Management Console Les rôles créés par les deux méthodes sont similaires, mais le rôle qui peut aussi être endossé depuis la console inclut une politique d'approbation contenant une condition particulière. Cette condition vérifie explicitement que l’audience SAML (l’attribut `SAML:aud`) est définie sur le point de terminaison de connexion AWS pour votre fournisseur SAML 1. La procédure de définition des attributs varie en fonction du type d’accès. + Si vous créez un rôle pour un accès par programme, choisissez un attribut dans la liste **Attribut**. Ensuite, dans le champ **Value** (Valeur), tapez une valeur à inclure dans le rôle. Cette valeur restreint l'accès au rôle aux utilisateurs du fournisseur d'identité dont la réponse d'authentification SAML (assertion) inclut les attributs que vous spécifiez. Vous devez spécifier au moins un attribut afin de garantir la limitation du rôle à un sous-ensemble d'utilisateurs de votre organisation. + Si vous créez un rôle pour la programmation et l' AWS Management Console accès, la section **Points de terminaison de connexion** définit l'URL que votre navigateur affiche lorsque vous vous connectez à la console. Ce point de terminaison est l’attribut de destinataire SAML de votre fournisseur d’identité, qui correspond à la clé de contexte [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml). Pour de plus amples informations, veuillez consulter [Configuration d’assertions SAML pour la réponse d’authentification](id_roles_providers_create_saml_assertions.md). 1. Choisissez des **points de terminaison régionaux** ou des **points de terminaison non régionaux**. Nous recommandons d’utiliser plusieurs points de terminaison de connexion SAML régionaux afin d’améliorer la résilience de la fédération. 1. Pour **les régions**, choisissez les régions prises en charge par votre fournisseur SAML pour la AWS connexion. 1. Pour que la **connexion URLs inclue des identifiants uniques, indiquez** si les points de terminaison de connexion incluent les identifiants uniques attribués à votre fournisseur d'identité AWS SAML. Cette option est requise pour les assertions SAML chiffrées. Pour de plus amples informations, veuillez consulter [Fédération SAML 2.0](id_roles_providers_saml.md). 1. Pour ajouter d'autres conditions liées aux attributs à la politique d'approbation, choisissez **Condition (optional)** (Conditions [facultatif]), sélectionnez la condition supplémentaire et spécifiez une valeur. **Note** La liste inclut les attributs SAML les plus couramment utilisés. IAM prend en charge des attributs supplémentaires que vous pouvez utiliser pour créer des conditions. Pour obtenir la liste des attributs pris en charge, veuillez consulter [Clés disponibles pour la fédération SAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml). Si vous avez besoin d'une condition pour un attribut SAML pris en charge ne figurant pas dans la liste, vous pouvez ajouter cette condition manuellement. Pour ce faire, modifiez la politique de confiance après la création du rôle. 1. Passez en revue les informations d'approbation SAML 2.0, puis choisissez **Next: Permissions** (Suivant : Autorisations). 1. IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser pour la politique d'autorisations ou choisissez **Create policy** (Créer une politique) pour ouvrir un nouvel onglet de navigateur et créer une nouvelle politique de bout en bout. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Une fois la politique créée, fermez cet onglet et revenez à l'onglet initial. Cochez la case en regard des politiques d’autorisations que vous souhaitez octroyer aux utilisateurs fédérés SAML. Si vous préférez, vous pouvez ne sélectionner aucune stratégie pour le moment, puis les attacher au rôle ultérieurement. Par défaut, un rôle ne dispose d'aucune autorisation. 1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée. Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). Sélectionnez la politique à utiliser comme limite d'autorisations. 1. Choisissez **Suivant**. 1. Choisissez **Suivant : Vérification**. 1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois celui-ci créé. 1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle. 1. Choisissez **Edit** (Modifier) dans les sections **Step 1: Select trusted entities** (Étape 1 : sélection d'entités de confiance) ou **Step 2: Add permissions** (Étape 2 : ajouter des autorisations) pour modifier les cas d'utilisation et les autorisations pour le rôle. 1. (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 [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. Après avoir créé le rôle, vous devez finaliser la relation d'approbation SAML en configurant le logiciel de votre fournisseur d'identité à l'aide d'informations sur AWS. Ces informations incluent les rôles que vous souhaitez que vos utilisateurs fédérés SAML utilisent. Il s'agit de la configuration de la relation d'approbation des parties utilisatrices entre votre fournisseur d'identité et AWS. Pour de plus amples informations, veuillez consulter [Configuration de votre IdP SAML 2.0 à l’aide d’une relation d’approbation des parties utilisatrices et ajout de demandes](id_roles_providers_create_saml_relying-party.md). # Création d’un rôle à l’aide de politiques d’approbation personnalisées Vous pouvez créer une politique de confiance personnalisée pour déléguer l'accès et permettre à d'autres personnes d'effectuer des actions dans votre Compte AWS. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). Pour plus d'informations sur la façon d'utiliser les rôles pour déléguer des autorisations, consultez [Termes et concepts relatifs aux rôles](id_roles.md#id_roles_terms-and-concepts). ## Création d'un rôle IAM à l'aide d'une politique d'approbation personnalisée (console) Vous pouvez utiliser le AWS Management Console pour créer un rôle qu'un utilisateur IAM peut assumer. Supposons, par exemple, que votre organisation en dispose Comptes AWS de plusieurs pour isoler un environnement de développement d'un environnement de production. Pour des informations générales sur la création d'un rôle autorisant les utilisateurs du compte de développement à accéder aux ressources du compte de production, consultez [Exemple de scénario utilisant des comptes de développement et de production distincts](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example). **Pour créer un rôle à l'aide d'une politique d'approbation personnalisée (console)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console, choisissez **Rôles**, puis **Créer un rôle**. 1. Choisissez le type de rôle **Custom trust policy** (Politique d'approbation personnalisée). 1. Dans la section **Custom trust policy** (Politique d'approbation personnalisée), saisissez ou collez la politique d'approbation personnalisée pour le rôle. Pour de plus amples informations, veuillez consulter [Création de politiques IAM](access_policies_create-console.md#access_policies_create-start). 1. 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](access_policies_policy-validator.md), puis choisissez **Next** (Suivant). 1. (Facultatif) Définissez une [limite d'autorisations](access_policies_boundaries.md). Il s’agit d’une fonctionnalité avancée disponible pour les fonctions de service, mais pas pour les rôles liés à un service. Ouvrez la section **Set permissions boundary** (Définir une limite d'autorisations) et choisissez **Use a permissions boundary to control the maximum role permissions** (Utiliser une limite d'autorisations pour contrôler le nombre maximum d'autorisations de rôle). IAM inclut une liste des politiques AWS gérées et gérées par le client dans votre compte. Sélectionnez la politique à utiliser comme limite d'autorisations. 1. Choisissez **Suivant**. 1. Pour **Nom du rôle**, le degré de la personnalisation du nom du rôle est défini par le service. Si le service définit le nom du rôle, cette option n'est pas modifiable. Dans d'autres cas, le service peut définir un préfixe pour le rôle ou vous permettre de saisir un suffixe facultatif. Certains services vous permettent de spécifier le nom complet de votre rôle. Si possible, saisissez un nom de rôle ou un suffixe de nom de rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Dans la mesure AWS où d'autres ressources peuvent faire référence au rôle, vous ne pouvez pas modifier le nom du rôle une fois celui-ci créé. 1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle. 1. (Facultatif) Choisissez **Modifier** dans les sections **Étape 1 : sélection d’entités de confiance** ou **Étape 2 : Ajouter des autorisations** pour modifier la politique et les autorisations personnalisées pour le rôle. 1. (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 [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. # Exemples de politiques pour la délégation d'accès Les exemples suivants montrent comment vous pouvez autoriser ou accorder l' Compte AWS accès aux ressources d'un autre Compte AWS. Pour apprendre à créer une politique IAM à l'aide de ces exemples de document de politique JSON, consultez [Création de politiques à l'aide de l'éditeur JSON](access_policies_create-console.md#access_policies_create-json-editor). **Topics** + [Utiliser des rôles pour déléguer l'accès aux ressources d'une autre Compte AWS ressource](#example-delegate-xaccount-rolesapi) + [Utilisation d'une politique pour la délégation d'accès à des services](#id_roles_create_policy-examples-access-to-services) + [Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à un compartiment Amazon S3 dans un autre compte](#example-delegate-xaccount-S3) + [Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à une file d'attente Amazon SQS dans un autre compte](#example-delegate-xaccount-SQS) + [Délégation d'accès impossible lorsque l'accès est refusé au compte](#example-delegate-xaccount-SQS-denied) ## Utiliser des rôles pour déléguer l'accès aux ressources d'une autre Compte AWS ressource Pour un didacticiel expliquant comment utiliser les rôles IAM pour accorder aux utilisateurs d'un compte l'accès aux AWS ressources d'un autre compte, voir[Tutoriel IAM : déléguer l'accès entre AWS comptes à l'aide de rôles IAM](tutorial_cross-account-with-roles.md). **Important** Vous pouvez inclure l'ARN d'un rôle ou d'un utilisateur dans l'élément `Principal` de la politique d'approbation d'un rôle. Lorsque vous enregistrez la politique, AWS transforme l'ARN en un identifiant principal unique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création du rôle ou de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN, lorsque la politique d'approbation est affichée. Cependant, si vous supprimez le rôle ou l'utilisateur, la relation est interrompue. La politique ne s'applique plus, même si vous recréez l'utilisateur ou le rôle, étant donné qu'il ne correspond pas à l'ID du principal stocké dans la politique d'approbation. Lorsque cela se produit, l'ID principal apparaît dans la console car il n'est plus AWS possible de le mapper à un ARN. Le résultat final est que si vous supprimez et recréez un utilisateur ou un rôle référencé dans l'élément `Principal` d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ARN. Il deviendra le nouvel ID du principal lorsque vous enregistrez la politique. ## Utilisation d'une politique pour la délégation d'accès à des services L'exemple suivant illustre une politique qui est peut être attachée à un rôle. La politique permet à deux services, Amazon EMR et Amazon AWS Data Pipeline, d'assumer ce rôle. Les services peuvent ensuite effectuer toutes les tâches autorisées par la politique d'autorisation affectée au rôle (non illustré). Pour définir plusieurs principaux de service, vous ne spécifiez pas deux éléments `Service` ; vous ne devez en avoir qu'un seul. À la place, vous utilisez un tableau de plusieurs principaux de service comme valeur d'un élément `Service` unique. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "elasticmapreduce.amazonaws.com", "datapipeline.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ ## Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à un compartiment Amazon S3 dans un autre compte Dans cet exemple, le compte A utilise une politique basée sur les ressources (une [politique de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html) Amazon S3) pour octroyer au compte B l'accès complet au compartiment S3 du compte A. Ensuite, le compte B crée une politique d'utilisateur IAM pour déléguer l'accès au compartiment du compte A à l'un des utilisateurs du compte B. La politique de compartiment S3 du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé *amzn-s3-demo-bucket*, et le numéro de compte du compte B est 111122223333. Il ne spécifie pas d'utilisateurs ou de groupes dans le compte B, simplement le compte proprement dit. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "AccountBAccess1", "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } } ``` ------ Le compte A peut également utiliser les [listes de contrôle d'accès Amazon S3 (ACLs)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) pour accorder au compte B l'accès à un compartiment S3 ou à un seul objet au sein d'un compartiment. Dans ce cas, seule change la façon dont le compte A accorde l'accès au compte B. Le compte B utilise toujours une politique pour déléguer l'accès à un groupe IAM dans le compte B, comme décrit dans la dernière partie de cet exemple. Pour plus d’informations sur le contrôle de l'accès aux compartiments et aux objets S3, veuillez consulter [contrôle des accès](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html) dans le *guide de l'utilisateur du service de stockage simple Amazon*. L'administrateur du compte B peut créer l'exemple de politique suivant. La politique donne un accès en lecture à un groupe ou à un utilisateur au sein du compte B. La politique précédente accorde l'accès au compte B. Toutefois, des groupes et des utilisateurs spécifiques au sein du compte B ne peuvent pas accéder à la ressource tant qu'une politique de groupe ou d'utilisateur ne leur accorde pas explicitement des autorisations pour cette ressource. Les autorisations de cette politique peuvent uniquement être un sous-ensemble de celles de la politique intercompte précédente. Le compte B ne peut pas accorder plus d'autorisations à ses utilisateurs et groupes que le compte A ne lui a accordé dans la première politique. Dans cette politique, l'élément `Action` est défini explicitement pour autoriser uniquement les actions `List`, tandis que l'élément `Resource` de cette politique correspond à l'élément `Resource` pour la politique de compartiment implémentée par le compte A. Pour implémenter cette politique, le compte B utilise IAM pour l'attacher à l'utilisateur (ou au groupe) approprié dans le compte B. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "s3:List*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } } ``` ------ ## Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à une file d'attente Amazon SQS dans un autre compte Dans l'exemple suivant, le compte A est doté d'une file d'attente Amazon SQS qui utilise une politique basée sur les ressources attachée à celle-ci pour accorder au compte B l'accès à la file d'attente. Le compte B utilise ensuite une politique de groupe IAM pour déléguer l'accès à un groupe du compte B. L'exemple de politique de file d'attente suivant accorde au compte B l'autorisation d'effectuer les actions `SendMessage` et `ReceiveMessage` dans la file d'attente du compte A nommée *queue1*, mais uniquement entre midi et 15 heures le 30 novembre 2014. Le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon SQS pour implémenter cette politique. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "111122223333"}, "Action": [ "sqs:SendMessage", "sqs:ReceiveMessage" ], "Resource": ["arn:aws:sqs:*:123456789012:queue1"], "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"}, "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"} } } } ``` ------ La politique du compte B pour la délégation d'accès à un groupe dans le compte B peut se présenter comme l'exemple suivant. Le compte B utilise IAM pour attacher cette politique à un groupe (ou utilisateur). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sqs:*", "Resource": "arn:aws:sqs:*:123456789012:queue1" } } ``` ------ Dans l'exemple de politique utilisateur IAM précédent, le compte B utilise un caractère générique pour accorder à son utilisateur l'accès à toutes les actions Amazon SQS dans la file d'attente du compte A. Cependant, le compte B peut déléguer l'accès dans la mesure où celui-ci lui a été accordé. Le groupe du compte B qui a une seconde politique peut accéder à la file d'attente uniquement entre midi et 15 heures le 30 novembre 2014. L'utilisateur peut uniquement effectuer les actions `SendMessage` et `ReceiveMessage`, tel que défini dans la politique de file d'attente Amazon SQS du compte A. ## Délégation d'accès impossible lorsque l'accès est refusé au compte Compte AWS On ne peut pas déléguer l'accès aux ressources d'un autre compte si celui-ci a explicitement refusé l'accès au compte parent de l'utilisateur. Le rejet se propage aux utilisateurs sous ce compte, qu'ils aient ou non des politiques existantes leur accordant l'accès. Par exemple, le compte A crée une politique de compartiment pour son compartiment S3 qui refuse explicitement au compte B l'accès à ce compartiment. Mais le compte B crée une politique d'utilisateur IAM qui accorde à un utilisateur du compte B l'accès au compartiment du compte A. Le refus explicite appliqué au compartiment S3 du compte A est propagé aux utilisateurs du compte B. Il remplace la politique d'utilisateur IAM qui accorde l'accès aux utilisateurs du compte B. (Pour des informations détaillées sur la façon dont les autorisations sont évaluées, consultez [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).) La politique de compartiment du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé *amzn-s3-demo-bucket*, et le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon S3 pour implémenter cette politique. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "AccountBDeny", "Effect": "Deny", "Principal": {"AWS": "111122223333"}, "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } } ``` ------ Ce refus explicite remplace toutes les politiques au sein du compte B qui accordent l'accès au compartiment S3 du compte A. # Gestion des rôles IAM Avant qu’un utilisateur, une application ou un service soit en mesure d’utiliser un rôle que vous avez créé, vous devez lui accorder les autorisations nécessaires pour changer de rôle. Pour accorder ces autorisations, vous pouvez utiliser n’importe quelle politique attachée à l’un des groupes ou des utilisateurs. Cette section décrit l'octroi d'autorisations aux utilisateurs pour utiliser un rôle. Il explique également comment l'utilisateur peut passer d'un rôle à un autre dans les Outils pour Windows PowerShell, le AWS Command Line Interface (AWS CLI) et l'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API. AWS Management Console **Important** Si vous créez un rôle par programmation plutôt que dans la console IAM, vous avez la possibilité d'ajouter un chemin `Path` de 512 caractères au maximum à l'élément `RoleName` qui lui, est de 64 caractères au maximum. Toutefois, si vous avez l'intention d'utiliser un rôle avec la fonctionnalité **Switch** Role dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères. **Topics** + [Afficher l'accès au rôle](#roles-modify_prerequisites) + [Générer une politique sur la base d'informations d'accès](#roles-modify_gen-policy) + [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md) + [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md) + [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md) + [Mise à jour d’un rôle lié à un service](id_roles_update-service-linked-role.md) + [Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md) + [Mettre à jour les autorisations pour un rôle](id_roles_update-role-permissions.md) + [Mise à jour des paramètres pour un rôle](id_roles_update-role-settings.md) + [Suppression de rôles ou de profils d’instance](id_roles_manage_delete.md) ## Afficher l'accès au rôle Avant de modifier les autorisations d'un rôle, vous devez passer en revue ses activités récentes au niveau service. Ceci est important, car vous ne souhaitez pas supprimer l'accès à partir d'un principal (personne ou application) qui l'utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md). ## Générer une politique sur la base d'informations d'accès Vous pouvez parfois octroyer plus d'autorisations à une entité IAM (utilisateur ou rôle) qu'elle n'en a besoin. Pour affiner les autorisations que vous octroyez, vous pouvez générer une politique IAM basée sur l'activité d'accès d'une entité. IAM Access Analyzer examine vos AWS CloudTrail journaux et génère un modèle de politique contenant les autorisations qui ont été utilisées par l'entité dans la plage de dates que vous avez spécifiée. Vous pouvez utiliser le modèle pour créer une politique gérée avec des autorisations affinées, puis l'attacher à l'entité IAM. Ainsi, vous accordez uniquement les autorisations dont l'utilisateur ou le rôle a besoin pour interagir avec les AWS ressources correspondant à votre cas d'utilisation spécifique. Pour en savoir plus, consultez [Génération d’une politique de l’analyseur d’accès IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html). # Octroi d’autorisations à un utilisateur pour endosser un rôle Lorsqu'un administrateur [crée un rôle pour un accès intercompte](id_roles_create_for-user.md), il établit une relation d'approbation entre le compte propriétaire du rôle et des ressources (compte d'approbation) et le compte qui contient les utilisateurs (compte approuvé). Pour cela, l'administrateur du compte d'approbation spécifie le numéro du compte approuvé en tant que `Principal` dans la politique d'approbation du rôle. Cela permet *potentiellement* à n'importe quel utilisateur du compte approuvé d'endosser le rôle. Pour achever la configuration, l'administrateur du compte approuvé doit accorder l'autorisation d'endosser ce rôle à des groupes ou utilisateurs spécifiques du compte. **Pour accorder l'autorisation de passer à un rôle** 1. En tant qu'administrateur du compte approuvé, créez une nouvelle politique pour l'utilisateur ou modifiez une politique existante pour y ajouter les éléments requis. Pour en savoir plus, consultez [Création ou modification de la politique](#roles-usingrole-createpolicy). 1. Choisissez ensuite la manière dont vous souhaitez partager les informations du rôle : + **Lien du rôle :** envoyez aux utilisateurs un lien qui les dirige vers la page **Switch Role** (Changer de rôle) dans laquelle tous les détails sont déjà remplis. + **ID ou alias du compte :** donnez à chaque utilisateur le nom du rôle ainsi que l'ID ou l'alias du compte. L'utilisateur accède ensuite à la page **Switch Role (Changer de rôle)** et ajoute les détails manuellement. Pour en savoir plus, consultez [Fourniture d'informations à l'utilisateur](#roles-usingrole-giveuser). Notez que vous ne pouvez changer de rôle que lorsque vous vous connectez en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité Web. Vous ne pouvez pas changer de rôle lorsque vous vous connectez en tant qu' Utilisateur racine d'un compte AWS. **Important** Vous ne pouvez pas changer AWS Management Console de rôle dans un rôle nécessitant une [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)valeur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) qui prend en charge le paramètre `ExternalId`. **Remarques** Cette rubrique décrit les politiques applicables aux *utilisateurs* car, en fin de compte, il s'agit ici d'accorder à un utilisateur les autorisations nécessaires pour effectuer une tâche. Cependant, nous vous déconseillons d'octroyer des autorisations directement à un utilisateur individuel. Lorsqu'un utilisateur assume un rôle, il reçoit également les autorisations associées. Lorsque vous changez de rôle dans le AWS Management Console, la console utilise toujours vos informations d'identification d'origine pour autoriser le changement. Cela s'applique que vous soyez connecté en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité web. Par exemple, si vous basculez sur RoleA, IAM utilise les informations d'identification du compte utilisateur ou du rôle fédéré d'origine pour déterminer si vous êtes autorisé à assumer le rôle RoleA. Si vous essayez ensuite de basculer sur RoleB *pendant que vous utilisez RoleA*, vos informations d'identification d'utilisateur ou du rôle fédéré **d'origine** sont utilisées pour autoriser votre tentative. Les informations d'identification de RoleA (Rôle A) ne sont pas utilisées pour cette action. **Topics** + [Création ou modification de la politique](#roles-usingrole-createpolicy) + [Fourniture d'informations à l'utilisateur](#roles-usingrole-giveuser) ## Création ou modification de la politique Une politique qui accorde à un utilisateur l'autorisation d'endosser un rôle doit inclure une instruction avec l'effet `Allow` sur les éléments suivants : + L'action `sts:AssumeRole` + L'Amazon Resource Name (ARN) du rôle dans un élément `Resource` Les utilisateurs bénéficiant de la politique sont autorisés à endosser les rôles figurant sur la ressource (via l'appartenance à un groupe ou directement). **Note** Si `Resource` est définie sur `*`, l'utilisateur peut endosser n'importe quel rôle dans n'importe quel compte faisant confiance au compte de l'utilisateur. (En d'autres termes, la politique de confiance du rôle spécifie le compte de l'utilisateur en tant que `Principal`). La bonne pratique consiste à appliquer le [principe du moindre privilège](http://en.wikipedia.org/wiki/Principle_of_least_privilege) et à spécifier l'ARN complet uniquement pour les rôles dont l'utilisateur a besoin. L'exemple suivant illustre une politique qui permet à l'utilisateur d'endosser des rôles dans un seul compte. En outre, la politique utilise un caractère générique (\$1) pour spécifier que l'utilisateur ne peut passer à un rôle que si le nom du rôle commence par les lettres `Test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/Test*" } } ``` ------ **Note** Les autorisations que le rôle octroie à l'utilisateur ne viennent pas s'ajouter aux autorisations dont il dispose déjà. Lorsqu'un utilisateur endosse un rôle, il abandonne temporairement ses autorisations d'origine, de manière à adopter celles accordées par le rôle. Lorsqu'il quitte le rôle, ses autorisations d'origine sont automatiquement restaurées. Par exemple, supposons que les autorisations de l'utilisateur lui permettent d'utiliser des instances Amazon EC2, mais que la politique des autorisations du rôle n'accorde pas ces autorisations. Dans ce cas, lorsque vous utilisez le rôle, l'utilisateur peut ne pas utiliser les instances Amazon EC2 dans la console. En outre, les informations d'identification temporaires obtenues via `AssumeRole` ne fonctionnent pas par programmation avec les instances Amazon EC2. ## Fourniture d'informations à l'utilisateur Une fois que vous avez créé un rôle et accordé à l'utilisateur les autorisations requises pour l'endosser, vous devez également fournir à l'utilisateur les éléments suivants : + Nom du rôle + ID ou alias du compte qui contient le rôle Pour faciliter l'accès aux utilisateurs, vous pouvez leur envoyer un lien préconfiguré contenant l'ID du compte et le nom du rôle. Vous pouvez voir le lien du rôle après avoir terminé l'assistant **Créer un rôle** en sélectionnant la bannière **Afficher le rôle** ou sur la page **Résumé du rôle** pour n'importe quel rôle inter-comptes. Vous pouvez également utiliser le format suivant pour créer le lien manuellement. Remplacez les deux paramètres de l'exemple suivant par l'ID ou l'alias de votre compte et le nom du rôle. `https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name` Nous vous recommandons de diriger vos utilisateurs vers la rubrique [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md) pour les guider à travers le processus. Pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous endossez un rôle, consultez [Je ne parviens pas à endosser un rôle](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role). **Considérations** + Si vous créez le rôle par programmation, vous pouvez définir un chemin et un nom. Dans ce cas, vous devez fournir le chemin complet et le nom du rôle à vos utilisateurs afin qu'ils les saisissent sur la page **Switch Role** (Changer de rôle) de la AWS Management Console. Par exemple : `division_abc/subdivision_efg/role_XYZ`. + Si vous créez le rôle par programmation, vous pouvez ajouter un `Path` de 512 caractères au maximum , ainsi qu'un `RoleName`. Le nom du rôle peut comporter jusqu'à 64 caractères. Toutefois, pour utiliser un rôle avec la fonctionnalité **Switch Role** dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères. + Pour des raisons de sécurité, vous pouvez [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Vous pouvez utiliser la clé de condition `sts:SourceIdentity` dans la politique d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient une identité lorsqu'ils endossent un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme identité de source. Cela peut vous aider à déterminer quel utilisateur a effectué une action spécifique dans AWS. Pour de plus amples informations, veuillez consulter [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity). Vous pouvez utiliser [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname) pour exiger des utilisateurs qu'ils spécifient un nom de session lorsqu'ils endossent un rôle. Cela peut vous aider à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux. # Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service Pour configurer de nombreux AWS services, vous devez leur *transmettre* un rôle IAM. Cela autorise le service à assumer ultérieurement le rôle et à effectuer des actions en votre nom. Pour la plupart des services, il vous suffit de transférer le rôle au service une fois au cours de la configuration, et non chaque fois que le service assume le rôle. Par exemple, supposons que vous avez une application s'exécutant sur une instance Amazon EC2. Cette application a besoin d'informations d'identification temporaires pour l'authentification et d'autorisations pour autoriser l'application à exécuter des actions dans AWS. Lorsque vous configurez l'application, vous devez transmettre un rôle à Amazon EC2 à utiliser avec l'instance qui fournit ces informations d'identification. Vous définissez les autorisations pour les applications s'exécutant sur l'instance en attachant une politique IAM au rôle. L'application endosse le rôle chaque fois qu'elle doit effectuer les actions qui sont autorisées par le rôle. Pour transmettre un rôle (et ses autorisations) à un AWS service, un utilisateur doit disposer des autorisations nécessaires pour *transmettre le rôle* au service. Cela permet aux administrateurs de s'assurer que seuls les utilisateurs autorisés peuvent configurer un service avec un rôle qui accorde des autorisations. Pour permettre à un utilisateur de transmettre un rôle à un AWS service, vous devez accorder l'`PassRole`autorisation à l'utilisateur, au rôle ou au groupe IAM de l'utilisateur. **Avertissement** Vous ne pouvez utiliser cette `PassRole` autorisation que pour transmettre un rôle IAM à un service qui partage le même AWS compte. Pour transmettre un rôle du compte A à un service du compte B, vous devez d'abord créer un rôle IAM dans le compte B qui peut assumer le rôle du compte A, puis le rôle du compte B peut être transmis au service. Pour en savoir plus, consultez [Accès intercompte aux ressources dans IAM](access_policies-cross-account-resource-access.md). N'essayez pas de contrôler les personnes susceptibles de faire passer un rôle en étiquetant ce rôle, puis en utilisant la clé de condition `ResourceTag` dans une politique avec l'action `iam:PassRole`. Cette approche ne produit pas des résultats fiables. Lors de la définition de l’autorisation `PassRole`, vous devez vous assurer qu’un utilisateur ne transfère pas un rôle ayant plus d’autorisations que ce que vous souhaitez pour l’utilisateur. Par exemple, Alice n’est peut-être pas autorisée à effectuer des actions Amazon S3. Si Alice pouvait transmettre un rôle à un service autorisant les actions Amazon S3, le service pourrait effectuer des actions Amazon S3 pour le compte d’Alice lors de l’exécution de la tâche. Lorsque vous spécifiez un rôle lié à un service, vous devez également posséder l'autorisation de transmettre ce rôle au service. Certains services créent automatiquement un rôle lié à un service dans votre compte lorsque vous effectuez une action dans ce service. Par exemple, Amazon EC2 Auto Scaling crée automatiquement le rôle lié au service `AWSServiceRoleForAutoScaling` la première fois que vous créez un groupe Auto Scaling. Si vous essayez de spécifier le rôle lié au service lorsque vous créez un groupe Auto Scaling sans l'autorisation `iam:PassRole`, vous recevez une erreur. Si vous ne spécifiez pas explicitement le rôle, l'autorisation `iam:PassRole` n'est pas requise et la valeur par défaut est d'utiliser le rôle `AWSServiceRoleForAutoScaling` pour toutes les opérations effectuées sur ce groupe. Pour savoir quels services prennent en charge les rôles liés à un service, veuillez consulter [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md). Pour savoir quels services créent automatiquement un rôle lié à un service lorsque vous effectuez une action dans ce service, choisissez le lien **Oui** et consultez la documentation relative au rôle lié à un service pour le service. Un utilisateur peut transmettre un ARN de rôle comme paramètre dans n'importe quelle opération d'API qui utilise le rôle pour attribuer des autorisations au service. Le service vérifie ensuite si cet utilisateur dispose de l'autorisation `iam:PassRole`. Pour que l'utilisateur transfère uniquement les rôles approuvés, vous pouvez filtrer l'autorisation `iam:PassRole` à l'aide de l'élément `Resources` de l'instruction de politique IAM. Vous pouvez utiliser `Condition` cet élément dans une politique JSON pour tester la valeur des clés incluses dans le contexte de toutes les AWS demandes. Pour en savoir plus sur l'utilisation des clés de condition dans une politique, consultez la section [Éléments de politique JSON IAM : Condition](reference_policies_elements_condition.md). La clé de condition `iam:PassedToService` peut être utilisée pour spécifier le principal de service du service auquel un rôle peut être transmis. Pour en savoir plus sur l'utilisation de la clé de `iam:PassedToService` condition dans une politique, consultez [iam : PassedToService](reference_policies_iam-condition-keys.md#ck_PassedToService). **Exemple 1** Supposons que vous vouliez accorder à un utilisateur la possibilité de transférer l'un des ensembles de rôles approuvés au service Amazon EC2 lors du lancement d'une instance. Vous avez besoin de trois éléments : + Une *politique d'autorisations* IAM attachée au rôle qui détermine les opérations pouvant être exécutées par le rôle. Limitez les autorisations aux seules actions nécessaires pour le rôle et aux seules ressources dont le rôle a besoin pour exécuter ces actions. Vous pouvez utiliser une politique d' AWS autorisations IAM gérée ou créée par le client. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "A list of the permissions the role is allowed to use" ], "Resource": [ "A list of the resources the role is allowed to access" ] } } ``` ------ + Une* politique d'approbation* pour le rôle, qui permet au service d'endosser le rôle. Par exemple, vous pourriez attacher la politique d'approbation suivante au rôle avec l'action `UpdateAssumeRolePolicy`. Cette politique d'approbation permet à Amazon EC2 d'utiliser le rôle et les autorisations attachées au rôle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } } ``` ------ + Une *politique d'autorisations* IAM attachée à l'utilisateur IAM, qui permet à l'utilisateur de transférer uniquement les rôles qui sont approuvés. Vous ajoutez généralement `iam:GetRole` à `iam:PassRole` pour que l'utilisateur puisse obtenir les détails du rôle à transférer. Dans cet exemple, l'utilisateur peut transférer uniquement les rôles qui existent dans le compte spécifié avec des noms commençant par l'interface `EC2-roles-for-XYZ-` : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::111122223333:role/EC2-roles-for-XYZ-*" } ] } ``` ------ L'utilisateur peut maintenant démarrer une instance Amazon EC2 avec un rôle affecté. Les applications qui s'exécutent sur l'instance peuvent accéder à des informations d'identification temporaires pour le rôle via les métadonnées du profil d'instance. Les politiques d'autorisations attachées au rôle déterminent ce que peut faire l'instance. **Exemple 2** Amazon Relational Database Service (Amazon RDS) prend en charge une fonction appelée **surveillance améliorée**. Cette fonctionnalité permet à Amazon RDS de surveiller une instance de base de données grâce à un agent. Cela permet également à Amazon RDS d'enregistrer les métriques dans Amazon CloudWatch Logs. Pour activer cette fonctionnalité, vous devez créer un rôle de service pour accorder à Amazon RDS des autorisations pour surveiller et écrire des métriques dans vos journaux. **Pour créer un rôle pour la surveillance améliorée Amazon RDS** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Cliquez sur **Rôles**, puis sur **Créer un rôle**. 1. Choisissez le type **AWS de rôle de service**, puis pour **Cas d'utilisation pour les autres Services AWS**, choisissez le service **RDS.** Choisissez **RDS - Enhanced Monitoring** (RDS - Surveillance améliorée), puis **Next** (Suivant). 1. Choisissez la politique **d'RDSEnhancedMonitoringRoleautorisation d'Amazon**. 1. Choisissez **Suivant**. 1. Pour **Role name** (Nom du rôle), saisissez un nom de rôle vous permettant d'identifier le but de ce rôle. Les noms de rôles doivent être uniques au sein de votre Compte AWS. Lorsqu'un nom de rôle est utilisé dans une politique ou dans le cadre d'un ARN, il est sensible à la casse. Lorsque le nom d'un rôle apparaît aux clients dans la console, par exemple lors du processus de connexion, il n'est pas sensible à la casse. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création. 1. (Facultatif) Pour **Description**, saisissez une description pour le nouveau rôle. 1. (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, veuillez consulter [Tags pour les Gestion des identités et des accès AWS ressources](id_tags.md). 1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**. Le rôle obtient automatiquement une politique d'approbation qui accorde au service `monitoring.rds.amazonaws.com` les autorisations nécessaires pour endosser le rôle. Une fois cette opération effectuée, Amazon RDS peut exécuter toutes les actions que la politique `AmazonRDSEnhancedMonitoringRole` autorise. L'utilisateur pour lequel vous souhaitez activer la surveillance améliorée a besoin d'une politique incluant une instruction lui permettant de lister les fonctions RDS et une autre lui prermettant de transférer la fonction comme suit. Utilisez votre numéro de compte et remplacez le nom du rôle par le nom fourni à l'étape 6. ``` { "Sid": "PolicyStatementToAllowUserToListRoles", "Effect": "Allow", "Action": ["iam:ListRoles"], "Resource": "*" }, { "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::account-id:role/RDS-Monitoring-Role" } ``` Vous pouvez combiner cette instruction avec des instructions d'une autre politique ou la placer dans sa propre politique. Au lieu de spécifier que l'utilisateur peut transférer un rôle commençant par `RDS-`, vous pouvez remplacer le nom du rôle dans l'ARN d'une ressource par un caractère générique, comme suit. ``` "Resource": "arn:aws:iam::account-id:role/RDS-*" ``` ## `iam:PassRole`actions dans les AWS CloudTrail journaux `PassRole`n'est pas un appel d'API. `PassRole`est une autorisation, ce qui signifie qu'aucun CloudTrail journal n'est généré pour IAM`PassRole`. Pour vérifier quels rôles sont transférés Services AWS à qui CloudTrail, vous devez consulter le CloudTrail journal qui a créé ou modifié la AWS ressource recevant le rôle. Par exemple, un rôle est transmis à une AWS Lambda fonction lors de sa création. le journal répertoriant l'action `CreateFunction` affichera l'enregistrement du rôle qui a été transmis à la fonction. # Révocation des informations d’identification de sécurité temporaires d’un rôle IAM **Avertissement** Si vous suivez les étapes indiquées sur cette page, tous les utilisateurs dont les sessions ont été créées en assumant le rôle se voient refuser l'accès à toutes les AWS actions et ressources. Cela peut entraîner le risque pour les utilisateurs de perdre leur travail non sauvegardé. Lorsque vous autorisez les utilisateurs à accéder AWS Management Console à une session de longue durée (12 heures, par exemple), leurs informations d'identification temporaires n'expirent pas aussi rapidement. Si les utilisateurs exposent par inadvertance leurs informations d'identification à un tiers non autorisé, celui-ci dispose d'un accès pendant la durée de la session. Cependant, vous pouvez révoquer immédiatement toutes les autorisations aux informations d'identification du rôle émises avant un moment donné, si nécessaire. Toutes les informations d'identification temporaires pour ce rôle qui ont été émises avant le moment spécifié deviennent non valides. Cela force tous les utilisateurs à s'authentifier de nouveau et demande de nouvelles informations d'identification. **Note** Vous ne pouvez pas révoquer la session d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)*. Lorsque vous révoquez des autorisations pour un rôle à l'aide de la procédure décrite dans cette rubrique, AWS vous associez une nouvelle politique intégrée au rôle qui refuse toutes les autorisations pour toutes les actions. Il inclut une condition qui applique les restrictions uniquement si l'utilisateur a endossé le rôle *avant* le moment où vous avez révoqué les autorisations. Si l'utilisateur endosse le rôle *après* la révocation des autorisations, la politique de rejet ne s'applique pas à cet utilisateur. Pour plus d'informations sur le refus d'accès, veuillez consulter la rubrique [Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires](id_credentials_temp_control-access_disable-perms.md). **Important** Cette politique de rejet s'applique à tous les utilisateurs du rôle spécifié, pas seulement à ceux dont les sessions de console durent plus longtemps. ## Autorisations minimales pour révoquer les autorisations de session d'un rôle Pour révoquer les autorisations de session d'un rôle avec succès, vous devez disposer de l'autorisation `PutRolePolicy` pour ce rôle. Cela vous permet d'attacher la politique en ligne `AWSRevokeOlderSessions` au rôle. ## Révocation des autorisations de session Vous pouvez révoquer les autorisations de session d’un rôle afin de refuser toutes les autorisations à tout utilisateur qui a endossé le rôle. **Note** Vous ne pouvez pas modifier les rôles qui ont été créés dans IAM à partir des jeux de permissions d’IAM IAM Identity Center. Vous devez révoquer la session d’ensemble d’autorisations active pour un utilisateur dans IAM Identity Center. Pour plus d’informations, consultez [Révocation des sessions de rôle IAM actives créées par des ensembles d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) dans le *Guide de l’utilisateur d’IAM Identity Center*. **Pour refuser immédiatement toutes autorisations à tout utilisateur actuel des informations d'identification du rôle** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation, sélectionnez **Rôles**, puis le nom (pas la case à cocher) du rôle dont vous voulez révoquer les autorisations. 1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l'onglet **Révoquer les sessions**. 1. Dans l'onglet **Révoquer les sessions**, choisissez **Révoquer les sessions actives**. 1. AWS vous demande de confirmer l'action. Cochez la case **Je reconnais que je révoque toutes les sessions actives pour ce rôle.** et choisissez **Révoquer les sessions actives** dans la boîte de dialogue. IAM attache ensuite une politique nommée `AWSRevokeOlderSessions` au rôle. Après avoir sélectionné **Révoquer les sessions actives**, la politique refuse tout accès aux utilisateurs qui ont assumé le rôle dans le passé ainsi qu’environ 30 secondes dans le futur. Ce choix du temps futur tient compte du délai de propagation de la politique afin de traiter une nouvelle session acquise ou renouvelée avant que la politique mise à jour ne soit en vigueur dans une région donnée. Tout utilisateur qui endosse le rôle plus de 30 secondes environ après que vous avez choisi Révoquer les sessions actives n’est pas affecté. Pour savoir pourquoi les modifications ne sont pas toujours visibles immédiatement, consultez la section [Les modifications que j'apporte ne sont pas toujours visibles immédiatement](troubleshoot.md#troubleshoot_general_eventual-consistency). **Note** Si vous choisissez **Révoquer les sessions actives** ultérieurement, l’horodatage de la politique sera actualisé et elle refusera à nouveau toutes les autorisations à tout utilisateur ayant endossé le rôle avant la nouvelle heure spécifiée. Les utilisateurs valides dont les sessions sont révoquées de cette manière doivent obtenir des informations d'identification temporaires pour qu'une nouvelle session continue de fonctionner. Les informations d'identification sont mises en AWS CLI cache jusqu'à leur expiration. Pour forcer la CLI à supprimer et actualiser les informations d'identification mises en cache qui ne sont plus valides, exécutez l'une des commandes suivantes : **Linux, macOS ou Unix** ``` $ rm -r ~/.aws/cli/cache ``` **Windows** ``` C:\> del /s /q %UserProfile%\.aws\cli\cache ``` ## Révocation des autorisations de session avant une heure spécifiée Vous pouvez également révoquer les autorisations de session à tout moment de votre choix à l'aide du SDK AWS CLI ou afin de spécifier une valeur pour la `aws:TokenIssueTime` clé dans l'élément Condition d'une politique. Cette politique refuse toutes les autorisations lorsque la valeur de `aws:TokenIssueTime` est antérieure aux date et heure spécifiées. La valeur de `aws:TokenIssueTime` correspond à l'exacte à laquelle les informations d'identification de sécurité temporaires ont été créées. La `aws:TokenIssueTime` valeur n'est présente que dans le contexte des AWS demandes signées avec des informations d'identification de sécurité temporaires, de sorte que l'instruction Deny de la politique n'affecte pas les demandes signées avec les informations d'identification à long terme de l'utilisateur IAM. Cette politique peut également être attachée à un rôle. Dans ce cas, la politique affecte uniquement les informations d'identification de sécurité temporaires créées par le rôle avant la date et l'heure spécifiées. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"} } } } ``` ------ Les utilisateurs valides dont les sessions sont révoquées de cette manière doivent obtenir des informations d'identification temporaires pour qu'une nouvelle session continue de fonctionner. Les informations d'identification sont mises en AWS CLI cache jusqu'à leur expiration. Pour forcer la CLI à supprimer et actualiser les informations d'identification mises en cache qui ne sont plus valides, exécutez l'une des commandes suivantes : **Linux, macOS ou Unix** ``` $ rm -r ~/.aws/cli/cache ``` **Windows** ``` C:\> del /s /q %UserProfile%\.aws\cli\cache ``` # Mise à jour d’un rôle lié à un service La méthode que vous utilisez pour modifier un rôle lié à un service dépend dudit service. Certains services peuvent vous permettre de modifier les autorisations d'un rôle lié à un service depuis la console, l'API ou la CLI. Cependant, une fois un rôle lié à un service créé, vous ne pouvez pas changer le nom d'un rôle car plusieurs entités peuvent faire référence au rôle. Vous pouvez modifier la description de n'importe quel rôle depuis la console IAM, l'API ou la CLI. Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services affichant **Oui **dans la colonne **Rôle lié à un service**. Pour savoir si le service prend en charge la modification du rôle lié à un service, choisissez le lien **Oui** pour afficher la documentation du rôle lié à ce service. ## Modification de la description d'un rôle lié à un service (console) Vous pouvez utiliser la console IAM pour modifier la description d'un rôle lié à un service. **Pour modifier la description d'un rôle lié à un service (console)** 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. 1. Choisissez le nom du rôle à modifier. 1. A l'extrême droite de **Description du rôle**, choisissez **Edit (Modifier)**. 1. Saisissez une nouvelle description dans la zone et choisissez **Save (Enregistrer)**. ## Modification de la description d'un rôle lié à un service (AWS CLI) Vous pouvez utiliser les commandes IAM depuis le AWS CLI pour modifier la description d'un rôle lié à un service. **Pour changer la description d'un rôle lié à un service (AWS CLI)** 1. (Facultatif) Pour afficher la description actuelle d'un rôle, exécutez les commandes suivantes : ``` aws iam [get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) --role-name ROLE-NAME ``` Utilisez le nom du rôle, pas l'ARN, pour faire référence aux rôles avec les commandes CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**. 1. Pour mettre à jour la description d'un rôle lié à un service, exécutez la commande suivante : ``` aws iam [update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) --role-name ROLE-NAME --description OPTIONAL-DESCRIPTION ``` ## Modification d'une description de rôle liée à un service (API)AWS Vous pouvez utiliser l' AWS API pour modifier la description d'un rôle lié à un service. **Pour modifier la description d'un rôle lié à un service (API)AWS** 1. (Facultatif) Pour afficher la description actuelle d'un rôle, appelez l'opération suivante et spécifiez le nom du rôle : AWS API : [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. Pour mettre à jour la description d'un rôle, appelez l'opération suivante et spécifiez le nom (et la description facultative) du rôle : AWS API : [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) # Mise à jour d’une politique d’approbation de rôle Pour modifier la personne qui peut endosser un rôle, vous devez modifier la politique d'approbation du rôle. Vous ne pouvez pas modifier la politique d'approbation d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)*. **Remarques** Si un utilisateur est répertorié comme principal dans la politique d'approbation d'un rôle, mais ne peut pas endosser le rôle, vérifiez les [limites d'autorisations](access_policies_boundaries.md) de l'utilisateur. Si une limite d'autorisation est définie pour l'utilisateur, elle doit autoriser l'action `sts:AssumeRole`. Pour permettre aux utilisateurs d'assumer à nouveau le rôle actuel au cours d'une session de rôle, spécifiez l'ARN du rôle ou l' Compte AWS ARN comme principal dans la politique de confiance des rôles. Services AWS qui fournissent des ressources de calcul telles qu'Amazon EC2, Amazon ECS, Amazon EKS et Lambda fournissent des informations d'identification temporaires et mettent automatiquement à jour ces informations d'identification. Cela garantit que vous disposez toujours d'un ensemble d'informations d'identification valide. Pour ces services, il n'est pas nécessaire d'endosser à nouveau le rôle actuel pour obtenir des informations d'identification temporaires. Toutefois, si vous avez l'intention de transférer des [balises de session](id_session-tags.md) ou une [politique de session](access_policies.md#policies_session), vous devez endosser à nouveau le rôle actuel. ## Mise à jour d’une politique d’approbation de rôle (console) **Pour modifier une politique de confiance dans les rôles dans AWS Management Console** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. 1. Dans la liste des rôles de votre compte, choisissez le nom du rôle que vous souhaitez modifier. 1. Sélectionnez l'onglet **Trust relationships** (Relations d'approbation), puis **Edit trust policy** (Modifier la politique d'approbation). 1. Modifiez la politique d'approbation au besoin. Pour ajouter des principaux supplémentaires capables d'endosser le rôle, spécifiez-les dans l'élément `Principal`. Par exemple, l'extrait de politique suivant montre comment faire référence à deux éléments Comptes AWS dans l'`Principal`élément : ``` "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ] }, ``` Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). L'extrait de politique suivant montre comment référencer deux AWS services dans l'`Principal`élément : ``` "Principal": { "Service": [ "opsworks.amazonaws.com", "ec2.amazonaws.com" ] }, ``` 1. Après avoir modifié votre politique d'approbation, choisissez **Mettre à jour la politique** pour enregistrer vos modifications. Pour plus d'informations sur la syntaxe et la structure de la politique, consultez les sections [Politiques et autorisations dans Gestion des identités et des accès AWS](access_policies.md) et [Référence de l’élément de politique JSON IAM](reference_policies_elements.md). **Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (console)** Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. Connectez-vous à l'externe de confiance Compte AWS. 1. Décidez si vous devez attacher les autorisations à un utilisateur ou à un groupe. Dans le panneau de navigation de la console IAM, sélectionnez **Users** (Utilisateurs) ou **User groups** (Groupes d'utilisateurs) selon le cas. 1. Choisissez le nom de l'utilisateur ou du groupe auquel vous souhaitez accorder l'accès, puis sélectionnez l'onglet **Autorisations**. 1. Effectuez l’une des actions suivantes : + Pour modifier une politique gérée par un client, choisissez le nom de la politique, choisissez **Modifier la politique**, puis l'onglet **JSON**. Vous ne pouvez pas modifier une politique AWS gérée. AWS les politiques gérées apparaissent avec l' AWS icône (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_icon.png)). Pour plus d'informations sur la différence entre les stratégies gérées AWS et les stratégies gérées par le client, consultez [Politiques gérées et politiques en ligne](access_policies_managed-vs-inline.md). + Pour modifier une politique en ligne, choisissez la flèche en regard du nom de la politique et choisissez **Modifier la politique**. 1. Dans l'éditeur de politiques, ajoutez un nouvel élément `Statement` spécifiant ce qui suit : ``` { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME" } ``` Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser. 1. Suivez les invites à l'écran pour terminer de modifier la politique. ## Mise à jour d’une politique d’approbation de rôle (AWS CLI) Vous pouvez utiliser le AWS CLI pour modifier les personnes autorisées à assumer un rôle. **Pour modifier une politique d'approbation de rôle (AWS CLI)** 1. (Facultatif) Si vous ne connaissez pas le nom du rôle que vous souhaitez modifier, exécutez la commande suivante pour répertorier les rôles de votre compte : + [aws iam list-roles](https://docs.aws.amazon.com/cli/latest/reference/iam/list-roles.html) 1. (Facultatif) Pour afficher la politique d'approbation actuelle d'un rôle, exécutez la commande suivante : + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. Pour modifier les principaux approuvés ayant accès au rôle, créez un fichier texte avec la politique d'approbation mise à jour. Vous pouvez utiliser l'éditeur de texte pour créer la politique. Par exemple, la politique d'approbation suivante illustre comment référencer deux Comptes AWS dans l'élément `Principal`. Cela permet aux utilisateurs séparés Comptes AWS d'assumer ce rôle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ]}, "Action": "sts:AssumeRole" } } ``` ------ Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. Pour utiliser le fichier créé afin de mettre à jour la politique de confiance, exécutez la commande suivante : + [était un objectif update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html) **Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (AWS CLI)** Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. Créez un fichier JSON contenant une politique d'autorisations qui accorde des autorisations permettant d'endosser le rôle. Par exemple, la politique suivante contient les autorisations nécessaires minimales : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME" } } ``` ------ Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser. 1. Exécutez la commande suivante pour charger le fichier JSON contenant la politique de confiance dans IAM : + [aws iam create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html) Le résultat de cette commande inclut l'ARN de la politique. Notez cet ARN, car vous aurez besoin de l'utiliser ultérieurement. 1. Décidez à quel utilisateur ou groupe attacher la politique. Si vous ne connaissez pas le nom de l'utilisateur ou du groupe concerné, utilisez les commandes suivantes pour répertorier les utilisateurs ou les groupes de votre compte : + [aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html) + [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html) 1. Utilisez l'une des commandes suivantes pour attacher la politique créée dans l'étape précédente à l'utilisateur ou au groupe : + [était un objectif attach-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html) + [était un objectif attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html) ## Mettre à jour une politique de confiance dans les rôles (AWS API) Vous pouvez utiliser l' AWS API pour modifier les personnes autorisées à assumer un rôle. **Pour modifier une politique de confiance des rôles (AWS API)** 1. (Facultatif) Si vous ne connaissez pas le nom du rôle que vous souhaitez modifier, appelez l'opération suivante pour répertorier les rôles de votre compte : + [ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html) 1. (Facultatif) Pour afficher la politique d'approbation actuelle d'un rôle, appelez l'opération suivante : + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. Pour modifier les principaux approuvés ayant accès au rôle, créez un fichier texte avec la politique d'approbation mise à jour. Vous pouvez utiliser l'éditeur de texte pour créer la politique. Par exemple, la politique d'approbation suivante illustre comment référencer deux Comptes AWS dans l'élément `Principal`. Cela permet aux utilisateurs séparés Comptes AWS d'assumer ce rôle. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ]}, "Action": "sts:AssumeRole" } } ``` ------ Si vous spécifiez un principal dans un autre compte, l'ajout d'un compte à la politique d'approbation d'un rôle n'est qu'une partie de la procédure d'établissement de la relation d'approbation entre comptes. Par défaut, aucun utilisateur des comptes approuvés ne peut endosser le rôle. L'administrateur du compte nouvellement approuvé doit accorder aux utilisateurs l'autorisation d'endosser le rôle. Pour ce faire, l'administrateur doit créer ou modifier une politique attachée à l'utilisateur pour lui permettre d'accéder à l'action `sts:AssumeRole`. Pour plus d'informations, consultez la procédure suivante ou [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. Pour utiliser le fichier créé afin de mettre à jour la politique de confiance, appelez l'opération suivante : + [UpdateAssumeRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html) **Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle (AWS API)** Pour plus d'informations sur cette procédure, consultez [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). 1. Créez un fichier JSON contenant une politique d'autorisations qui accorde des autorisations permettant d'endosser le rôle. Par exemple, la politique suivante contient les autorisations nécessaires minimales : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME" } } ``` ------ Remplacez l'ARN dans l'instruction par celui du rôle que l'utilisateur peut endosser. 1. Appelez l'opération suivante pour charger le fichier JSON contenant la politique de confiance dans IAM : + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html) Le résultat de cette opération inclut l'ARN de la politique. Notez cet ARN, car vous aurez besoin de l'utiliser ultérieurement. 1. Décidez à quel utilisateur ou groupe attacher la politique. Si vous ne connaissez pas le nom de l'utilisateur ou du groupe concerné, appelez les opérations suivantes pour répertorier les utilisateurs ou les groupes de votre compte : + [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html) + [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html) 1. Appelez l'une des opérations suivantes pour attacher la politique créée à l'étape précédente à l'utilisateur ou au groupe : + API : [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html) + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html) # Mettre à jour les autorisations pour un rôle Utilisez les procédures suivantes pour mettre à jour les politiques d’autorisation et les limites des autorisations d’un rôle. ## Prérequis : afficher l’accès au rôle Avant de modifier les autorisations d'un rôle, vous devez passer en revue ses activités récentes au niveau service. Ceci est important, car vous ne souhaitez pas supprimer l'accès à partir d'un principal (personne ou application) qui l'utilise. Pour de plus amples informations sur l'affichage des dernières informations consultées, consultez [Affiner les autorisations en AWS utilisant les dernières informations consultées](access_policies_last-accessed.md). ## Mettre à jour une politique d’autorisation pour un rôle Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service. ### Mise à jour d’une politique d’autorisations de rôle (console) **Pour changer les autorisations autorisées par un rôle (console)** 1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. 1. Choisissez le nom du rôle à modifier, puis choisissez l'onglet **Autorisations**. 1. Effectuez l’une des actions suivantes : + Pour modifier une politique existante gérée par le client, choisissez le nom de la politique, puis choisissez **Modifier la politique**. **Note** Vous ne pouvez pas modifier une politique AWS gérée. AWS les politiques gérées apparaissent avec l' AWS icône (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/policy_icon.png)). Pour plus d'informations sur la différence entre les politiques AWS gérées et les politiques gérées par le client, consultez[Politiques gérées et politiques en ligne](access_policies_managed-vs-inline.md). + Pour attacher une stratégie gérée existante au rôle, choisissez **Add permissions** (Ajouter des autorisations) puis choisissez **Attach policies** (Attacher des politiques). + Pour modifier une politique en ligne existante, développez la politique et choisissez **Edit** (Modifier). + Pour intégrer une nouvelle politique en ligne, choisissez **Add permissions** (Ajouter des autorisations) puis choisissez **Create inline policy** (Création de stratégie en ligne). + Pour supprimer une politique existante du rôle, cochez la case située en regard du nom de la politique et sélectionnez **Retirer**. ### Mise à jour d’une politique d’autorisations de rôle (AWS CLI) Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service. **Pour modifier les autorisations autorisées par un rôle (AWS CLI)** 1. (Facultatif) Pour afficher les autorisations actuelles associées à un rôle, exécutez les commandes suivantes : 1. [aws vise à list-role-policies répertorier](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-policies.html) les politiques en ligne 1. [aws iam va list-attached-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html) répertorier les politiques gérées 1. La commande permettant de mettre à jour les autorisations du rôle varie selon que vous mettez à jour une politique gérée ou une politique en ligne. Pour mettre à jour une politique gérée, exécutez la commande suivante pour créer une nouvelle version de la politique gérée : + [était un objectif create-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html) Pour mettre à jour une politique en ligne, exécutez la commande suivante : + [était un objectif put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) ### Mettre à jour une politique d'autorisation de rôle (AWS API) Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle (ou les stratégies). Vous ne pouvez pas modifier la politique d'autorisations d'un *[rôle lié à un service](id_roles.md#iam-term-service-linked-role)* dans IAM. Vous pouvez modifier la politique d'autorisations dans le service dépendant du rôle. Pour vérifier si un service prend en charge cette fonctionnalité, reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et recherchez les services qui possèdent **Yes (Oui)**dans la colonne **Rôles liés à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service. **Pour modifier les autorisations accordées par un rôle (AWS API)** 1. (Facultatif) Pour afficher les autorisations actuelles associées à un rôle, appelez les opérations suivantes : 1. [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)pour répertorier les politiques en ligne 1. [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)pour répertorier les politiques gérées 1. L'opération permettant de mettre à jour les autorisations du rôle varie selon que vous mettez à jour une politique gérée ou une politique en ligne. Pour mettre à jour une politique gérée, appelez l'opération suivante pour créer une nouvelle version de la politique gérée : + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html) Pour mettre à jour une politique en ligne, appelez l'opération suivante : + [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) ## Mettre à jour la limite des autorisations pour un rôle Pour modifier le nombre maximum d'autorisations permises pour un rôle, modifiez la [limite d'autorisations](access_policies_boundaries.md) du rôle ### Mise à jour d’une limite des autorisations de rôle (console) **Pour modifier la politique utilisée afin de définir la limite d'autorisations pour un rôle** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation, choisissez **Rôles**. 1. Sélectionnez le nom du rôle présentant la [limite d'autorisations](access_policies_boundaries.md) que vous souhaitez modifier. 1. Sélectionnez l’onglet **Autorisations**. Si nécessaire, ouvrez la section **Permissions boundary (Limite d'autorisations)**, puis choisissez **Change boundary (Modifier une limite)**. 1. Sélectionnez la politique que vous souhaitez utiliser pour la limite d'autorisations. 1. Choisissez **Change boundary (Modifier une limite)**. Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. ### Mise à jour d’une limite des autorisations de rôle (AWS CLI) **Pour modifier la politique gérée utilisée afin de définir la limite d'autorisations pour un rôle (AWS CLI)** 1. (Facultatif) Pour afficher la [limite d'autorisations](access_policies_boundaries.md) actuelle d'un rôle, exécutez la commande suivante : + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. Pour utiliser une autre politique gérée afin de mettre à jour la limite d'autorisations d'un rôle, exécutez la commande suivante : + [était un objectif put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) Un rôle peut disposer d'une seule politique gérée définie comme une limite d'autorisations. Si vous modifiez la limite d'autorisations, cela modifie le nombre maximum d'autorisations permises pour un rôle. ### Mettre à jour la limite d'autorisations d'un rôle (AWS API) **Pour modifier la politique gérée utilisée pour définir la limite des autorisations pour un rôle (AWS API)** 1. (Facultatif) Pour afficher la [limite d'autorisations](access_policies_boundaries.md) actuelle d'un rôle, appelez l'opération suivante : + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. Pour utiliser une autre politique gérée afin de mettre à jour la limite d'autorisations d'un rôle, appelez l'opération suivante : + [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) Un rôle peut disposer d'une seule politique gérée définie comme une limite d'autorisations. Si vous modifiez la limite d'autorisations, cela modifie le nombre maximum d'autorisations permises pour un rôle. # Mise à jour des paramètres pour un rôle Utilisez les procédures suivantes pour mettre à jour la description d’un rôle ou modifier la durée maximale de session d’un rôle. ## Mettre à jour la description d’un rôle Pour modifier la description du rôle, modifiez le texte de la description. ### Mise à jour d’une description de rôle (console) **Pour modifier la description d'un rôle (console)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. 1. Choisissez le nom du rôle à modifier. 1. Dans la section **Summary** (Récapitulatif), sélectionnez **Edit** (Modifier). 1. Saisissez une nouvelle description dans le champ et sélectionnez **Save changes** (Enregistrer les modifications). ### Mise à jour de la description d’un rôle (AWS CLI) **Pour modifier la description d'un rôle (AWS CLI)** 1. (Facultatif) Pour afficher la description actuelle d'un rôle, exécutez la commande suivante : + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. Pour mettre à jour la description d'un rôle, exécutez la commande suivante avec le paramètre de description : + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) ### Mettre à jour la description d'un rôle (AWS API) **Pour modifier la description d'un rôle (AWS API)** 1. (Facultatif) Pour afficher la description actuelle d'un rôle, appelez l'opération suivante : + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. Pour mettre à jour la description d'un rôle, appelez l'opération suivante avec le paramètre de description : + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) ## Mettre à jour la durée de session maximale pour un rôle Pour spécifier le paramètre de durée de session maximale pour les rôles assumés à l'aide de la console, de l' AWS CLI AWS API ou de l'API, modifiez la valeur du paramètre de durée maximale de session. La valeur de ce paramètre peut varier de 1 heure à 12 heures. Si vous ne spécifiez pas de valeur, la valeur par défaut de 1 heure maximum est appliquée. Ce paramètre ne limite pas les sessions prises en charge par AWS les services. ### Mise à jour de la durée de session maximale d’un rôle (console) **Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de la console ou de AWS l'API (console) AWS CLI** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. 1. Choisissez le nom du rôle à modifier. 1. Dans la section **Summary** (Récapitulatif), sélectionnez **Edit** (Modifier). 1. Pour **Maximum session duration** (Durée de session maximale), choisissez une valeur. Autrement, vous pouvez choisir **Custom duration** (Durée personnalisée) et saisir une valeur (en secondes). 1. Sélectionnez **Enregistrer les modifications**. Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). Dans le AWS Management Console, les sessions utilisateur IAM durent 12 heures par défaut. Les utilisateurs IAM qui changent de rôle dans la console se voient accorder la durée de session maximale du rôle ou le temps restant dans la session de l'utilisateur IAM, selon la durée la plus courte. Toute personne assumant le rôle depuis l' AWS API AWS CLI or peut demander une session plus longue, jusqu'à ce maximum. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée. + Pour spécifier une durée de session à l'aide du paramètre, AWS CLI utilisez le `duration-seconds` paramètre. Pour en savoir plus, veuillez consulter la section [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md). + Pour spécifier une durée de session à l'aide de l' AWS API, utilisez le `DurationSeconds` paramètre. Pour en savoir plus, veuillez consulter la section [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md). ### Mise à jour de la durée de session maximale d’un rôle (AWS CLI) **Note** Toute personne assumant le rôle depuis l'API AWS CLI or peut utiliser le paramètre `duration-seconds` CLI ou le paramètre `DurationSeconds` API pour demander une session plus longue. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée à l'aide du paramètre `DurationSeconds`. Si les utilisateurs ne spécifient pas de valeur pour le paramètre `DurationSeconds`, leurs informations d'identification de sécurité sont valides pendant une heure. **Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de AWS CLI (AWS CLI)** 1. (Facultatif) Pour afficher le paramètre de durée de session maximale d'un rôle, exécutez la commande suivante : + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) 1. Pour mettre à jour le paramètre de durée de session maximale d'un rôle, exécutez la commande suivante avec le paramètre `max-session-duration` de l'interface de ligne de commande ou le paramètre `MaxSessionDuration` de l'API : + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). ### Mise à jour de la durée maximale des sessions de rôle (AWS API) **Note** Toute personne assumant le rôle depuis l'API AWS CLI or peut utiliser le paramètre `duration-seconds` CLI ou le paramètre `DurationSeconds` API pour demander une session plus longue. Le paramètre `MaxSessionDuration` détermine la durée maximale de la session de rôle qui peut être demandée à l'aide du paramètre `DurationSeconds`. Si les utilisateurs ne spécifient pas de valeur pour le paramètre `DurationSeconds`, leurs informations d'identification de sécurité sont valides pendant une heure. **Pour modifier le paramètre de durée maximale de session pour les rôles assumés à l'aide de l'API (AWS API)** 1. (Facultatif) Pour afficher le paramètre de durée de session maximale d'un rôle, appelez l'opération suivante : + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 1. Pour mettre à jour le paramètre de durée de session maximale d'un rôle, appelez l'opération suivante avec le paramètre `max-sessionduration` de la CLI ou le paramètre `MaxSessionDuration` de l'API : + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) Vos modifications ne prennent pas effet jusqu'à ce qu'une autre personne endosse ce rôle. Pour apprendre à révoquer des sessions existantes pour ce rôle, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). # Suppression de rôles ou de profils d’instance Si vous n'avez plus besoin d'un rôle, nous vous recommandons de supprimer le rôle et ses autorisations associées. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Si le rôle était associé à une instance EC2, vous pouvez également le supprimer du profil d'instance, puis supprimer ce dernier. **Avertissement** Vérifiez qu'aucune instance Amazon EC2 n'est en cours d'exécution avec le rôle ou le profil d'instance que vous êtes sur le point de supprimer. La suppression d'un rôle ou d'un profil d'instance associé à une instance en cours d'exécution arrêtera toutes les applications qui s'exécutent sur l'instance. Si vous préférez ne pas supprimer définitivement un rôle, vous pouvez le désactiver. Pour ce faire, modifiez les politiques du rôle, puis révoquez toutes les sessions en cours. Par exemple, vous pouvez ajouter une politique au rôle qui refuse l'accès à tous AWS. Vous pouvez également modifier la politique d'approbation pour refuser l'accès à toute personne qui tente d'endosser le rôle. Pour en savoir plus sur la révocation des sessions, consultez [Révocation des informations d’identification de sécurité temporaires d’un rôle IAM](id_roles_use_revoke-sessions.md). **Topics** + [Affichage de l’accès au rôle](#roles-delete_prerequisites) + [Suppression d'un rôle lié à un service](#id_roles_manage_delete_slr) + [Suppression d'un rôle IAM (console)](#roles-managingrole-deleting-console) + [Suppression d'un rôle IAM (AWS CLI)](#roles-managingrole-deleting-cli) + [Supprimer un rôle IAM (AWS API)](#roles-managingrole-deleting-api) + [Informations connexes](#roles-managingrole-deleting-related-info) ## Affichage de l’accès au rôle Avant de supprimer un rôle, nous vous recommandons de vérifier la date de sa dernière utilisation. Vous pouvez le faire à l'aide de l'API AWS Management Console AWS CLI, du ou de l' AWS API. Vous devriez consulter ces informations, car vous ne voulez pas retirer l'accès à une personne utilisant ce rôle. La date de la dernière activité du rôle peut ne pas correspondre à la dernière date indiquée dans l’onglet **Dernière consultation**. L’onglet [**Dernière consultation**](access_policies_last-accessed-view-data.md) signale l’activité uniquement pour les services autorisés par les politiques d’autorisations du rôle. La date de la dernière activité du rôle inclut la dernière tentative d'accès à un service dans lequel le rôle a été créé AWS. **Note** La période de suivi de la dernière activité d’un rôle et des données Dernière consultation correspond aux 400 jours précédents. Cette période peut être plus courte si votre région a commencé à prendre en charge ces fonctionnalités au cours de la dernière année. Le rôle aurait pu être utilisé il y a plus de 400 jours. Pour de plus amples informations sur la période de suivi, veuillez consulter [Où AWS suit les dernières informations consultées](access_policies_last-accessed.md#last-accessed_tracking-period). **Pour afficher la date à laquelle un rôle a été utilisé pour la dernière fois (console)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation, choisissez **Rôles**. 1. Recherchez la ligne du rôle dont vous souhaitez afficher l'activité. Vous pouvez utiliser le champ de recherche pour affiner les résultats. Affichez la colonne **Dernière activité** pour voir le nombre de jours écoulés depuis la dernière utilisation du rôle. Si le rôle n'a pas été utilisé pendant la période de suivi, le tableau affiche **Aucun**. 1. Choisissez le nom du rôle pour afficher plus d'informations. La page **Summary** (Résumé) du rôle inclut également **Last activity** (Dernière activité), qui affiche la date à laquelle le rôle a été utilisé pour la dernière fois. Si le rôle n'a pas été utilisé au cours des 400 derniers jours, la **Dernière activité** affiche **Non consulté pendant la période de suivi**. **Pour voir quand un rôle a été utilisé pour la dernière fois (AWS CLI)** `[aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)` - Exécutez cette commande pour renvoyer des informations sur un rôle, y compris l'objet `RoleLastUsed`. Cet objet contient la `LastUsedDate` et la `Region` dans laquelle le rôle a été utilisé pour la dernière fois. Si `RoleLastUsed` est présent mais ne contient pas de valeur, le rôle n'a pas été utilisé pendant la période de suivi. **Pour voir quand un rôle a été utilisé pour la dernière fois (AWS API)** `[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/GetRole.html)` - Appelez cette opération pour renvoyer des informations sur un rôle, y compris l'objet `RoleLastUsed`. Cet objet contient la `LastUsedDate` et la `Region` dans laquelle le rôle a été utilisé pour la dernière fois. Si `RoleLastUsed` est présent mais ne contient pas de valeur, le rôle n'a pas été utilisé pendant la période de suivi. ## Suppression d'un rôle lié à un service La méthode que vous utilisez pour supprimer un rôle lié à un service dépend dudit service. Dans certains cas, vous n'avez pas besoin de supprimer manuellement un rôle lié à un service. Par exemple, lorsque vous terminez une action donnée (comme supprimer une ressource) dans le service, le service peut supprimer le rôle lié au service à votre place. Dans d'autres cas, le service peut prendre en charge la suppression manuelle d'un rôle lié à un service à partir de la console, de l'API ou de la AWS CLI. Consultez la documentation relative au *[rôle lié au service](id_roles.md#iam-term-service-linked-role)* dans le service lié pour savoir comment supprimer le rôle. Pour afficher les rôles liés à un service de votre compte, rendez-vous sur la page **IAM Roles** (Rôles IAM) de la console. Les rôles liés à un service s'affichent avec **(Rôle lié à un service)** mentionné dans la colonne **Entités de confiance** du tableau. Une bannière sur la page **Summary** (Résumé) d'un rôle indique aussi que le rôle est lié à un service. Si le service ne contient pas de documentation pour supprimer le rôle lié au service, vous pouvez utiliser la console IAM ou l'API pour supprimer le rôle. AWS CLI ## Suppression d'un rôle IAM (console) Lorsque vous utilisez le AWS Management Console pour supprimer un rôle, IAM détache automatiquement les politiques gérées associées au rôle. Il supprime aussi automatiquement toute politique en ligne associée au rôle, ainsi que tout profil d'instance Amazon EC2 qui contient le rôle. **Important** Dans certains cas, un rôle peut être associé à un profil d'instance Amazon EC2, et le rôle et le profil d'instance peuvent porter exactement le même nom. Dans ce cas, vous pouvez utiliser le AWS Management Console pour supprimer le rôle et le profil d'instance. Ce lient se fait automatiquement pour les rôles et les profils d'instance que vous créez dans la console. Si vous avez créé le rôle à partir des outils pour Windows PowerShell ou de l' AWS API, le rôle et le profil d'instance peuvent porter des noms différents. AWS CLI Dans ce cas, vous ne pouvez pas utiliser la console pour les supprimer. Vous devez plutôt utiliser les AWS CLI outils pour Windows PowerShell ou l' AWS API pour supprimer d'abord le rôle du profil d'instance. Vous devez ensuite réaliser une étape distincte pour supprimer le rôle. **Pour supprimer un rôle (console)** 1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse. 1. Dans le panneau de navigation, choisissez **Rôles**, puis cochez la case en regard du rôle à supprimer. 1. En haut de la page, sélectionnez **Delete** (Supprimer). 1. Dans la boîte de dialogue de confirmation, passez en revue les dernières informations consultées, qui indiquent la date à laquelle chacun des rôles sélectionnés a accédé pour la dernière fois à un AWS service. Cela vous permet de confirmer si le rôle est actif actuellement. Pour poursuivre, saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete (Supprimer)**. Si vous êtes sûr, procédez à la suppression même si les dernières informations consultées sont toujours en cours de chargement. **Note** Vous ne pouvez pas utiliser la console pour supprimer un profil d'instance, sauf lorsqu'elle porte le même nom que le rôle. Le profil d'instance est supprimé dans le cadre du processus de suppression d'un rôle comme décrit dans la procédure précédente. Pour supprimer un profil d'instance sans supprimer également le rôle, vous devez utiliser l' AWS API AWS CLI or. Pour plus d’informations, consultez les sections suivantes. ## Suppression d'un rôle IAM (AWS CLI) Lorsque vous utilisez le AWS CLI pour supprimer un rôle, vous devez d'abord supprimer les politiques intégrées associées au rôle. Vous devez également détacher les politiques gérées associées au rôle. Si vous voulez supprimer le profil d'instance associé contenant le rôle, vous devez le supprimer séparément. **Pour supprimer un rôle (AWS CLI)** 1. Si vous ne connaissez pas le nom du rôle que vous souhaitez supprimer, tapez la commande suivante pour répertorier les rôles dans votre compte : ``` aws iam list-roles ``` La liste inclut l'Amazon Resource Name (ARN) de chaque rôle. Utilisez le nom du rôle, pas l'ARN, pour faire référence aux rôles avec les commandes CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**. 1. Supprimez le rôle de tous les profils d'instance auxquels il est associé. 1. Pour répertorier tous les profils d'instance auxquels un rôle est associé, tapez la commande suivante : ``` aws iam list-instance-profiles-for-role --role-name role-name ``` 1. Pour supprimer le rôle d'un profil d'instance, saisissez la commande suivante pour chaque profil instance : ``` aws iam remove-role-from-instance-profile --instance-profile-name instance-profile-name --role-name role-name ``` 1. Supprimez toutes les politiques associées au rôle. 1. Pour répertorier toutes les politiques en ligne que contient le rôle, saisissez la commande suivante : ``` aws iam list-role-policies --role-name role-name ``` 1. Pour supprimer chaque politique en ligne du rôle, saisissez la commande suivante pour chaque politique : ``` aws iam delete-role-policy --role-name role-name --policy-name policy-name ``` 1. Pour répertorier toutes les politiques gérées attachées au rôle, saisissez la commande suivante : ``` aws iam list-attached-role-policies --role-name role-name ``` 1. Pour détacher chaque politique gérée du rôle, saisissez la commande suivante pour chaque politique : ``` aws iam detach-role-policy --role-name role-name --policy-arn policy-arn ``` 1. Tapez la commande suivante pour supprimer le rôle : ``` aws iam delete-role --role-name role-name ``` 1. Si vous ne prévoyez pas de réutiliser les profils d'instance associés au rôle, vous pouvez saisir la commande suivante pour les supprimer : ``` aws iam delete-instance-profile --instance-profile-name instance-profile-name ``` ## Supprimer un rôle IAM (AWS API) Lorsque vous utilisez l'API IAM pour supprimer un rôle, vous devez d'abord supprimer les politiques en ligne associées au rôle. Vous devez également détacher les politiques gérées associées au rôle. Si vous voulez supprimer le profil d'instance associé contenant le rôle, vous devez le supprimer séparément. **Pour supprimer un rôle (AWS API)** 1. Pour répertorier tous les profils d'instance auxquels un rôle est associé, appelez [ListInstanceProfilesForRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html). Pour supprimer le rôle d'un profil d'instance, appelez [RemoveRoleFromInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html). Vous devez transmettre le nom du rôle et le nom du profil d'instance. Si vous ne comptez pas réutiliser un profil d'instance associé au rôle, appelez [DeleteInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html)pour le supprimer. 1. Pour répertorier toutes les politiques intégrées à un rôle, appelez [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html). Pour supprimer les politiques intégrées associées au rôle, appelez [DeleteRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRolePolicy.html). Vous devez transmettre le nom du rôle et le nom de la politique en ligne. 1. Pour répertorier toutes les politiques gérées associées à un rôle, appelez [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html). Pour détacher les politiques gérées associées au rôle, appelez [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html). Vous devez transmettre le nom du rôle et l'ARN de la politique gérée. 1. Appelez [DeleteRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRole.html)pour supprimer le rôle. ## Informations connexes Pour obtenir des informations générales sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). Pour obtenir des informations générales sur les rôles liés à un service, veuillez consulter [Créer un rôle lié à un service](id_roles_create-service-linked-role.md). # Méthodes pour assumer un rôle Avant qu’un utilisateur, une application ou un service soit en mesure d’utiliser un rôle que vous avez créé, vous devez lui [accorder les autorisations nécessaires pour changer](id_roles_use_permissions-to-switch.md) de rôle. Pour accorder ces autorisations, vous pouvez utiliser n’importe quelle politique attachée à l’un des groupes ou des utilisateurs. Une fois les autorisations accordées, l'utilisateur peut assumer un rôle dans les outils pour Windows PowerShell, le AWS Command Line Interface (AWS CLI) et l'[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API. AWS Management Console **Important** Si vous créez un rôle par programmation plutôt que dans la console IAM, vous avez la possibilité d'ajouter un chemin `Path` de 512 caractères au maximum à l'élément `RoleName` qui lui, est de 64 caractères au maximum. Toutefois, si vous avez l'intention d'utiliser un rôle avec la fonctionnalité **Switch** Role dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères. La méthode utilisée pour endosser le rôle détermine qui peut endosser le rôle et la durée de la session de rôle. Lorsque vous l'utilisez `AssumeRole*` les opérations d'API, le rôle IAM que vous endossez est la ressource. Le rôle ou l'utilisateur IAM qui appelle les opérations de l'API `AssumeRole*` est le principal. Le tableau suivant compare les méthodes pour endosser des rôles. | Méthode permettant d'endosser le rôle | **Qui peut endosser le rôle** | **Méthode permettant de spécifier la durée de vie des informations d'identification** | **Durée de vie des informations d'identification (min \$1 max \$1 par défaut)** | | --- | --- | --- | --- | | AWS Management Console | Utilisateur ou rôles¹ (en [changeant de rôle](id_roles_use_switch-role-console.md)) | Durée de session maximale sur la page récapitulative des rôles | 15 min \$1 Durée de session maximale² \$1 1 h | | Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | Utilisateur ou rôle¹ | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h | | Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Tout utilisateur authentifié utilisant SAML | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h | | Opération d'interface de ligne de commande (CLI) [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) ou d'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Tout utilisateur authentifié à l’aide d’un fournisseur OIDC | Paramètre de CLI duration-seconds ou d'API DurationSeconds | 15 min \$1 Durée de session maximale² \$1 1 h | | [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRole | Utilisateur ou rôle | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h | | [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRoleWithSAML | Tout utilisateur authentifié utilisant SAML | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h | | [URL de console](id_roles_providers_enable-console-custom-url.md) construite avec AssumeRoleWithWebIdentity | Tout utilisateur authentifié à l’aide d’un fournisseur OIDC | Paramètre HTML SessionDuration dans l'URL | 15 min \$1 12 h \$1 1 h | ¹ L’utilisation des informations d’identification pour qu’un rôle endosse un rôle différent est appelée [création de chaînes de rôles](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez la création de chaînes de rôles, la durée de session du rôle est limitée à une heure. Cela s'applique au changement de AWS Management Console rôle et aux opérations d'API. AWS CLI Cette limitation ne s'applique pas à l'attribution initiale d'un rôle à partir des informations d'identification de l'utilisateur, ni aux applications exécutées sur des EC2 instances Amazon à l'aide de profils d'instance. ² La valeur de ce paramètre peut varier de 1 heure à 12 heures. Pour en savoir plus sur la modification du paramètre de durée de session maximale, consultez [Gestion des rôles IAM](id_roles_manage.md). Ce paramètre détermine la durée de session maximale que vous pouvez demander lorsque vous obtenez les informations d'identification du rôle. Par exemple, lorsque vous utilisez les opérations d'API [AssumeRole\$1](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) pour assumer un rôle, vous pouvez spécifier une durée de session à l'aide du `DurationSeconds` paramètre. Utilisez ce paramètre pour spécifier la durée de la session du rôle entre 900 secondes (15 minutes) et la durée de session maximale pour le rôle. Les utilisateurs IAM qui changent de rôle dans la console se voient accorder la durée de session maximale ou le temps restant dans la session de l'utilisateur, selon la durée la plus courte. Supposons que vous définissiez une durée maximale de 5 heures sur un rôle. Un utilisateur IAM qui s'est connecté à la console pendant 10 heures (sur 12, le maximum par défaut) décide d'endosser le rôle. La durée de la session de rôle disponible est de 2 heures. Pour savoir comment afficher la valeur maximale pour votre rôle, consultez [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration) plus loin sur cette page. **Remarques** Le paramètre de durée maximale de session ne limite pas les sessions endossées par les services AWS . Les informations d'identification du rôle Amazon EC2 IAM ne sont pas soumises à la durée de session maximale configurée dans le rôle. Pour permettre aux utilisateurs d'assumer à nouveau le rôle actuel au cours d'une session de rôle, spécifiez l'ARN ou l' Compte AWS ARN comme principal dans la politique de confiance des rôles. Services AWS qui fournissent des ressources de calcul telles qu'Amazon EC2, Amazon ECS, Amazon EKS et Lambda fournissent des informations d'identification temporaires et mettent automatiquement à jour ces informations d'identification. Cela garantit que vous disposez toujours d'un ensemble d'informations d'identification valide. Pour ces services, il n'est pas nécessaire d'endosser à nouveau le rôle actuel pour obtenir des informations d'identification temporaires. Toutefois, si vous avez l'intention de transférer des [balises de session](id_session-tags.md) ou une [politique de session](access_policies.md#policies_session), vous devez endosser à nouveau le rôle actuel. Pour savoir comment modifier une politique d'approbation des rôles afin d'ajouter l'ARN ou Compte AWS l'ARN du rôle principal, consultez[Mise à jour d’une politique d’approbation de rôle](id_roles_update-role-trust-policy.md). **Topics** + [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md) + [Basculer vers un rôle IAM (AWS CLI)](id_roles_use_switch-role-cli.md) + [Basculer vers un rôle IAM (Outils pour Windows PowerShell)](id_roles_use_switch-role-twp.md) + [Basculer vers un rôle IAM (AWS API)](id_roles_use_switch-role-api.md) + [Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2](id_roles_use_switch-role-ec2.md) + [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md) # Basculer d’un utilisateur à un rôle IAM (console) Vous pouvez basculer d'un rôle à l'autre lorsque vous vous connectez en tant qu'utilisateur IAM, utilisateur de IAM Identity Center, rôle fédéré SAML ou rôle fédéré d'identité Web. Un *rôle* définit un ensemble d'autorisations que vous pouvez utiliser pour accéder aux AWS ressources dont vous avez besoin. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté en tant qu’utilisateur IAM, vous pouvez passer à un rôle IAM. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Les autorisations de votre utilisateur et des rôles que vous assumez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement vos autorisations utilisateur et travaillez avec celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées. Lorsque vous changez de rôle dans le AWS Management Console, la console utilise toujours vos informations d'identification d'origine pour autoriser le changement. Par exemple, si vous basculez sur RoleA, IAM utilise vos informations d’identification d’origine pour déterminer si vous êtes autorisé à endosser le rôle RoleA. Si vous passez ensuite à RoleB alors *que vous utilisez RoleA, utilisez* toujours **vos** informations d'identification d'origine pour autoriser le changement AWS , et non les informations d'identification pour RoleA. **Note** Lorsque vous vous connectez en tant qu’utilisateur dans IAM Identity Center, en tant que rôle fédéré par SAML ou en tant que rôle fédéré par identité Web, vous endossez un rôle IAM lorsque vous démarrez votre session. Par exemple, lorsqu'un utilisateur d'IAM Identity Center se connecte au portail AWS d'accès, il doit choisir un ensemble d'autorisations correspondant à un rôle avant de pouvoir accéder aux AWS ressources. ## Séances de rôle Lorsque vous changez de rôle, votre AWS Management Console session dure 1 heure par défaut. Les sessions des utilisateurs IAM ont une durée de 12 heures par défaut, d’autres utilisateurs peuvent avoir des durées de session différentes. Lorsque vous changez de rôle dans la console, la durée maximale de la session du rôle ou la durée restante de votre session d’utilisateur vous est accordée, selon la durée la plus courte. Vous ne pouvez pas prolonger la durée de votre session en endossant un rôle. Par exemple, supposons qu'une durée de session maximale de 10 heures soit définie pour un rôle. Vous êtes connecté à la console depuis huit heures lorsque vous décidez d’endosser le rôle. Il reste quatre heures dans votre session utilisateur IAM, de sorte que la durée autorisée de la session du rôle est de quatre heures, et non la durée maximale de la session de dix heures. Le tableau suivant montre comment déterminer la durée de session d'un utilisateur IAM lorsqu'il change de rôle dans la console. | Le temps restant de la session de l'utilisateur IAM est... | La durée de la session de rôle est… | | --- | --- | | Moins que la durée de session maximale d'un rôle | Temps restant dans la session de l'utilisateur IAM | | Plus que la durée de session maximale du rôle | Valeur de durée de session maximale | | Égale à la durée de session maximale du rôle | Valeur de durée de session maximale (approximative) | L’utilisation des informations d’identification pour qu’un rôle endosse un rôle différent est appelée [création de chaînes de rôles](id_roles.md#iam-term-role-chaining). Lorsque vous utilisez le chaînage des rôles, la durée de la session est limitée à une heure, quel que soit le paramètre de durée maximale de session configuré pour chaque rôle. Cela s'applique au changement de AWS Management Console rôle et aux opérations d'API. AWS CLI **Note** Certaines consoles AWS de service peuvent renouveler automatiquement votre session de rôle lorsqu'elle expire sans que vous n'ayez à effectuer aucune action. Certaines peuvent vous inviter à recharger la page de votre navigateur pour réauthentifier votre session. ## Considérations + Vous ne pouvez pas changer de rôle si vous vous connectez en tant que Utilisateur racine d'un compte AWS. + Les utilisateurs doivent être autorisés à changer de rôle conformément à la politique. Pour obtenir des instructions, veuillez consulter [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md). + Vous ne pouvez pas changer de rôle dans le rôle AWS Management Console pour un rôle qui nécessite une [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)valeur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) qui prend en charge le paramètre `ExternalId`. ## Pour changer de rôle 1. Suivez la procédure de connexion correspondant à votre type d’utilisateur, comme décrit dans la rubrique [Connexion à AWS Management Console](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) du *Guide de l’utilisateur Connexion à AWS *. 1. Dans le AWS Management Console, choisissez votre nom d'utilisateur dans la barre de navigation en haut à droite. Cela ressemble généralement à ceci : ***username*@ *account\$1ID\$1number\$1or\$1alias***. 1. Choisissez l’une des méthodes suivantes pour changer de rôle : + Choisissez **Changer de rôle**. + Si vous avez opté pour la prise en charge multi-session, choisissez **Ajouter une session** et sélectionnez **Changer de rôle**. **Note** Vous pouvez vous connecter à un maximum de cinq identités différentes simultanément dans un seul navigateur Web dans l’ AWS Management Console. Pour plus de détails, consultez la section [Connexion à plusieurs comptes](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html) dans le *Guide de démarrage AWS Management Console *. 1. Dans la page **Switch Role (Changer de rôle)**, entrez l'ID ou l'alias de compte, ainsi que le nom du rôle que vous a fourni l'administrateur. **Note** Si l'administrateur a créé le rôle avec un chemin d'accès tel que `division_abc/subdivision_efg/roleToDoX`, vous devez entrer le chemin d'accès complet et le nom dans le champ **Rôle**. Si vous entrez uniquement le nom du rôle, ou si l'ensemble de `Path` et `RoleName` dépasse 64 caractères, le changement de rôle échoue. Cette restriction est imposée par les cookies du navigateur dans lesquels est stocké le nom du rôle. Dans ce cas, contactez votre administrateur et demandez-lui de réduire la taille du chemin d'accès et le nom du rôle. 1. (Facultatif) Vous pouvez saisir un nom d’affichage et sélectionner une couleur d’affichage qui mettra en évidence le rôle dans la barre de navigation de la console. + Pour **Nom d’affichage**, saisissez le texte que vous voulez afficher sur la barre de navigation à la place de votre nom utilisateur lorsque le rôle est actif. Un nom, basé sur les informations du compte et du rôle, est suggéré, mais vous pouvez le modifier à votre convenance. + Pour **Couleur d’affichage**, sélectionnez une couleur pour mettre en évidence le nom d’affichage. Le nom et la couleur peuvent vous aider à savoir quand le rôle est actif, ce qui modifie vos autorisations. Par exemple, pour un rôle qui vous donne accès à l'environnement de test, vous pouvez spécifier un **Display name** (Nom d'affichage) de **Test** et sélectionner la couleur verte pour **Color**. Pour le rôle qui vous donne accès à la production, vous pouvez spécifier un **Display name** (Nom d'affichage) de **Production** et sélectionner la couleur rouge pour **Color**. 1. Choisissez **Changer de rôle**. Le nom d'affichage et la couleur remplacent votre nom utilisateur sur la barre de navigation et vous pouvez commencer à utiliser les autorisations que le rôle vous accorde. 1. Une fois que vous avez terminé les tâches nécessitant le rôle IAM, vous pouvez revenir à votre session d’origine. Cela supprimera les autorisations supplémentaires fournies par le rôle et vous ramènera à vos autorisations standard. 1. Dans la console IAM, choisissez le nom d'affichage du rôle sous **Display Name (Nom d'affichage)** en haut à droite de la barre de navigation. 1. Choisissez **Revenir**. Par exemple, supposons que vous êtes connecté au numéro de compte `123456789012` à l'aide du nom d'utilisateur `Richard`. Une fois que vous avez utilisé le rôle `admin-role`, vous souhaitez cesser d'utiliser ce rôle et revenir à vos autorisations initiales. Pour arrêter d’utiliser le rôle, sélectionnez **admin-role @ 123456789012**, puis choisissez **Switch back.** ![\[Graphique indiquant la fonction Revenir permettant d’arrêter d’utiliser un rôle IAM et de revenir à l’utilisateur d’origine.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role-stop-using.png) **Astuce** Les derniers rôles utilisés sont répertoriés dans le menu . La prochaine fois que vous voulez endosser l’un de ces rôles, choisissez simplement le rôle souhaité. Il vous suffit de saisir manuellement les informations sur le compte et le rôle si le rôle n’est pas affiché dans le menu. ## Ressources supplémentaires + [Octroi d’autorisations à un utilisateur pour endosser un rôle](id_roles_use_permissions-to-switch.md) + [Accorder à un utilisateur l'autorisation de transmettre un rôle à un AWS service](id_roles_use_passrole.md) + [Créer un rôle pour attribuer des autorisations à un utilisateur IAM](id_roles_create_for-user.md) + [Création d'un rôle pour déléguer des autorisations à un AWS service](id_roles_create_for-service.md) + [Résolution des problèmes liés aux rôles IAM](troubleshoot_roles.md) # Basculer vers un rôle IAM (AWS CLI) Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS dont vous avez besoin. À cet égard, il est semblable à un [utilisateur IAM Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté en tant qu'utilisateur, vous pouvez passer à un rôle. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md). **Important** Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement les autorisations utilisateur et de rôle précédentes et utilisez celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées. Vous pouvez utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'utilisateur IAM. Vous pouvez également utiliser un rôle pour exécuter une AWS CLI commande lorsque vous êtes connecté en tant qu'[utilisateur authentifié de manière externe](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) ou [OIDC](id_roles_providers_oidc.md)) qui utilise déjà un rôle. De plus, vous pouvez utiliser un rôle pour exécuter une commande de la AWS CLI dans une instance Amazon EC2 attachée à un rôle via son profil d'instance. Il n'est pas possible d'assumer un rôle si vous êtes connecté en tant qu' Utilisateur racine d'un compte AWS. [**Chaînage de rôles**](id_roles.md#iam-term-role-chaining) : vous pouvez aussi utiliser le chaînage de rôles, qui utilise les autorisations d'un rôle pour accéder à un second rôle. Par défaut, votre session de rôle dure une heure. Lorsque vous endossez ce rôle à l'aide des opérations de la CLI `assume-role*`, vous pouvez spécifier une valeur pour le paramètre `duration-seconds`. Cette valeur peut être comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Si vous changez de rôle dans la console, la durée de votre session est limitée à une heure. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration). Si vous utilisez la création de chaînes de rôles, la durée de votre session est limitée à une heure maximum. Si vous utilisez ensuite le paramètre `duration-seconds` pour fournir une valeur supérieure à une heure, l'opération échoue. ## Exemple de scénario : passer à un rôle de production Imaginez que vous êtes un utilisateur IAM pour travailler dans l'environnement de développement. Dans ce scénario, vous devez parfois travailler avec l'environnement de production au niveau de la ligne de commande avec l'[AWS CLI](https://aws.amazon.com/cli/). Vous disposez déjà d'un ensemble d'informations d'identification de clé d'accès. Il peut s'agir de la paire de clés d'accès attribuée à votre utilisateur IAM standard. Ou, si vous êtes connecté en tant que principal fédéré SAML ou OIDC, il peut s’agir de la paire de clés d’accès pour le rôle qui vous a été attribué initialement. Si vos autorisations actuelles vous permettent d'assumer un rôle IAM spécifique, vous pouvez identifier ce rôle dans un « profil » des fichiers de AWS CLI configuration. Cette commande est ensuite exécutée avec les autorisations du rôle IAM spécifié, pas l'identité d'origine. Notez que lorsque vous spécifiez ce profil dans une AWS CLI commande, vous utilisez le nouveau rôle. Dans ce cas, vous ne pouvez pas utiliser vos autorisations d'origine dans le compte de développement en même temps. Ceci est dû au fait qu'un seul ensemble d'autorisations peut être actif à la fois. **Note** Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname). **Pour passer à un rôle de production (AWS CLI)** 1. Si vous n'avez jamais utilisé le AWS CLI, vous devez d'abord configurer votre profil CLI par défaut. Ouvrez une invite de commande et configurez votre AWS CLI installation pour utiliser la clé d'accès de votre utilisateur IAM ou de votre rôle fédéré. Pour plus d'informations, veuillez consulter [configuration de l'outil AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration) dans le *guide de l'utilisateur de l'outil AWS Command Line Interface *. Exécutez la commande [aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) comme suit : ``` aws configure ``` Lorsque vous y êtes invité, fournissez les informations suivantes : ``` AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: us-east-2 Default output format [None]: json ``` 1. Créez un profil pour le rôle dans le `.aws/config` fichier Unix ou Linux, ou le fichier `C:\Users\USERNAME\.aws\config` dans Windows. L'exemple suivant crée un profil appelé `prodaccess` qui passe au rôle `ProductionAccessRole` dans le compte `123456789012`. Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. Lorsque ce profil est invoqué, il AWS CLI utilise les informations d'identification du `source_profile` pour demander les informations d'identification du rôle. De ce fait, l'identité référencée en tant que `source_profile` doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`. ``` [profile prodaccess] role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole source_profile = default ``` 1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre est `--profile prodaccess` exécutée sous les autorisations associées au rôle IAM `ProductionAccessRole` plutôt que sous celles de l'utilisateur par défaut. ``` aws iam list-users --profile prodaccess ``` Cette commande fonctionne si les autorisations affectées au rôle `ProductionAccessRole` permettent de répertorier les utilisateurs dans le compte AWS actuel. 1. Pour revenir aux autorisations accordées par vos informations d'identification d'origine, exécutez les commandes sans le paramètre `--profile`. Vous AWS CLI recommencez à utiliser les informations d'identification de votre profil par défaut, que vous avez configuré dans[Step 1](#step-configure-default). Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *. ## Exemple de scénario : permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte Imaginez que vous en utilisiez deux Comptes AWS et que vous souhaitiez autoriser une application exécutée sur une instance Amazon EC2 à exécuter des [AWS CLI](https://aws.amazon.com/cli/)commandes dans les deux comptes. Supposons que l'instance EC2 existe dans le compte `111111111111`. Cette instance inclut le rôle de profil d'instance `abcd` qui permet à l'appli d'effectuer les tâches Amazon S3 `amzn-s3-demo-bucket1` en lecture seule sur le compartiment dans le même compte `111111111111`. Toutefois, l'application doit également être autorisée à endosser le rôle `efgh` entre comptes pour effectuer des tâches dans le compte `222222222222`. Pour ce faire, le rôle de profil d'instance EC2 `abcd` doit disposer des autorisations suivantes : ***Politique d'autorisations de rôle `abcd` du compte 111111111111*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1/*", "arn:aws:s3:::amzn-s3-demo-bucket1" ] }, { "Sid": "AllowIPToAssumeCrossAccountRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/efgh" } ] } ``` ------ Supposons que le rôle `efgh` entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment `amzn-s3-demo-bucket2` dans le même compte `222222222222`. Pour ce faire, le rôle `efgh` entre comptes doit avoir la politique d'autorisations suivante : ***Politique d'autorisations de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket2/*", "arn:aws:s3:::amzn-s3-demo-bucket2" ] } ] } ``` ------ Le rôle `efgh` doit autoriser le rôle de profil d'instance `abcd` à l'endosser. Pour ce faire, le rôle `efgh` doit avoir la politique de confiance suivante : ***Politique de confiance de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "efghTrustPolicy", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"} } ] } ``` ------ Pour exécuter ensuite AWS CLI les commandes dans le compte`222222222222`, vous devez mettre à jour le fichier de configuration de la CLI. Identifiez le rôle `efgh` en tant que « profil » et le rôle de profil d'instance EC2 `abcd` en tant que « source » d'informations d'identification dans le fichier de configuration d' AWS CLI . Ensuite, vos commandes de CLI sont exécutées avec les autorisations du rôle `efgh`, pas du rôle `abcd` d'origine. **Note** Pour des raisons de sécurité, vous pouvez AWS CloudTrail vérifier l'utilisation des rôles dans le compte. Pour différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux dans les CloudTrail journaux, vous pouvez utiliser le nom de session du rôle. Lorsque le AWS CLI assume un rôle au nom d'un utilisateur tel que décrit dans cette rubrique, un nom de session de rôle est automatiquement créé sous le nom de`AWS-CLI-session-nnnnnnnn`. *nnnnnnnn*Voici un entier qui représente l'heure en temps d'[époque Unix](http://wikipedia.org/wiki/Unix_time) (le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970). Pour plus d'informations, consultez la section [Référence aux CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le *guide de AWS CloudTrail l'utilisateur*. **Pour autoriser un rôle de profil d'instance EC2 afin de passer à un rôle entre comptes (AWS CLI)** 1. Vous n'avez pas besoin de configurer un profil par défaut pour la CLI. Au lieu de cela, vous pouvez charger les informations d'identification à partir des métadonnées du profil d'instance EC2. Créez un profil pour le rôle dans le fichier `.aws/config`. L'exemple suivant crée un profil `instancecrossaccount` qui passe au rôle `efgh` dans le compte `222222222222`. Lorsque ce profil est appelé, l’interface AWS CLI utilise les informations d'identification des métadonnées du profil d'instance EC2 pour demander les informations d'identification du rôle. De ce fait, le rôle de profil d'instance EC2 doit disposer des autorisations `sts:AssumeRole` pour le rôle spécifié dans le `role_arn`. ``` [profile instancecrossaccount] role_arn = arn:aws:iam::222222222222:role/efgh credential_source = Ec2InstanceMetadata ``` 1. Après avoir créé le nouveau profil, toute AWS CLI commande spécifiant le paramètre `--profile instancecrossaccount` s'exécute sous les autorisations associées au `efgh` rôle dans le compte`222222222222`. ``` aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount ``` Cette commande fonctionne si les autorisations affectées au rôle `efgh` autorisent à répertorier les utilisateurs dans l' Compte AWS actuel. 1. Pour revenir au profil d'instance EC2 d'origine les autorisations de compte `111111111111`, exécutez les commandes de CLI sans le paramètre `--profile`. Pour plus d'informations, consultez [Endossement d'un rôle](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) dans le *Guide de l'utilisateur AWS Command Line Interface *. # Basculer vers un rôle IAM (Outils pour Windows PowerShell) Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS dont vous avez besoin. À cet égard, il est semblable à un [utilisateur IAM Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté, vous pouvez endosser un rôle. Ceci annule temporairement vos autorisations utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). **Important** Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement vos autorisations utilisateur et travaillez avec celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont automatiquement restaurées. Cette section décrit comment changer de rôles lorsque vous utilisez la ligne de commande avec AWS Tools for Windows PowerShell. Imaginez que vous disposez d'un compte dans l'environnement de développement et que vous deviez parfois travailler avec l'environnement de production en ligne de commande à l'aide [des outils pour Windows PowerShell](https://aws.amazon.com/powershell/). Un ensemble d'informations d'identification de clé d'accès est déjà à votre disposition. Il peut s'agir de la paire de clés d'accès attribuée à votre utilisateur IAM standard. Ou, si vous êtes connecté en tant que principal fédéré SAML ou OIDC, il peut s’agir de la paire de clés d’accès pour le rôle qui vous a été attribué initialement. Ces informations d'identification vous permettent d'exécuter le cmdlet `Use-STSRole` qui transmet l'ARN d'un nouveau rôle en tant que paramètre. Cette commande renvoie es informations d'identification de sécurité temporaires du rôle demandé. Vous pouvez ensuite utiliser ces informations d'identification dans PowerShell les commandes suivantes avec les autorisations du rôle pour accéder aux ressources en production. Bien que vous utilisiez ce rôle, vous ne pouvez pas utiliser vos autorisations d'utilisateur dans le compte Développement, car un seul ensemble d'autorisations est en vigueur à la fois. **Note** Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname). 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 passer à un rôle (Outils pour Windows PowerShell)** 1. Ouvrez une invite de PowerShell commande et configurez le profil par défaut pour utiliser la clé d'accès de votre utilisateur IAM actuel ou de votre rôle fédéré. Si vous avez déjà utilisé les outils pour Windows PowerShell, cela est probablement déjà fait. Notez que vous ne pouvez changer de rôle que si vous êtes connecté en tant qu'utilisateur IAM, et non en tant que Utilisateur racine d'un compte AWS. ``` PS C:\> Set-AWSCredentials -AccessKey AKIAIOSFODNN7EXAMPLE -SecretKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -StoreAs MyMainUserProfile PS C:\> Initialize-AWSDefaults -ProfileName MyMainUserProfile -Region us-east-2 ``` Pour plus d'informations, consultez la section [Utilisation des AWS informations d'identification](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html) dans le *guide de Outils AWS pour PowerShell l'utilisateur*. 1. Pour récupérer les informations d'identification du nouveau rôle, exécutez la commande suivante pour passer au rôle `RoleName` dans le compte 123456789012. Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. La commande nécessite que vous fournissiez un nom de session également. Pour cela, n'importe quel texte fera l'affaire. La commande suivante demande les informations d'identification et capture l'objet de propriété `Credentials` dans l'objet des résultats renvoyés et le stocke dans la variable `$Creds`. ``` PS C:\> $Creds = (Use-STSRole -RoleArn "arn:aws:iam::123456789012:role/RoleName" -RoleSessionName "MyRoleSessionName").Credentials ``` `$Creds` est un objet qui contient à présent les éléments `AccessKeyId`, `SecretAccessKey` et `SessionToken` dont vous avez besoin dans la procédure suivante. Les exemples de commandes suivants illustrent les valeurs habituelles. ``` PS C:\> $Creds.AccessKeyId AKIAIOSFODNN7EXAMPLE PS C:\> $Creds.SecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY PS C:\> $Creds.SessionToken AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRp XviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPy Oj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UuysgsKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/C s8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87eNhyDHq6ikBQ== PS C:\> $Creds.Expiration Thursday, June 18, 2018 2:28:31 PM ``` 1. Pour utiliser ces informations d'identification dans n'importe quelle commande suivante, incluez-les dans le paramètre `-Credential`. Par exemple, la commande suivante utilise les informations d'identification du rôle et fonctionne uniquement si le rôle a l'autorisation `iam:ListRoles` et peut donc exécuter le cmdlet `Get-IAMRoles` : ``` PS C:\> get-iamroles -Credential $Creds ``` 1. Pour revenir à vos informations d'identification d'origine, arrêtez simplement d'utiliser le `-Credentials $Creds` paramètre et PowerShell autorisez le retour aux informations d'identification stockées dans le profil par défaut. # Basculer vers un rôle IAM (AWS API) Un *rôle* spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources AWS . À cet égard, il est semblable à un [utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html). Un principal (personne ou application) assume le rôle de recevoir des autorisations temporaires pour effectuer les tâches requises et interagir avec les AWS ressources. Le rôle peut être dans votre propre compte ou dans un autre Compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les créer et de les configurer, consultez [Rôles IAM](id_roles.md) et [Création d’un rôle IAM](id_roles_create.md). Pour connaître les différentes méthodes que vous pouvez utiliser pour endosser un rôle, consultez [Méthodes pour assumer un rôle](id_roles_manage-assume.md). **Important** Les autorisations de votre utilisateur IAM et des rôles que vous endossez ne peuvent pas être cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous endossez un rôle, vous abandonnez temporairement les autorisations utilisateur et de rôle précédentes et utilisez celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations originales sont automatiquement restaurées. Pour assumer un rôle, une application appelle l'opération AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API et transmet l'ARN du rôle à utiliser. L'opération crée une nouvelle session avec des informations d'identification temporaires. Cette session possède les mêmes autorisations que les politiques basées sur une identité pour ce rôle. Lorsque vous appelez [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), vous pouvez, si vous le souhaitez, transmettre des [politiques de session](access_policies.md#policies_session) en ligne ou gérées. Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètre lorsque vous créez par programmation une session d’informations d’identification temporaires pour un rôle ou une session utilisateur fédérée. Vous pouvez transmettre un seul document de politique de session en ligne JSON à l'aide du paramètre `Policy`. Vous pouvez utiliser le paramètre `PolicyArns` pour spécifier jusqu'à 10 politiques de session gérées. Les autorisations de la session obtenues sont une combinaison des stratégies basées sur l'identité de l'entité et des stratégies de session. Les politiques de session s'avèrent utiles lorsque vous devez fournir les informations d'identification temporaires du rôle à une autre personne. Cette dernière peut utiliser les informations d'identification temporaires du rôle dans les appels d'API AWS suivants pour accéder aux ressources du compte qui possède le rôle. Vous ne pouvez pas utiliser les politiques de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité. Pour en savoir plus sur la manière de AWS déterminer les autorisations effectives d'un rôle, consultez[Logique d'évaluation de politiques](reference_policies_evaluation-logic.md). ![\[PermissionsWhenPassingRoles_Schéma\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role_passed_policy_permissions.png) Vous pouvez appeler `AssumeRole` lorsque vous êtes connecté en tant qu’utilisateur IAM ou en tant qu’[utilisateur authentifié en externe](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) ou [OIDC](id_roles_providers_oidc.md)) utilisant déjà un rôle. Vous pouvez également utiliser la [*création de chaînes de rôles*](id_roles.md#iam-term-role-chaining), qui utilise un rôle pour endosser un deuxième rôle. Il n'est pas possible d'assumer un rôle si vous êtes connecté en tant qu' Utilisateur racine d'un compte AWS. Par défaut, votre session de rôle dure une heure. Lorsque vous assumez ce rôle à l'aide des opérations d' AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API, vous pouvez spécifier une valeur pour le `DurationSeconds` paramètre. Cette valeur peut être comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter [Mettre à jour la durée de session maximale pour un rôle](id_roles_update-role-settings.md#id_roles_update-session-duration). Si vous utilisez la création de chaînes de rôles, votre session est limitée à une durée maximale d'une heure. Si vous utilisez ensuite le paramètre `DurationSeconds` pour fournir une valeur supérieure à une heure, l'opération échoue. **Note** Pour des raisons de sécurité, les administrateurs peuvent [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Votre administrateur peut exiger que vous spécifiiez une identité source ou un nom de session de rôle lorsque vous endossez le rôle. Pour plus d’informations, consultez [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) et [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname). Les exemples de code suivants montrent comment créer un utilisateur et assumer un rôle. **Avertissement** Afin d’éviter les risques de sécurité, n’employez pas les utilisateurs IAM pour l’authentification lorsque vous développez des logiciels spécialisés ou lorsque vous travaillez avec des données réelles. Préférez la fédération avec un fournisseur d’identité tel que [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). + Créer un utilisateur sans autorisation. + Créer un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3 pour le compte. + Ajouter une politique pour permettre à l’utilisateur d’assumer le rôle. + Assumez le rôle et répertorier les compartiments S3 à l’aide d’informations d’identification temporaires, puis nettoyez les ressources. ------ #### [ .NET ] **SDK pour .NET** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/IAM#code-examples). ``` global using Amazon.IdentityManagement; global using Amazon.S3; global using Amazon.SecurityToken; global using IAMActions; global using IamScenariosCommon; global using Microsoft.Extensions.DependencyInjection; global using Microsoft.Extensions.Hosting; global using Microsoft.Extensions.Logging; global using Microsoft.Extensions.Logging.Console; global using Microsoft.Extensions.Logging.Debug; namespace IAMActions; public class IAMWrapper { private readonly IAmazonIdentityManagementService _IAMService; /// /// Constructor for the IAMWrapper class. /// /// An IAM client object. public IAMWrapper(IAmazonIdentityManagementService IAMService) { _IAMService = IAMService; } /// /// Attach an IAM policy to a role. /// /// The policy to attach. /// The role that the policy will be attached to. /// A Boolean value indicating the success of the action. public async Task AttachRolePolicyAsync(string policyArn, string roleName) { var response = await _IAMService.AttachRolePolicyAsync(new AttachRolePolicyRequest { PolicyArn = policyArn, RoleName = roleName, }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Create an IAM access key for a user. /// /// The username for which to create the IAM access /// key. /// The AccessKey. public async Task CreateAccessKeyAsync(string userName) { var response = await _IAMService.CreateAccessKeyAsync(new CreateAccessKeyRequest { UserName = userName, }); return response.AccessKey; } /// /// Create an IAM policy. /// /// The name to give the new IAM policy. /// The policy document for the new policy. /// The new IAM policy object. public async Task CreatePolicyAsync(string policyName, string policyDocument) { var response = await _IAMService.CreatePolicyAsync(new CreatePolicyRequest { PolicyDocument = policyDocument, PolicyName = policyName, }); return response.Policy; } /// /// Create a new IAM role. /// /// The name of the IAM role. /// The name of the IAM policy document /// for the new role. /// The Amazon Resource Name (ARN) of the role. public async Task CreateRoleAsync(string roleName, string rolePolicyDocument) { var request = new CreateRoleRequest { RoleName = roleName, AssumeRolePolicyDocument = rolePolicyDocument, }; var response = await _IAMService.CreateRoleAsync(request); return response.Role.Arn; } /// /// Create an IAM service-linked role. /// /// The name of the AWS Service. /// A description of the IAM service-linked role. /// The IAM role that was created. public async Task CreateServiceLinkedRoleAsync(string serviceName, string description) { var request = new CreateServiceLinkedRoleRequest { AWSServiceName = serviceName, Description = description }; var response = await _IAMService.CreateServiceLinkedRoleAsync(request); return response.Role; } /// /// Create an IAM user. /// /// The username for the new IAM user. /// The IAM user that was created. public async Task CreateUserAsync(string userName) { var response = await _IAMService.CreateUserAsync(new CreateUserRequest { UserName = userName }); return response.User; } /// /// Delete an IAM user's access key. /// /// The Id for the IAM access key. /// The username of the user that owns the IAM /// access key. /// A Boolean value indicating the success of the action. public async Task DeleteAccessKeyAsync(string accessKeyId, string userName) { var response = await _IAMService.DeleteAccessKeyAsync(new DeleteAccessKeyRequest { AccessKeyId = accessKeyId, UserName = userName, }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Delete an IAM policy. /// /// The Amazon Resource Name (ARN) of the policy to /// delete. /// A Boolean value indicating the success of the action. public async Task DeletePolicyAsync(string policyArn) { var response = await _IAMService.DeletePolicyAsync(new DeletePolicyRequest { PolicyArn = policyArn }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Delete an IAM role. /// /// The name of the IAM role to delete. /// A Boolean value indicating the success of the action. public async Task DeleteRoleAsync(string roleName) { var response = await _IAMService.DeleteRoleAsync(new DeleteRoleRequest { RoleName = roleName }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Delete an IAM role policy. /// /// The name of the IAM role. /// The name of the IAM role policy to delete. /// A Boolean value indicating the success of the action. public async Task DeleteRolePolicyAsync(string roleName, string policyName) { var response = await _IAMService.DeleteRolePolicyAsync(new DeleteRolePolicyRequest { PolicyName = policyName, RoleName = roleName, }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Delete an IAM user. /// /// The username of the IAM user to delete. /// A Boolean value indicating the success of the action. public async Task DeleteUserAsync(string userName) { var response = await _IAMService.DeleteUserAsync(new DeleteUserRequest { UserName = userName }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Delete an IAM user policy. /// /// The name of the IAM policy to delete. /// The username of the IAM user. /// A Boolean value indicating the success of the action. public async Task DeleteUserPolicyAsync(string policyName, string userName) { var response = await _IAMService.DeleteUserPolicyAsync(new DeleteUserPolicyRequest { PolicyName = policyName, UserName = userName }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Detach an IAM policy from an IAM role. /// /// The Amazon Resource Name (ARN) of the IAM policy. /// The name of the IAM role. /// A Boolean value indicating the success of the action. public async Task DetachRolePolicyAsync(string policyArn, string roleName) { var response = await _IAMService.DetachRolePolicyAsync(new DetachRolePolicyRequest { PolicyArn = policyArn, RoleName = roleName, }); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Gets the IAM password policy for an AWS account. /// /// The PasswordPolicy for the AWS account. public async Task GetAccountPasswordPolicyAsync() { var response = await _IAMService.GetAccountPasswordPolicyAsync(new GetAccountPasswordPolicyRequest()); return response.PasswordPolicy; } /// /// Get information about an IAM policy. /// /// The IAM policy to retrieve information for. /// The IAM policy. public async Task GetPolicyAsync(string policyArn) { var response = await _IAMService.GetPolicyAsync(new GetPolicyRequest { PolicyArn = policyArn }); return response.Policy; } /// /// Get information about an IAM role. /// /// The name of the IAM role to retrieve information /// for. /// The IAM role that was retrieved. public async Task GetRoleAsync(string roleName) { var response = await _IAMService.GetRoleAsync(new GetRoleRequest { RoleName = roleName, }); return response.Role; } /// /// Get information about an IAM user. /// /// The username of the user. /// An IAM user object. public async Task GetUserAsync(string userName) { var response = await _IAMService.GetUserAsync(new GetUserRequest { UserName = userName }); return response.User; } /// /// List the IAM role policies that are attached to an IAM role. /// /// The IAM role to list IAM policies for. /// A list of the IAM policies attached to the IAM role. public async Task> ListAttachedRolePoliciesAsync(string roleName) { var attachedPolicies = new List(); var attachedRolePoliciesPaginator = _IAMService.Paginators.ListAttachedRolePolicies(new ListAttachedRolePoliciesRequest { RoleName = roleName }); await foreach (var response in attachedRolePoliciesPaginator.Responses) { attachedPolicies.AddRange(response.AttachedPolicies); } return attachedPolicies; } /// /// List IAM groups. /// /// A list of IAM groups. public async Task> ListGroupsAsync() { var groupsPaginator = _IAMService.Paginators.ListGroups(new ListGroupsRequest()); var groups = new List(); await foreach (var response in groupsPaginator.Responses) { groups.AddRange(response.Groups); } return groups; } /// /// List IAM policies. /// /// A list of the IAM policies. public async Task> ListPoliciesAsync() { var listPoliciesPaginator = _IAMService.Paginators.ListPolicies(new ListPoliciesRequest()); var policies = new List(); await foreach (var response in listPoliciesPaginator.Responses) { policies.AddRange(response.Policies); } return policies; } /// /// List IAM role policies. /// /// The IAM role for which to list IAM policies. /// A list of IAM policy names. public async Task> ListRolePoliciesAsync(string roleName) { var listRolePoliciesPaginator = _IAMService.Paginators.ListRolePolicies(new ListRolePoliciesRequest { RoleName = roleName }); var policyNames = new List(); await foreach (var response in listRolePoliciesPaginator.Responses) { policyNames.AddRange(response.PolicyNames); } return policyNames; } /// /// List IAM roles. /// /// A list of IAM roles. public async Task> ListRolesAsync() { var listRolesPaginator = _IAMService.Paginators.ListRoles(new ListRolesRequest()); var roles = new List(); await foreach (var response in listRolesPaginator.Responses) { roles.AddRange(response.Roles); } return roles; } /// /// List SAML authentication providers. /// /// A list of SAML providers. public async Task> ListSAMLProvidersAsync() { var response = await _IAMService.ListSAMLProvidersAsync(new ListSAMLProvidersRequest()); return response.SAMLProviderList; } /// /// List IAM users. /// /// A list of IAM users. public async Task> ListUsersAsync() { var listUsersPaginator = _IAMService.Paginators.ListUsers(new ListUsersRequest()); var users = new List(); await foreach (var response in listUsersPaginator.Responses) { users.AddRange(response.Users); } return users; } /// /// Update the inline policy document embedded in a role. /// /// The name of the policy to embed. /// The name of the role to update. /// The policy document that defines the role. /// A Boolean value indicating the success of the action. public async Task PutRolePolicyAsync(string policyName, string roleName, string policyDocument) { var request = new PutRolePolicyRequest { PolicyName = policyName, RoleName = roleName, PolicyDocument = policyDocument }; var response = await _IAMService.PutRolePolicyAsync(request); return response.HttpStatusCode == HttpStatusCode.OK; } /// /// Add or update an inline policy document that is embedded in an IAM user. /// /// The name of the IAM user. /// The name of the IAM policy. /// The policy document defining the IAM policy. /// A Boolean value indicating the success of the action. public async Task PutUserPolicyAsync(string userName, string policyName, string policyDocument) { var request = new PutUserPolicyRequest { UserName = userName, PolicyName = policyName, PolicyDocument = policyDocument }; var response = await _IAMService.PutUserPolicyAsync(request); return response.HttpStatusCode == System.Net.HttpStatusCode.OK; } /// /// Wait for a new access key to be ready to use. /// /// The Id of the access key. /// A boolean value indicating the success of the action. public async Task WaitUntilAccessKeyIsReady(string accessKeyId) { var keyReady = false; do { try { var response = await _IAMService.GetAccessKeyLastUsedAsync( new GetAccessKeyLastUsedRequest { AccessKeyId = accessKeyId }); if (response.UserName is not null) { keyReady = true; } } catch (NoSuchEntityException) { keyReady = false; } } while (!keyReady); return keyReady; } } using Microsoft.Extensions.Configuration; namespace IAMBasics; public class IAMBasics { private static ILogger logger = null!; static async Task Main(string[] args) { // Set up dependency injection for the AWS service. using var host = Host.CreateDefaultBuilder(args) .ConfigureLogging(logging => logging.AddFilter("System", LogLevel.Debug) .AddFilter("Microsoft", LogLevel.Information) .AddFilter("Microsoft", LogLevel.Trace)) .ConfigureServices((_, services) => services.AddAWSService() .AddTransient() .AddTransient() ) .Build(); logger = LoggerFactory.Create(builder => { builder.AddConsole(); }) .CreateLogger(); IConfiguration configuration = new ConfigurationBuilder() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("settings.json") // Load test settings from .json file. .AddJsonFile("settings.local.json", true) // Optionally load local settings. .Build(); // Values needed for user, role, and policies. string userName = configuration["UserName"]!; string s3PolicyName = configuration["S3PolicyName"]!; string roleName = configuration["RoleName"]!; var iamWrapper = host.Services.GetRequiredService(); var uiWrapper = host.Services.GetRequiredService(); uiWrapper.DisplayBasicsOverview(); uiWrapper.PressEnter(); // First create a user. By default, the new user has // no permissions. uiWrapper.DisplayTitle("Create User"); Console.WriteLine($"Creating a new user with user name: {userName}."); var user = await iamWrapper.CreateUserAsync(userName); var userArn = user.Arn; Console.WriteLine($"Successfully created user: {userName} with ARN: {userArn}."); uiWrapper.WaitABit(15, "Now let's wait for the user to be ready for use."); // Define a role policy document that allows the new user // to assume the role. string assumeRolePolicyDocument = "{" + "\"Version\": \"2012-10-17\"," + "\"Statement\": [{" + "\"Effect\": \"Allow\"," + "\"Principal\": {" + $" \"AWS\": \"{userArn}\"" + "}," + "\"Action\": \"sts:AssumeRole\"" + "}]" + "}"; // Permissions to list all buckets. string policyDocument = "{" + "\"Version\": \"2012-10-17\"," + " \"Statement\" : [{" + " \"Action\" : [\"s3:ListAllMyBuckets\"]," + " \"Effect\" : \"Allow\"," + " \"Resource\" : \"*\"" + "}]" + "}"; // Create an AccessKey for the user. uiWrapper.DisplayTitle("Create access key"); Console.WriteLine("Now let's create an access key for the new user."); var accessKey = await iamWrapper.CreateAccessKeyAsync(userName); var accessKeyId = accessKey.AccessKeyId; var secretAccessKey = accessKey.SecretAccessKey; Console.WriteLine($"We have created the access key with Access key id: {accessKeyId}."); Console.WriteLine("Now let's wait until the IAM access key is ready to use."); var keyReady = await iamWrapper.WaitUntilAccessKeyIsReady(accessKeyId); // Now try listing the Amazon Simple Storage Service (Amazon S3) // buckets. This should fail at this point because the user doesn't // have permissions to perform this task. uiWrapper.DisplayTitle("Try to display Amazon S3 buckets"); Console.WriteLine("Now let's try to display a list of the user's Amazon S3 buckets."); var s3Client1 = new AmazonS3Client(accessKeyId, secretAccessKey); var stsClient1 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey); var s3Wrapper = new S3Wrapper(s3Client1, stsClient1); var buckets = await s3Wrapper.ListMyBucketsAsync(); Console.WriteLine(buckets is null ? "As expected, the call to list the buckets has returned a null list." : "Something went wrong. This shouldn't have worked."); uiWrapper.PressEnter(); uiWrapper.DisplayTitle("Create IAM role"); Console.WriteLine($"Creating the role: {roleName}"); // Creating an IAM role to allow listing the S3 buckets. A role name // is not case sensitive and must be unique to the account for which it // is created. var roleArn = await iamWrapper.CreateRoleAsync(roleName, assumeRolePolicyDocument); uiWrapper.PressEnter(); // Create a policy with permissions to list S3 buckets. uiWrapper.DisplayTitle("Create IAM policy"); Console.WriteLine($"Creating the policy: {s3PolicyName}"); Console.WriteLine("with permissions to list the Amazon S3 buckets for the account."); var policy = await iamWrapper.CreatePolicyAsync(s3PolicyName, policyDocument); // Wait 15 seconds for the IAM policy to be available. uiWrapper.WaitABit(15, "Waiting for the policy to be available."); // Attach the policy to the role you created earlier. uiWrapper.DisplayTitle("Attach new IAM policy"); Console.WriteLine("Now let's attach the policy to the role."); await iamWrapper.AttachRolePolicyAsync(policy.Arn, roleName); // Wait 15 seconds for the role to be updated. Console.WriteLine(); uiWrapper.WaitABit(15, "Waiting for the policy to be attached."); // Use the AWS Security Token Service (AWS STS) to have the user // assume the role we created. var stsClient2 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey); // Wait for the new credentials to become valid. uiWrapper.WaitABit(10, "Waiting for the credentials to be valid."); var assumedRoleCredentials = await s3Wrapper.AssumeS3RoleAsync("temporary-session", roleArn); // Try again to list the buckets using the client created with // the new user's credentials. This time, it should work. var s3Client2 = new AmazonS3Client(assumedRoleCredentials); s3Wrapper.UpdateClients(s3Client2, stsClient2); buckets = await s3Wrapper.ListMyBucketsAsync(); uiWrapper.DisplayTitle("List Amazon S3 buckets"); Console.WriteLine("This time we should have buckets to list."); if (buckets is not null) { buckets.ForEach(bucket => { Console.WriteLine($"{bucket.BucketName} created: {bucket.CreationDate}"); }); } uiWrapper.PressEnter(); // Now clean up all the resources used in the example. uiWrapper.DisplayTitle("Clean up resources"); Console.WriteLine("Thank you for watching. The IAM Basics demo is complete."); Console.WriteLine("Please wait while we clean up the resources we created."); await iamWrapper.DetachRolePolicyAsync(policy.Arn, roleName); await iamWrapper.DeletePolicyAsync(policy.Arn); await iamWrapper.DeleteRoleAsync(roleName); await iamWrapper.DeleteAccessKeyAsync(accessKeyId, userName); await iamWrapper.DeleteUserAsync(userName); uiWrapper.PressEnter(); Console.WriteLine("All done cleaning up our resources. Thank you for your patience."); } } namespace IamScenariosCommon; using System.Net; /// /// A class to perform Amazon Simple Storage Service (Amazon S3) actions for /// the IAM Basics scenario. /// public class S3Wrapper { private IAmazonS3 _s3Service; private IAmazonSecurityTokenService _stsService; /// /// Constructor for the S3Wrapper class. /// /// An Amazon S3 client object. /// An AWS Security Token Service (AWS STS) /// client object. public S3Wrapper(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService) { _s3Service = s3Service; _stsService = stsService; } /// /// Assumes an AWS Identity and Access Management (IAM) role that allows /// Amazon S3 access for the current session. /// /// A string representing the current session. /// The name of the IAM role to assume. /// Credentials for the newly assumed IAM role. public async Task AssumeS3RoleAsync(string roleSession, string roleToAssume) { // Create the request to use with the AssumeRoleAsync call. var request = new AssumeRoleRequest() { RoleSessionName = roleSession, RoleArn = roleToAssume, }; var response = await _stsService.AssumeRoleAsync(request); return response.Credentials; } /// /// Delete an S3 bucket. /// /// Name of the S3 bucket to delete. /// A Boolean value indicating the success of the action. public async Task DeleteBucketAsync(string bucketName) { var result = await _s3Service.DeleteBucketAsync(new DeleteBucketRequest { BucketName = bucketName }); return result.HttpStatusCode == HttpStatusCode.OK; } /// /// List the buckets that are owned by the user's account. /// /// Async Task. public async Task?> ListMyBucketsAsync() { try { // Get the list of buckets accessible by the new user. var response = await _s3Service.ListBucketsAsync(); return response.Buckets; } catch (AmazonS3Exception ex) { // Something else went wrong. Display the error message. Console.WriteLine($"Error: {ex.Message}"); return null; } } /// /// Create a new S3 bucket. /// /// The name for the new bucket. /// A Boolean value indicating whether the action completed /// successfully. public async Task PutBucketAsync(string bucketName) { var response = await _s3Service.PutBucketAsync(new PutBucketRequest { BucketName = bucketName }); return response.HttpStatusCode == HttpStatusCode.OK; } /// /// Update the client objects with new client objects. This is available /// because the scenario uses the methods of this class without and then /// with the proper permissions to list S3 buckets. /// /// The Amazon S3 client object. /// The AWS STS client object. public void UpdateClients(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService) { _s3Service = s3Service; _stsService = stsService; } } namespace IamScenariosCommon; public class UIWrapper { public readonly string SepBar = new('-', Console.WindowWidth); /// /// Show information about the IAM Groups scenario. /// public void DisplayGroupsOverview() { Console.Clear(); DisplayTitle("Welcome to the IAM Groups Demo"); Console.WriteLine("This example application does the following:"); Console.WriteLine("\t1. Creates an Amazon Identity and Access Management (IAM) group."); Console.WriteLine("\t2. Adds an IAM policy to the IAM group giving it full access to Amazon S3."); Console.WriteLine("\t3. Creates a new IAM user."); Console.WriteLine("\t4. Creates an IAM access key for the user."); Console.WriteLine("\t5. Adds the user to the IAM group."); Console.WriteLine("\t6. Lists the buckets on the account."); Console.WriteLine("\t7. Proves that the user has full Amazon S3 access by creating a bucket."); Console.WriteLine("\t8. List the buckets again to show the new bucket."); Console.WriteLine("\t9. Cleans up all the resources created."); } /// /// Show information about the IAM Basics scenario. /// public void DisplayBasicsOverview() { Console.Clear(); DisplayTitle("Welcome to IAM Basics"); Console.WriteLine("This example application does the following:"); Console.WriteLine("\t1. Creates a user with no permissions."); Console.WriteLine("\t2. Creates a role and policy that grant s3:ListAllMyBuckets permission."); Console.WriteLine("\t3. Grants the user permission to assume the role."); Console.WriteLine("\t4. Creates an S3 client object as the user and tries to list buckets (this will fail)."); Console.WriteLine("\t5. Gets temporary credentials by assuming the role."); Console.WriteLine("\t6. Creates a new S3 client object with the temporary credentials and lists the buckets (this will succeed)."); Console.WriteLine("\t7. Deletes all the resources."); } /// /// Display a message and wait until the user presses enter. /// public void PressEnter() { Console.Write("\nPress to continue. "); _ = Console.ReadLine(); Console.WriteLine(); } /// /// Pad a string with spaces to center it on the console display. /// /// The string to be centered. /// The padded string. public string CenterString(string strToCenter) { var padAmount = (Console.WindowWidth - strToCenter.Length) / 2; var leftPad = new string(' ', padAmount); return $"{leftPad}{strToCenter}"; } /// /// Display a line of hyphens, the centered text of the title, and another /// line of hyphens. /// /// The string to be displayed. public void DisplayTitle(string strTitle) { Console.WriteLine(SepBar); Console.WriteLine(CenterString(strTitle)); Console.WriteLine(SepBar); } /// /// Display a countdown and wait for a number of seconds. /// /// The number of seconds to wait. public void WaitABit(int numSeconds, string msg) { Console.WriteLine(msg); // Wait for the requested number of seconds. for (int i = numSeconds; i > 0; i--) { System.Threading.Thread.Sleep(1000); Console.Write($"{i}..."); } PressEnter(); } } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour .NET *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/PutUserPolicy) ------ #### [ Bash ] **AWS CLI avec le script Bash** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples). ``` ############################################################################### # function iam_create_user_assume_role # # Scenario to create an IAM user, create an IAM role, and apply the role to the user. # # "IAM access" permissions are needed to run this code. # "STS assume role" permissions are needed to run this code. (Note: It might be necessary to # create a custom policy). # # Returns: # 0 - If successful. # 1 - If an error occurred. ############################################################################### function iam_create_user_assume_role() { { if [ "$IAM_OPERATIONS_SOURCED" != "True" ]; then source ./iam_operations.sh fi } echo_repeat "*" 88 echo "Welcome to the IAM create user and assume role demo." echo echo "This demo will create an IAM user, create an IAM role, and apply the role to the user." echo_repeat "*" 88 echo echo -n "Enter a name for a new IAM user: " get_input user_name=$get_input_result local user_arn user_arn=$(iam_create_user -u "$user_name") # shellcheck disable=SC2181 if [[ ${?} == 0 ]]; then echo "Created demo IAM user named $user_name" else errecho "$user_arn" errecho "The user failed to create. This demo will exit." return 1 fi local access_key_response access_key_response=$(iam_create_user_access_key -u "$user_name") # shellcheck disable=SC2181 if [[ ${?} != 0 ]]; then errecho "The access key failed to create. This demo will exit." clean_up "$user_name" return 1 fi IFS=$'\t ' read -r -a access_key_values <<<"$access_key_response" local key_name=${access_key_values[0]} local key_secret=${access_key_values[1]} echo "Created access key named $key_name" echo "Wait 10 seconds for the user to be ready." sleep 10 echo_repeat "*" 88 echo local iam_role_name iam_role_name=$(generate_random_name "test-role") echo "Creating a role named $iam_role_name with user $user_name as the principal." local assume_role_policy_document="{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"$user_arn\"}, \"Action\": \"sts:AssumeRole\" }] }" local role_arn role_arn=$(iam_create_role -n "$iam_role_name" -p "$assume_role_policy_document") # shellcheck disable=SC2181 if [ ${?} == 0 ]; then echo "Created IAM role named $iam_role_name" else errecho "The role failed to create. This demo will exit." clean_up "$user_name" "$key_name" return 1 fi local policy_name policy_name=$(generate_random_name "test-policy") local policy_document="{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"s3:ListAllMyBuckets\", \"Resource\": \"arn:aws:s3:::*\"}]}" local policy_arn policy_arn=$(iam_create_policy -n "$policy_name" -p "$policy_document") # shellcheck disable=SC2181 if [[ ${?} == 0 ]]; then echo "Created IAM policy named $policy_name" else errecho "The policy failed to create." clean_up "$user_name" "$key_name" "$iam_role_name" return 1 fi if (iam_attach_role_policy -n "$iam_role_name" -p "$policy_arn"); then echo "Attached policy $policy_arn to role $iam_role_name" else errecho "The policy failed to attach." clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" return 1 fi local assume_role_policy_document="{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"sts:AssumeRole\", \"Resource\": \"$role_arn\"}]}" local assume_role_policy_name assume_role_policy_name=$(generate_random_name "test-assume-role-") # shellcheck disable=SC2181 local assume_role_policy_arn assume_role_policy_arn=$(iam_create_policy -n "$assume_role_policy_name" -p "$assume_role_policy_document") # shellcheck disable=SC2181 if [ ${?} == 0 ]; then echo "Created IAM policy named $assume_role_policy_name for sts assume role" else errecho "The policy failed to create." clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" return 1 fi echo "Wait 10 seconds to give AWS time to propagate these new resources and connections." sleep 10 echo_repeat "*" 88 echo echo "Try to list buckets without the new user assuming the role." echo_repeat "*" 88 echo # Set the environment variables for the created user. # bashsupport disable=BP2001 export AWS_ACCESS_KEY_ID=$key_name # bashsupport disable=BP2001 export AWS_SECRET_ACCESS_KEY=$key_secret local buckets buckets=$(s3_list_buckets) # shellcheck disable=SC2181 if [ ${?} == 0 ]; then local bucket_count bucket_count=$(echo "$buckets" | wc -w | xargs) echo "There are $bucket_count buckets in the account. This should not have happened." else errecho "Because the role with permissions has not been assumed, listing buckets failed." fi echo echo_repeat "*" 88 echo "Now assume the role $iam_role_name and list the buckets." echo_repeat "*" 88 echo local credentials credentials=$(sts_assume_role -r "$role_arn" -n "AssumeRoleDemoSession") # shellcheck disable=SC2181 if [ ${?} == 0 ]; then echo "Assumed role $iam_role_name" else errecho "Failed to assume role." export AWS_ACCESS_KEY_ID="" export AWS_SECRET_ACCESS_KEY="" clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn" return 1 fi IFS=$'\t ' read -r -a credentials <<<"$credentials" export AWS_ACCESS_KEY_ID=${credentials[0]} export AWS_SECRET_ACCESS_KEY=${credentials[1]} # bashsupport disable=BP2001 export AWS_SESSION_TOKEN=${credentials[2]} buckets=$(s3_list_buckets) # shellcheck disable=SC2181 if [ ${?} == 0 ]; then local bucket_count bucket_count=$(echo "$buckets" | wc -w | xargs) echo "There are $bucket_count buckets in the account. Listing buckets succeeded because of " echo "the assumed role." else errecho "Failed to list buckets. This should not happen." export AWS_ACCESS_KEY_ID="" export AWS_SECRET_ACCESS_KEY="" export AWS_SESSION_TOKEN="" clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn" return 1 fi local result=0 export AWS_ACCESS_KEY_ID="" export AWS_SECRET_ACCESS_KEY="" echo echo_repeat "*" 88 echo "The created resources will now be deleted." echo_repeat "*" 88 echo clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn" # shellcheck disable=SC2181 if [[ ${?} -ne 0 ]]; then result=1 fi return $result } ``` Fonctions IAM utilisées dans ce scénario. ``` ############################################################################### # function iam_user_exists # # This function checks to see if the specified AWS Identity and Access Management (IAM) user already exists. # # Parameters: # $1 - The name of the IAM user to check. # # Returns: # 0 - If the user already exists. # 1 - If the user doesn't exist. ############################################################################### function iam_user_exists() { local user_name user_name=$1 # Check whether the IAM user already exists. # We suppress all output - we're interested only in the return code. local errors errors=$(aws iam get-user \ --user-name "$user_name" 2>&1 >/dev/null) local error_code=${?} if [[ $error_code -eq 0 ]]; then return 0 # 0 in Bash script means true. else if [[ $errors != *"error"*"(NoSuchEntity)"* ]]; then aws_cli_error_log $error_code errecho "Error calling iam get-user $errors" fi return 1 # 1 in Bash script means false. fi } ############################################################################### # function iam_create_user # # This function creates the specified IAM user, unless # it already exists. # # Parameters: # -u user_name -- The name of the user to create. # # Returns: # The ARN of the user. # And: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_create_user() { local user_name response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_create_user" echo "Creates an AWS Identity and Access Management (IAM) user. You must supply a username:" echo " -u user_name The name of the user. It must be unique within the account." echo "" } # Retrieve the calling parameters. while getopts "u:h" option; do case "${option}" in u) user_name="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$user_name" ]]; then errecho "ERROR: You must provide a username with the -u parameter." usage return 1 fi iecho "Parameters:\n" iecho " User name: $user_name" iecho "" # If the user already exists, we don't want to try to create it. if (iam_user_exists "$user_name"); then errecho "ERROR: A user with that name already exists in the account." return 1 fi response=$(aws iam create-user --user-name "$user_name" \ --output text \ --query 'User.Arn') local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports create-user operation failed.$response" return 1 fi echo "$response" return 0 } ############################################################################### # function iam_create_user_access_key # # This function creates an IAM access key for the specified user. # # Parameters: # -u user_name -- The name of the IAM user. # [-f file_name] -- The optional file name for the access key output. # # Returns: # [access_key_id access_key_secret] # And: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_create_user_access_key() { local user_name file_name response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_create_user_access_key" echo "Creates an AWS Identity and Access Management (IAM) key pair." echo " -u user_name The name of the IAM user." echo " [-f file_name] Optional file name for the access key output." echo "" } # Retrieve the calling parameters. while getopts "u:f:h" option; do case "${option}" in u) user_name="${OPTARG}" ;; f) file_name="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$user_name" ]]; then errecho "ERROR: You must provide a username with the -u parameter." usage return 1 fi response=$(aws iam create-access-key \ --user-name "$user_name" \ --output text) local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports create-access-key operation failed.$response" return 1 fi if [[ -n "$file_name" ]]; then echo "$response" >"$file_name" fi local key_id key_secret # shellcheck disable=SC2086 key_id=$(echo $response | cut -f 2 -d ' ') # shellcheck disable=SC2086 key_secret=$(echo $response | cut -f 4 -d ' ') echo "$key_id $key_secret" return 0 } ############################################################################### # function iam_create_role # # This function creates an IAM role. # # Parameters: # -n role_name -- The name of the IAM role. # -p policy_json -- The assume role policy document. # # Returns: # The ARN of the role. # And: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_create_role() { local role_name policy_document response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_create_user_access_key" echo "Creates an AWS Identity and Access Management (IAM) role." echo " -n role_name The name of the IAM role." echo " -p policy_json -- The assume role policy document." echo "" } # Retrieve the calling parameters. while getopts "n:p:h" option; do case "${option}" in n) role_name="${OPTARG}" ;; p) policy_document="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$role_name" ]]; then errecho "ERROR: You must provide a role name with the -n parameter." usage return 1 fi if [[ -z "$policy_document" ]]; then errecho "ERROR: You must provide a policy document with the -p parameter." usage return 1 fi response=$(aws iam create-role \ --role-name "$role_name" \ --assume-role-policy-document "$policy_document" \ --output text \ --query Role.Arn) local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports create-role operation failed.\n$response" return 1 fi echo "$response" return 0 } ############################################################################### # function iam_create_policy # # This function creates an IAM policy. # # Parameters: # -n policy_name -- The name of the IAM policy. # -p policy_json -- The policy document. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_create_policy() { local policy_name policy_document response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_create_policy" echo "Creates an AWS Identity and Access Management (IAM) policy." echo " -n policy_name The name of the IAM policy." echo " -p policy_json -- The policy document." echo "" } # Retrieve the calling parameters. while getopts "n:p:h" option; do case "${option}" in n) policy_name="${OPTARG}" ;; p) policy_document="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$policy_name" ]]; then errecho "ERROR: You must provide a policy name with the -n parameter." usage return 1 fi if [[ -z "$policy_document" ]]; then errecho "ERROR: You must provide a policy document with the -p parameter." usage return 1 fi response=$(aws iam create-policy \ --policy-name "$policy_name" \ --policy-document "$policy_document" \ --output text \ --query Policy.Arn) local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports create-policy operation failed.\n$response" return 1 fi echo "$response" } ############################################################################### # function iam_attach_role_policy # # This function attaches an IAM policy to a tole. # # Parameters: # -n role_name -- The name of the IAM role. # -p policy_ARN -- The IAM policy document ARN.. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_attach_role_policy() { local role_name policy_arn response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_attach_role_policy" echo "Attaches an AWS Identity and Access Management (IAM) policy to an IAM role." echo " -n role_name The name of the IAM role." echo " -p policy_ARN -- The IAM policy document ARN." echo "" } # Retrieve the calling parameters. while getopts "n:p:h" option; do case "${option}" in n) role_name="${OPTARG}" ;; p) policy_arn="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$role_name" ]]; then errecho "ERROR: You must provide a role name with the -n parameter." usage return 1 fi if [[ -z "$policy_arn" ]]; then errecho "ERROR: You must provide a policy ARN with the -p parameter." usage return 1 fi response=$(aws iam attach-role-policy \ --role-name "$role_name" \ --policy-arn "$policy_arn") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports attach-role-policy operation failed.\n$response" return 1 fi echo "$response" return 0 } ############################################################################### # function iam_detach_role_policy # # This function detaches an IAM policy to a tole. # # Parameters: # -n role_name -- The name of the IAM role. # -p policy_ARN -- The IAM policy document ARN.. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_detach_role_policy() { local role_name policy_arn response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_detach_role_policy" echo "Detaches an AWS Identity and Access Management (IAM) policy to an IAM role." echo " -n role_name The name of the IAM role." echo " -p policy_ARN -- The IAM policy document ARN." echo "" } # Retrieve the calling parameters. while getopts "n:p:h" option; do case "${option}" in n) role_name="${OPTARG}" ;; p) policy_arn="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$role_name" ]]; then errecho "ERROR: You must provide a role name with the -n parameter." usage return 1 fi if [[ -z "$policy_arn" ]]; then errecho "ERROR: You must provide a policy ARN with the -p parameter." usage return 1 fi response=$(aws iam detach-role-policy \ --role-name "$role_name" \ --policy-arn "$policy_arn") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports detach-role-policy operation failed.\n$response" return 1 fi echo "$response" return 0 } ############################################################################### # function iam_delete_policy # # This function deletes an IAM policy. # # Parameters: # -n policy_arn -- The name of the IAM policy arn. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_delete_policy() { local policy_arn response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_delete_policy" echo "Deletes an AWS Identity and Access Management (IAM) policy" echo " -n policy_arn -- The name of the IAM policy arn." echo "" } # Retrieve the calling parameters. while getopts "n:h" option; do case "${option}" in n) policy_arn="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$policy_arn" ]]; then errecho "ERROR: You must provide a policy arn with the -n parameter." usage return 1 fi iecho "Parameters:\n" iecho " Policy arn: $policy_arn" iecho "" response=$(aws iam delete-policy \ --policy-arn "$policy_arn") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports delete-policy operation failed.\n$response" return 1 fi iecho "delete-policy response:$response" iecho return 0 } ############################################################################### # function iam_delete_role # # This function deletes an IAM role. # # Parameters: # -n role_name -- The name of the IAM role. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_delete_role() { local role_name response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_delete_role" echo "Deletes an AWS Identity and Access Management (IAM) role" echo " -n role_name -- The name of the IAM role." echo "" } # Retrieve the calling parameters. while getopts "n:h" option; do case "${option}" in n) role_name="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 echo "role_name:$role_name" if [[ -z "$role_name" ]]; then errecho "ERROR: You must provide a role name with the -n parameter." usage return 1 fi iecho "Parameters:\n" iecho " Role name: $role_name" iecho "" response=$(aws iam delete-role \ --role-name "$role_name") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports delete-role operation failed.\n$response" return 1 fi iecho "delete-role response:$response" iecho return 0 } ############################################################################### # function iam_delete_access_key # # This function deletes an IAM access key for the specified IAM user. # # Parameters: # -u user_name -- The name of the user. # -k access_key -- The access key to delete. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_delete_access_key() { local user_name access_key response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_delete_access_key" echo "Deletes an AWS Identity and Access Management (IAM) access key for the specified IAM user" echo " -u user_name The name of the user." echo " -k access_key The access key to delete." echo "" } # Retrieve the calling parameters. while getopts "u:k:h" option; do case "${option}" in u) user_name="${OPTARG}" ;; k) access_key="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$user_name" ]]; then errecho "ERROR: You must provide a username with the -u parameter." usage return 1 fi if [[ -z "$access_key" ]]; then errecho "ERROR: You must provide an access key with the -k parameter." usage return 1 fi iecho "Parameters:\n" iecho " Username: $user_name" iecho " Access key: $access_key" iecho "" response=$(aws iam delete-access-key \ --user-name "$user_name" \ --access-key-id "$access_key") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports delete-access-key operation failed.\n$response" return 1 fi iecho "delete-access-key response:$response" iecho return 0 } ############################################################################### # function iam_delete_user # # This function deletes the specified IAM user. # # Parameters: # -u user_name -- The name of the user to create. # # Returns: # 0 - If successful. # 1 - If it fails. ############################################################################### function iam_delete_user() { local user_name response local option OPTARG # Required to use getopts command in a function. # bashsupport disable=BP5008 function usage() { echo "function iam_delete_user" echo "Deletes an AWS Identity and Access Management (IAM) user. You must supply a username:" echo " -u user_name The name of the user." echo "" } # Retrieve the calling parameters. while getopts "u:h" option; do case "${option}" in u) user_name="${OPTARG}" ;; h) usage return 0 ;; \?) echo "Invalid parameter" usage return 1 ;; esac done export OPTIND=1 if [[ -z "$user_name" ]]; then errecho "ERROR: You must provide a username with the -u parameter." usage return 1 fi iecho "Parameters:\n" iecho " User name: $user_name" iecho "" # If the user does not exist, we don't want to try to delete it. if (! iam_user_exists "$user_name"); then errecho "ERROR: A user with that name does not exist in the account." return 1 fi response=$(aws iam delete-user \ --user-name "$user_name") local error_code=${?} if [[ $error_code -ne 0 ]]; then aws_cli_error_log $error_code errecho "ERROR: AWS reports delete-user operation failed.$response" return 1 fi iecho "delete-user response:$response" iecho return 0 } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des commandes de l’AWS CLI *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/PutUserPolicy) ------ #### [ C\$1\$1 ] **SDK pour C\$1\$1** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/iam#code-examples). ``` namespace AwsDoc { namespace IAM { //! Cleanup by deleting created entities. /*! \sa DeleteCreatedEntities \param client: IAM client. \param role: IAM role. \param user: IAM user. \param policy: IAM policy. */ static bool DeleteCreatedEntities(const Aws::IAM::IAMClient &client, const Aws::IAM::Model::Role &role, const Aws::IAM::Model::User &user, const Aws::IAM::Model::Policy &policy); } static const int LIST_BUCKETS_WAIT_SEC = 20; static const char ALLOCATION_TAG[] = "example_code"; } //! Scenario to create an IAM user, create an IAM role, and apply the role to the user. // "IAM access" permissions are needed to run this code. // "STS assume role" permissions are needed to run this code. (Note: It might be necessary to // create a custom policy). /*! \sa iamCreateUserAssumeRoleScenario \param clientConfig: Aws client configuration. \return bool: Successful completion. */ bool AwsDoc::IAM::iamCreateUserAssumeRoleScenario( const Aws::Client::ClientConfiguration &clientConfig) { Aws::IAM::IAMClient client(clientConfig); Aws::IAM::Model::User user; Aws::IAM::Model::Role role; Aws::IAM::Model::Policy policy; // 1. Create a user. { Aws::IAM::Model::CreateUserRequest request; Aws::String uuid = Aws::Utils::UUID::RandomUUID(); Aws::String userName = "iam-demo-user-" + Aws::Utils::StringUtils::ToLower(uuid.c_str()); request.SetUserName(userName); Aws::IAM::Model::CreateUserOutcome outcome = client.CreateUser(request); if (!outcome.IsSuccess()) { std::cout << "Error creating IAM user " << userName << ":" << outcome.GetError().GetMessage() << std::endl; return false; } else { std::cout << "Successfully created IAM user " << userName << std::endl; } user = outcome.GetResult().GetUser(); } // 2. Create a role. { // Get the IAM user for the current client in order to access its ARN. Aws::String iamUserArn; { Aws::IAM::Model::GetUserRequest request; Aws::IAM::Model::GetUserOutcome outcome = client.GetUser(request); if (!outcome.IsSuccess()) { std::cerr << "Error getting Iam user. " << outcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } else { std::cout << "Successfully retrieved Iam user " << outcome.GetResult().GetUser().GetUserName() << std::endl; } iamUserArn = outcome.GetResult().GetUser().GetArn(); } Aws::IAM::Model::CreateRoleRequest request; Aws::String uuid = Aws::Utils::UUID::RandomUUID(); Aws::String roleName = "iam-demo-role-" + Aws::Utils::StringUtils::ToLower(uuid.c_str()); request.SetRoleName(roleName); // Build policy document for role. Aws::Utils::Document jsonStatement; jsonStatement.WithString("Effect", "Allow"); Aws::Utils::Document jsonPrincipal; jsonPrincipal.WithString("AWS", iamUserArn); jsonStatement.WithObject("Principal", jsonPrincipal); jsonStatement.WithString("Action", "sts:AssumeRole"); jsonStatement.WithObject("Condition", Aws::Utils::Document()); Aws::Utils::Document policyDocument; policyDocument.WithString("Version", "2012-10-17"); Aws::Utils::Array statements(1); statements[0] = jsonStatement; policyDocument.WithArray("Statement", statements); std::cout << "Setting policy for role\n " << policyDocument.View().WriteCompact() << std::endl; // Set role policy document as JSON string. request.SetAssumeRolePolicyDocument(policyDocument.View().WriteCompact()); Aws::IAM::Model::CreateRoleOutcome outcome = client.CreateRole(request); if (!outcome.IsSuccess()) { std::cerr << "Error creating role. " << outcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } else { std::cout << "Successfully created a role with name " << roleName << std::endl; } role = outcome.GetResult().GetRole(); } // 3. Create an IAM policy. { Aws::IAM::Model::CreatePolicyRequest request; Aws::String uuid = Aws::Utils::UUID::RandomUUID(); Aws::String policyName = "iam-demo-policy-" + Aws::Utils::StringUtils::ToLower(uuid.c_str()); request.SetPolicyName(policyName); // Build IAM policy document. Aws::Utils::Document jsonStatement; jsonStatement.WithString("Effect", "Allow"); jsonStatement.WithString("Action", "s3:ListAllMyBuckets"); jsonStatement.WithString("Resource", "arn:aws:s3:::*"); Aws::Utils::Document policyDocument; policyDocument.WithString("Version", "2012-10-17"); Aws::Utils::Array statements(1); statements[0] = jsonStatement; policyDocument.WithArray("Statement", statements); std::cout << "Creating a policy.\n " << policyDocument.View().WriteCompact() << std::endl; // Set IAM policy document as JSON string. request.SetPolicyDocument(policyDocument.View().WriteCompact()); Aws::IAM::Model::CreatePolicyOutcome outcome = client.CreatePolicy(request); if (!outcome.IsSuccess()) { std::cerr << "Error creating policy. " << outcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } else { std::cout << "Successfully created a policy with name, " << policyName << "." << std::endl; } policy = outcome.GetResult().GetPolicy(); } // 4. Assume the new role using the AWS Security Token Service (STS). Aws::STS::Model::Credentials credentials; { Aws::STS::STSClient stsClient(clientConfig); Aws::STS::Model::AssumeRoleRequest request; request.SetRoleArn(role.GetArn()); Aws::String uuid = Aws::Utils::UUID::RandomUUID(); Aws::String roleSessionName = "iam-demo-role-session-" + Aws::Utils::StringUtils::ToLower(uuid.c_str()); request.SetRoleSessionName(roleSessionName); Aws::STS::Model::AssumeRoleOutcome assumeRoleOutcome; // Repeatedly call AssumeRole, because there is often a delay // before the role is available to be assumed. // Repeat at most 20 times when access is denied. int count = 0; while (true) { assumeRoleOutcome = stsClient.AssumeRole(request); if (!assumeRoleOutcome.IsSuccess()) { if (count > 20 || assumeRoleOutcome.GetError().GetErrorType() != Aws::STS::STSErrors::ACCESS_DENIED) { std::cerr << "Error assuming role after 20 tries. " << assumeRoleOutcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } std::this_thread::sleep_for(std::chrono::seconds(1)); } else { std::cout << "Successfully assumed the role after " << count << " seconds." << std::endl; break; } count++; } credentials = assumeRoleOutcome.GetResult().GetCredentials(); } // 5. List objects in the bucket (This should fail). { Aws::S3::S3Client s3Client( Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(), credentials.GetSecretAccessKey(), credentials.GetSessionToken()), Aws::MakeShared(ALLOCATION_TAG), clientConfig); Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets(); if (!listBucketsOutcome.IsSuccess()) { if (listBucketsOutcome.GetError().GetErrorType() != Aws::S3::S3Errors::ACCESS_DENIED) { std::cerr << "Could not lists buckets. " << listBucketsOutcome.GetError().GetMessage() << std::endl; } else { std::cout << "Access to list buckets denied because privileges have not been applied." << std::endl; } } else { std::cerr << "Successfully retrieved bucket lists when this should not happen." << std::endl; } } // 6. Attach the policy to the role. { Aws::IAM::Model::AttachRolePolicyRequest request; request.SetRoleName(role.GetRoleName()); request.WithPolicyArn(policy.GetArn()); Aws::IAM::Model::AttachRolePolicyOutcome outcome = client.AttachRolePolicy( request); if (!outcome.IsSuccess()) { std::cerr << "Error creating policy. " << outcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } else { std::cout << "Successfully attached the policy with name, " << policy.GetPolicyName() << ", to the role, " << role.GetRoleName() << "." << std::endl; } } int count = 0; // 7. List objects in the bucket (this should succeed). // Repeatedly call ListBuckets, because there is often a delay // before the policy with ListBucket permissions has been applied to the role. // Repeat at most LIST_BUCKETS_WAIT_SEC times when access is denied. while (true) { Aws::S3::S3Client s3Client( Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(), credentials.GetSecretAccessKey(), credentials.GetSessionToken()), Aws::MakeShared(ALLOCATION_TAG), clientConfig); Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets(); if (!listBucketsOutcome.IsSuccess()) { if ((count > LIST_BUCKETS_WAIT_SEC) || listBucketsOutcome.GetError().GetErrorType() != Aws::S3::S3Errors::ACCESS_DENIED) { std::cerr << "Could not lists buckets after " << LIST_BUCKETS_WAIT_SEC << " seconds. " << listBucketsOutcome.GetError().GetMessage() << std::endl; DeleteCreatedEntities(client, role, user, policy); return false; } std::this_thread::sleep_for(std::chrono::seconds(1)); } else { std::cout << "Successfully retrieved bucket lists after " << count << " seconds." << std::endl; break; } count++; } // 8. Delete all the created resources. return DeleteCreatedEntities(client, role, user, policy); } bool AwsDoc::IAM::DeleteCreatedEntities(const Aws::IAM::IAMClient &client, const Aws::IAM::Model::Role &role, const Aws::IAM::Model::User &user, const Aws::IAM::Model::Policy &policy) { bool result = true; if (policy.ArnHasBeenSet()) { // Detach the policy from the role. { Aws::IAM::Model::DetachRolePolicyRequest request; request.SetPolicyArn(policy.GetArn()); request.SetRoleName(role.GetRoleName()); Aws::IAM::Model::DetachRolePolicyOutcome outcome = client.DetachRolePolicy( request); if (!outcome.IsSuccess()) { std::cerr << "Error Detaching policy from roles. " << outcome.GetError().GetMessage() << std::endl; result = false; } else { std::cout << "Successfully detached the policy with arn " << policy.GetArn() << " from role " << role.GetRoleName() << "." << std::endl; } } // Delete the policy. { Aws::IAM::Model::DeletePolicyRequest request; request.WithPolicyArn(policy.GetArn()); Aws::IAM::Model::DeletePolicyOutcome outcome = client.DeletePolicy(request); if (!outcome.IsSuccess()) { std::cerr << "Error deleting policy. " << outcome.GetError().GetMessage() << std::endl; result = false; } else { std::cout << "Successfully deleted the policy with arn " << policy.GetArn() << std::endl; } } } if (role.RoleIdHasBeenSet()) { // Delete the role. Aws::IAM::Model::DeleteRoleRequest request; request.SetRoleName(role.GetRoleName()); Aws::IAM::Model::DeleteRoleOutcome outcome = client.DeleteRole(request); if (!outcome.IsSuccess()) { std::cerr << "Error deleting role. " << outcome.GetError().GetMessage() << std::endl; result = false; } else { std::cout << "Successfully deleted the role with name " << role.GetRoleName() << std::endl; } } if (user.ArnHasBeenSet()) { // Delete the user. Aws::IAM::Model::DeleteUserRequest request; request.WithUserName(user.GetUserName()); Aws::IAM::Model::DeleteUserOutcome outcome = client.DeleteUser(request); if (!outcome.IsSuccess()) { std::cerr << "Error deleting user. " << outcome.GetError().GetMessage() << std::endl; result = false; } else { std::cout << "Successfully deleted the user with name " << user.GetUserName() << std::endl; } } return result; } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour C\$1\$1 *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/PutUserPolicy) ------ #### [ Go ] **Kit SDK pour Go V2** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2/iam#code-examples). Exécutez un scénario interactif à une invite de commande. ``` import ( "context" "errors" "fmt" "log" "math/rand" "strings" "time" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/credentials" "github.com/aws/aws-sdk-go-v2/service/iam" "github.com/aws/aws-sdk-go-v2/service/iam/types" "github.com/aws/aws-sdk-go-v2/service/s3" "github.com/aws/aws-sdk-go-v2/service/sts" "github.com/aws/smithy-go" "github.com/awsdocs/aws-doc-sdk-examples/gov2/demotools" "github.com/awsdocs/aws-doc-sdk-examples/gov2/iam/actions" ) // AssumeRoleScenario shows you how to use the AWS Identity and Access Management (IAM) // service to perform the following actions: // // 1. Create a user who has no permissions. // 2. Create a role that grants permission to list Amazon Simple Storage Service // (Amazon S3) buckets for the account. // 3. Add a policy to let the user assume the role. // 4. Try and fail to list buckets without permissions. // 5. Assume the role and list S3 buckets using temporary credentials. // 6. Delete the policy, role, and user. type AssumeRoleScenario struct { sdkConfig aws.Config accountWrapper actions.AccountWrapper policyWrapper actions.PolicyWrapper roleWrapper actions.RoleWrapper userWrapper actions.UserWrapper questioner demotools.IQuestioner helper IScenarioHelper isTestRun bool } // NewAssumeRoleScenario constructs an AssumeRoleScenario instance from a configuration. // It uses the specified config to get an IAM client and create wrappers for the actions // used in the scenario. func NewAssumeRoleScenario(sdkConfig aws.Config, questioner demotools.IQuestioner, helper IScenarioHelper) AssumeRoleScenario { iamClient := iam.NewFromConfig(sdkConfig) return AssumeRoleScenario{ sdkConfig: sdkConfig, accountWrapper: actions.AccountWrapper{IamClient: iamClient}, policyWrapper: actions.PolicyWrapper{IamClient: iamClient}, roleWrapper: actions.RoleWrapper{IamClient: iamClient}, userWrapper: actions.UserWrapper{IamClient: iamClient}, questioner: questioner, helper: helper, } } // addTestOptions appends the API options specified in the original configuration to // another configuration. This is used to attach the middleware stubber to clients // that are constructed during the scenario, which is needed for unit testing. func (scenario AssumeRoleScenario) addTestOptions(scenarioConfig *aws.Config) { if scenario.isTestRun { scenarioConfig.APIOptions = append(scenarioConfig.APIOptions, scenario.sdkConfig.APIOptions...) } } // Run runs the interactive scenario. func (scenario AssumeRoleScenario) Run(ctx context.Context) { defer func() { if r := recover(); r != nil { log.Printf("Something went wrong with the demo.\n") log.Println(r) } }() log.Println(strings.Repeat("-", 88)) log.Println("Welcome to the AWS Identity and Access Management (IAM) assume role demo.") log.Println(strings.Repeat("-", 88)) user := scenario.CreateUser(ctx) accessKey := scenario.CreateAccessKey(ctx, user) role := scenario.CreateRoleAndPolicies(ctx, user) noPermsConfig := scenario.ListBucketsWithoutPermissions(ctx, accessKey) scenario.ListBucketsWithAssumedRole(ctx, noPermsConfig, role) scenario.Cleanup(ctx, user, role) log.Println(strings.Repeat("-", 88)) log.Println("Thanks for watching!") log.Println(strings.Repeat("-", 88)) } // CreateUser creates a new IAM user. This user has no permissions. func (scenario AssumeRoleScenario) CreateUser(ctx context.Context) *types.User { log.Println("Let's create an example user with no permissions.") userName := scenario.questioner.Ask("Enter a name for the example user:", demotools.NotEmpty{}) user, err := scenario.userWrapper.GetUser(ctx, userName) if err != nil { panic(err) } if user == nil { user, err = scenario.userWrapper.CreateUser(ctx, userName) if err != nil { panic(err) } log.Printf("Created user %v.\n", *user.UserName) } else { log.Printf("User %v already exists.\n", *user.UserName) } log.Println(strings.Repeat("-", 88)) return user } // CreateAccessKey creates an access key for the user. func (scenario AssumeRoleScenario) CreateAccessKey(ctx context.Context, user *types.User) *types.AccessKey { accessKey, err := scenario.userWrapper.CreateAccessKeyPair(ctx, *user.UserName) if err != nil { panic(err) } log.Printf("Created access key %v for your user.", *accessKey.AccessKeyId) log.Println("Waiting a few seconds for your user to be ready...") scenario.helper.Pause(10) log.Println(strings.Repeat("-", 88)) return accessKey } // CreateRoleAndPolicies creates a policy that grants permission to list S3 buckets for // the current account and attaches the policy to a newly created role. It also adds an // inline policy to the specified user that grants the user permission to assume the role. func (scenario AssumeRoleScenario) CreateRoleAndPolicies(ctx context.Context, user *types.User) *types.Role { log.Println("Let's create a role and policy that grant permission to list S3 buckets.") scenario.questioner.Ask("Press Enter when you're ready.") listBucketsRole, err := scenario.roleWrapper.CreateRole(ctx, scenario.helper.GetName(), *user.Arn) if err != nil { panic(err) } log.Printf("Created role %v.\n", *listBucketsRole.RoleName) listBucketsPolicy, err := scenario.policyWrapper.CreatePolicy( ctx, scenario.helper.GetName(), []string{"s3:ListAllMyBuckets"}, "arn:aws:s3:::*") if err != nil { panic(err) } log.Printf("Created policy %v.\n", *listBucketsPolicy.PolicyName) err = scenario.roleWrapper.AttachRolePolicy(ctx, *listBucketsPolicy.Arn, *listBucketsRole.RoleName) if err != nil { panic(err) } log.Printf("Attached policy %v to role %v.\n", *listBucketsPolicy.PolicyName, *listBucketsRole.RoleName) err = scenario.userWrapper.CreateUserPolicy(ctx, *user.UserName, scenario.helper.GetName(), []string{"sts:AssumeRole"}, *listBucketsRole.Arn) if err != nil { panic(err) } log.Printf("Created an inline policy for user %v that lets the user assume the role.\n", *user.UserName) log.Println("Let's give AWS a few seconds to propagate these new resources and connections...") scenario.helper.Pause(10) log.Println(strings.Repeat("-", 88)) return listBucketsRole } // ListBucketsWithoutPermissions creates an Amazon S3 client from the user's access key // credentials and tries to list buckets for the account. Because the user does not have // permission to perform this action, the action fails. func (scenario AssumeRoleScenario) ListBucketsWithoutPermissions(ctx context.Context, accessKey *types.AccessKey) *aws.Config { log.Println("Let's try to list buckets without permissions. This should return an AccessDenied error.") scenario.questioner.Ask("Press Enter when you're ready.") noPermsConfig, err := config.LoadDefaultConfig(ctx, config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider( *accessKey.AccessKeyId, *accessKey.SecretAccessKey, ""), )) if err != nil { panic(err) } // Add test options if this is a test run. This is needed only for testing purposes. scenario.addTestOptions(&noPermsConfig) s3Client := s3.NewFromConfig(noPermsConfig) _, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{}) if err != nil { // The SDK for Go does not model the AccessDenied error, so check ErrorCode directly. var ae smithy.APIError if errors.As(err, &ae) { switch ae.ErrorCode() { case "AccessDenied": log.Println("Got AccessDenied error, which is the expected result because\n" + "the ListBuckets call was made without permissions.") default: log.Println("Expected AccessDenied, got something else.") panic(err) } } } else { log.Println("Expected AccessDenied error when calling ListBuckets without permissions,\n" + "but the call succeeded. Continuing the example anyway...") } log.Println(strings.Repeat("-", 88)) return &noPermsConfig } // ListBucketsWithAssumedRole performs the following actions: // // 1. Creates an AWS Security Token Service (AWS STS) client from the config created from // the user's access key credentials. // 2. Gets temporary credentials by assuming the role that grants permission to list the // buckets. // 3. Creates an Amazon S3 client from the temporary credentials. // 4. Lists buckets for the account. Because the temporary credentials are generated by // assuming the role that grants permission, the action succeeds. func (scenario AssumeRoleScenario) ListBucketsWithAssumedRole(ctx context.Context, noPermsConfig *aws.Config, role *types.Role) { log.Println("Let's assume the role that grants permission to list buckets and try again.") scenario.questioner.Ask("Press Enter when you're ready.") stsClient := sts.NewFromConfig(*noPermsConfig) tempCredentials, err := stsClient.AssumeRole(ctx, &sts.AssumeRoleInput{ RoleArn: role.Arn, RoleSessionName: aws.String("AssumeRoleExampleSession"), DurationSeconds: aws.Int32(900), }) if err != nil { log.Printf("Couldn't assume role %v.\n", *role.RoleName) panic(err) } log.Printf("Assumed role %v, got temporary credentials.\n", *role.RoleName) assumeRoleConfig, err := config.LoadDefaultConfig(ctx, config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider( *tempCredentials.Credentials.AccessKeyId, *tempCredentials.Credentials.SecretAccessKey, *tempCredentials.Credentials.SessionToken), ), ) if err != nil { panic(err) } // Add test options if this is a test run. This is needed only for testing purposes. scenario.addTestOptions(&assumeRoleConfig) s3Client := s3.NewFromConfig(assumeRoleConfig) result, err := s3Client.ListBuckets(ctx, &s3.ListBucketsInput{}) if err != nil { log.Println("Couldn't list buckets with assumed role credentials.") panic(err) } log.Println("Successfully called ListBuckets with assumed role credentials, \n" + "here are some of them:") for i := 0; i < len(result.Buckets) && i < 5; i++ { log.Printf("\t%v\n", *result.Buckets[i].Name) } log.Println(strings.Repeat("-", 88)) } // Cleanup deletes all resources created for the scenario. func (scenario AssumeRoleScenario) Cleanup(ctx context.Context, user *types.User, role *types.Role) { if scenario.questioner.AskBool( "Do you want to delete the resources created for this example? (y/n)", "y", ) { policies, err := scenario.roleWrapper.ListAttachedRolePolicies(ctx, *role.RoleName) if err != nil { panic(err) } for _, policy := range policies { err = scenario.roleWrapper.DetachRolePolicy(ctx, *role.RoleName, *policy.PolicyArn) if err != nil { panic(err) } err = scenario.policyWrapper.DeletePolicy(ctx, *policy.PolicyArn) if err != nil { panic(err) } log.Printf("Detached policy %v from role %v and deleted the policy.\n", *policy.PolicyName, *role.RoleName) } err = scenario.roleWrapper.DeleteRole(ctx, *role.RoleName) if err != nil { panic(err) } log.Printf("Deleted role %v.\n", *role.RoleName) userPols, err := scenario.userWrapper.ListUserPolicies(ctx, *user.UserName) if err != nil { panic(err) } for _, userPol := range userPols { err = scenario.userWrapper.DeleteUserPolicy(ctx, *user.UserName, userPol) if err != nil { panic(err) } log.Printf("Deleted policy %v from user %v.\n", userPol, *user.UserName) } keys, err := scenario.userWrapper.ListAccessKeys(ctx, *user.UserName) if err != nil { panic(err) } for _, key := range keys { err = scenario.userWrapper.DeleteAccessKey(ctx, *user.UserName, *key.AccessKeyId) if err != nil { panic(err) } log.Printf("Deleted access key %v from user %v.\n", *key.AccessKeyId, *user.UserName) } err = scenario.userWrapper.DeleteUser(ctx, *user.UserName) if err != nil { panic(err) } log.Printf("Deleted user %v.\n", *user.UserName) log.Println(strings.Repeat("-", 88)) } } // IScenarioHelper abstracts input and wait functions from a scenario so that they // can be mocked for unit testing. type IScenarioHelper interface { GetName() string Pause(secs int) } const rMax = 100000 type ScenarioHelper struct { Prefix string Random *rand.Rand } // GetName returns a unique name formed of a prefix and a random number. func (helper *ScenarioHelper) GetName() string { return fmt.Sprintf("%v%v", helper.Prefix, helper.Random.Intn(rMax)) } // Pause waits for the specified number of seconds. func (helper ScenarioHelper) Pause(secs int) { time.Sleep(time.Duration(secs) * time.Second) } ``` Définissez une structure qui encapsule les actions du compte. ``` import ( "context" "log" "github.com/aws/aws-sdk-go-v2/service/iam" "github.com/aws/aws-sdk-go-v2/service/iam/types" ) // AccountWrapper encapsulates AWS Identity and Access Management (IAM) account actions // used in the examples. // It contains an IAM service client that is used to perform account actions. type AccountWrapper struct { IamClient *iam.Client } // GetAccountPasswordPolicy gets the account password policy for the current account. // If no policy has been set, a NoSuchEntityException is error is returned. func (wrapper AccountWrapper) GetAccountPasswordPolicy(ctx context.Context) (*types.PasswordPolicy, error) { var pwPolicy *types.PasswordPolicy result, err := wrapper.IamClient.GetAccountPasswordPolicy(ctx, &iam.GetAccountPasswordPolicyInput{}) if err != nil { log.Printf("Couldn't get account password policy. Here's why: %v\n", err) } else { pwPolicy = result.PasswordPolicy } return pwPolicy, err } // ListSAMLProviders gets the SAML providers for the account. func (wrapper AccountWrapper) ListSAMLProviders(ctx context.Context) ([]types.SAMLProviderListEntry, error) { var providers []types.SAMLProviderListEntry result, err := wrapper.IamClient.ListSAMLProviders(ctx, &iam.ListSAMLProvidersInput{}) if err != nil { log.Printf("Couldn't list SAML providers. Here's why: %v\n", err) } else { providers = result.SAMLProviderList } return providers, err } ``` Définissez une structure qui encapsule les actions de la politique. ``` import ( "context" "encoding/json" "log" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/service/iam" "github.com/aws/aws-sdk-go-v2/service/iam/types" ) // PolicyWrapper encapsulates AWS Identity and Access Management (IAM) policy actions // used in the examples. // It contains an IAM service client that is used to perform policy actions. type PolicyWrapper struct { IamClient *iam.Client } // ListPolicies gets up to maxPolicies policies. func (wrapper PolicyWrapper) ListPolicies(ctx context.Context, maxPolicies int32) ([]types.Policy, error) { var policies []types.Policy result, err := wrapper.IamClient.ListPolicies(ctx, &iam.ListPoliciesInput{ MaxItems: aws.Int32(maxPolicies), }) if err != nil { log.Printf("Couldn't list policies. Here's why: %v\n", err) } else { policies = result.Policies } return policies, err } // PolicyDocument defines a policy document as a Go struct that can be serialized // to JSON. type PolicyDocument struct { Version string Statement []PolicyStatement } // PolicyStatement defines a statement in a policy document. type PolicyStatement struct { Effect string Action []string Principal map[string]string `json:",omitempty"` Resource *string `json:",omitempty"` } // CreatePolicy creates a policy that grants a list of actions to the specified resource. // PolicyDocument shows how to work with a policy document as a data structure and // serialize it to JSON by using Go's JSON marshaler. func (wrapper PolicyWrapper) CreatePolicy(ctx context.Context, policyName string, actions []string, resourceArn string) (*types.Policy, error) { var policy *types.Policy policyDoc := PolicyDocument{ Version: "2012-10-17", Statement: []PolicyStatement{{ Effect: "Allow", Action: actions, Resource: aws.String(resourceArn), }}, } policyBytes, err := json.Marshal(policyDoc) if err != nil { log.Printf("Couldn't create policy document for %v. Here's why: %v\n", resourceArn, err) return nil, err } result, err := wrapper.IamClient.CreatePolicy(ctx, &iam.CreatePolicyInput{ PolicyDocument: aws.String(string(policyBytes)), PolicyName: aws.String(policyName), }) if err != nil { log.Printf("Couldn't create policy %v. Here's why: %v\n", policyName, err) } else { policy = result.Policy } return policy, err } // GetPolicy gets data about a policy. func (wrapper PolicyWrapper) GetPolicy(ctx context.Context, policyArn string) (*types.Policy, error) { var policy *types.Policy result, err := wrapper.IamClient.GetPolicy(ctx, &iam.GetPolicyInput{ PolicyArn: aws.String(policyArn), }) if err != nil { log.Printf("Couldn't get policy %v. Here's why: %v\n", policyArn, err) } else { policy = result.Policy } return policy, err } // DeletePolicy deletes a policy. func (wrapper PolicyWrapper) DeletePolicy(ctx context.Context, policyArn string) error { _, err := wrapper.IamClient.DeletePolicy(ctx, &iam.DeletePolicyInput{ PolicyArn: aws.String(policyArn), }) if err != nil { log.Printf("Couldn't delete policy %v. Here's why: %v\n", policyArn, err) } return err } ``` Définissez une structure qui encapsule les actions du rôle. ``` import ( "context" "encoding/json" "log" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/service/iam" "github.com/aws/aws-sdk-go-v2/service/iam/types" ) // RoleWrapper encapsulates AWS Identity and Access Management (IAM) role actions // used in the examples. // It contains an IAM service client that is used to perform role actions. type RoleWrapper struct { IamClient *iam.Client } // ListRoles gets up to maxRoles roles. func (wrapper RoleWrapper) ListRoles(ctx context.Context, maxRoles int32) ([]types.Role, error) { var roles []types.Role result, err := wrapper.IamClient.ListRoles(ctx, &iam.ListRolesInput{MaxItems: aws.Int32(maxRoles)}, ) if err != nil { log.Printf("Couldn't list roles. Here's why: %v\n", err) } else { roles = result.Roles } return roles, err } // CreateRole creates a role that trusts a specified user. The trusted user can assume // the role to acquire its permissions. // PolicyDocument shows how to work with a policy document as a data structure and // serialize it to JSON by using Go's JSON marshaler. func (wrapper RoleWrapper) CreateRole(ctx context.Context, roleName string, trustedUserArn string) (*types.Role, error) { var role *types.Role trustPolicy := PolicyDocument{ Version: "2012-10-17", Statement: []PolicyStatement{{ Effect: "Allow", Principal: map[string]string{"AWS": trustedUserArn}, Action: []string{"sts:AssumeRole"}, }}, } policyBytes, err := json.Marshal(trustPolicy) if err != nil { log.Printf("Couldn't create trust policy for %v. Here's why: %v\n", trustedUserArn, err) return nil, err } result, err := wrapper.IamClient.CreateRole(ctx, &iam.CreateRoleInput{ AssumeRolePolicyDocument: aws.String(string(policyBytes)), RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't create role %v. Here's why: %v\n", roleName, err) } else { role = result.Role } return role, err } // GetRole gets data about a role. func (wrapper RoleWrapper) GetRole(ctx context.Context, roleName string) (*types.Role, error) { var role *types.Role result, err := wrapper.IamClient.GetRole(ctx, &iam.GetRoleInput{RoleName: aws.String(roleName)}) if err != nil { log.Printf("Couldn't get role %v. Here's why: %v\n", roleName, err) } else { role = result.Role } return role, err } // CreateServiceLinkedRole creates a service-linked role that is owned by the specified service. func (wrapper RoleWrapper) CreateServiceLinkedRole(ctx context.Context, serviceName string, description string) ( *types.Role, error) { var role *types.Role result, err := wrapper.IamClient.CreateServiceLinkedRole(ctx, &iam.CreateServiceLinkedRoleInput{ AWSServiceName: aws.String(serviceName), Description: aws.String(description), }) if err != nil { log.Printf("Couldn't create service-linked role %v. Here's why: %v\n", serviceName, err) } else { role = result.Role } return role, err } // DeleteServiceLinkedRole deletes a service-linked role. func (wrapper RoleWrapper) DeleteServiceLinkedRole(ctx context.Context, roleName string) error { _, err := wrapper.IamClient.DeleteServiceLinkedRole(ctx, &iam.DeleteServiceLinkedRoleInput{ RoleName: aws.String(roleName)}, ) if err != nil { log.Printf("Couldn't delete service-linked role %v. Here's why: %v\n", roleName, err) } return err } // AttachRolePolicy attaches a policy to a role. func (wrapper RoleWrapper) AttachRolePolicy(ctx context.Context, policyArn string, roleName string) error { _, err := wrapper.IamClient.AttachRolePolicy(ctx, &iam.AttachRolePolicyInput{ PolicyArn: aws.String(policyArn), RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't attach policy %v to role %v. Here's why: %v\n", policyArn, roleName, err) } return err } // ListAttachedRolePolicies lists the policies that are attached to the specified role. func (wrapper RoleWrapper) ListAttachedRolePolicies(ctx context.Context, roleName string) ([]types.AttachedPolicy, error) { var policies []types.AttachedPolicy result, err := wrapper.IamClient.ListAttachedRolePolicies(ctx, &iam.ListAttachedRolePoliciesInput{ RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't list attached policies for role %v. Here's why: %v\n", roleName, err) } else { policies = result.AttachedPolicies } return policies, err } // DetachRolePolicy detaches a policy from a role. func (wrapper RoleWrapper) DetachRolePolicy(ctx context.Context, roleName string, policyArn string) error { _, err := wrapper.IamClient.DetachRolePolicy(ctx, &iam.DetachRolePolicyInput{ PolicyArn: aws.String(policyArn), RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't detach policy from role %v. Here's why: %v\n", roleName, err) } return err } // ListRolePolicies lists the inline policies for a role. func (wrapper RoleWrapper) ListRolePolicies(ctx context.Context, roleName string) ([]string, error) { var policies []string result, err := wrapper.IamClient.ListRolePolicies(ctx, &iam.ListRolePoliciesInput{ RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't list policies for role %v. Here's why: %v\n", roleName, err) } else { policies = result.PolicyNames } return policies, err } // DeleteRole deletes a role. All attached policies must be detached before a // role can be deleted. func (wrapper RoleWrapper) DeleteRole(ctx context.Context, roleName string) error { _, err := wrapper.IamClient.DeleteRole(ctx, &iam.DeleteRoleInput{ RoleName: aws.String(roleName), }) if err != nil { log.Printf("Couldn't delete role %v. Here's why: %v\n", roleName, err) } return err } ``` Définissez une structure qui encapsule les actions de l’utilisateur. ``` import ( "context" "encoding/json" "errors" "log" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/service/iam" "github.com/aws/aws-sdk-go-v2/service/iam/types" "github.com/aws/smithy-go" ) // UserWrapper encapsulates user actions used in the examples. // It contains an IAM service client that is used to perform user actions. type UserWrapper struct { IamClient *iam.Client } // ListUsers gets up to maxUsers number of users. func (wrapper UserWrapper) ListUsers(ctx context.Context, maxUsers int32) ([]types.User, error) { var users []types.User result, err := wrapper.IamClient.ListUsers(ctx, &iam.ListUsersInput{ MaxItems: aws.Int32(maxUsers), }) if err != nil { log.Printf("Couldn't list users. Here's why: %v\n", err) } else { users = result.Users } return users, err } // GetUser gets data about a user. func (wrapper UserWrapper) GetUser(ctx context.Context, userName string) (*types.User, error) { var user *types.User result, err := wrapper.IamClient.GetUser(ctx, &iam.GetUserInput{ UserName: aws.String(userName), }) if err != nil { var apiError smithy.APIError if errors.As(err, &apiError) { switch apiError.(type) { case *types.NoSuchEntityException: log.Printf("User %v does not exist.\n", userName) err = nil default: log.Printf("Couldn't get user %v. Here's why: %v\n", userName, err) } } } else { user = result.User } return user, err } // CreateUser creates a new user with the specified name. func (wrapper UserWrapper) CreateUser(ctx context.Context, userName string) (*types.User, error) { var user *types.User result, err := wrapper.IamClient.CreateUser(ctx, &iam.CreateUserInput{ UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't create user %v. Here's why: %v\n", userName, err) } else { user = result.User } return user, err } // CreateUserPolicy adds an inline policy to a user. This example creates a policy that // grants a list of actions on a specified role. // PolicyDocument shows how to work with a policy document as a data structure and // serialize it to JSON by using Go's JSON marshaler. func (wrapper UserWrapper) CreateUserPolicy(ctx context.Context, userName string, policyName string, actions []string, roleArn string) error { policyDoc := PolicyDocument{ Version: "2012-10-17", Statement: []PolicyStatement{{ Effect: "Allow", Action: actions, Resource: aws.String(roleArn), }}, } policyBytes, err := json.Marshal(policyDoc) if err != nil { log.Printf("Couldn't create policy document for %v. Here's why: %v\n", roleArn, err) return err } _, err = wrapper.IamClient.PutUserPolicy(ctx, &iam.PutUserPolicyInput{ PolicyDocument: aws.String(string(policyBytes)), PolicyName: aws.String(policyName), UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't create policy for user %v. Here's why: %v\n", userName, err) } return err } // ListUserPolicies lists the inline policies for the specified user. func (wrapper UserWrapper) ListUserPolicies(ctx context.Context, userName string) ([]string, error) { var policies []string result, err := wrapper.IamClient.ListUserPolicies(ctx, &iam.ListUserPoliciesInput{ UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't list policies for user %v. Here's why: %v\n", userName, err) } else { policies = result.PolicyNames } return policies, err } // DeleteUserPolicy deletes an inline policy from a user. func (wrapper UserWrapper) DeleteUserPolicy(ctx context.Context, userName string, policyName string) error { _, err := wrapper.IamClient.DeleteUserPolicy(ctx, &iam.DeleteUserPolicyInput{ PolicyName: aws.String(policyName), UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't delete policy from user %v. Here's why: %v\n", userName, err) } return err } // DeleteUser deletes a user. func (wrapper UserWrapper) DeleteUser(ctx context.Context, userName string) error { _, err := wrapper.IamClient.DeleteUser(ctx, &iam.DeleteUserInput{ UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't delete user %v. Here's why: %v\n", userName, err) } return err } // CreateAccessKeyPair creates an access key for a user. The returned access key contains // the ID and secret credentials needed to use the key. func (wrapper UserWrapper) CreateAccessKeyPair(ctx context.Context, userName string) (*types.AccessKey, error) { var key *types.AccessKey result, err := wrapper.IamClient.CreateAccessKey(ctx, &iam.CreateAccessKeyInput{ UserName: aws.String(userName)}) if err != nil { log.Printf("Couldn't create access key pair for user %v. Here's why: %v\n", userName, err) } else { key = result.AccessKey } return key, err } // DeleteAccessKey deletes an access key from a user. func (wrapper UserWrapper) DeleteAccessKey(ctx context.Context, userName string, keyId string) error { _, err := wrapper.IamClient.DeleteAccessKey(ctx, &iam.DeleteAccessKeyInput{ AccessKeyId: aws.String(keyId), UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't delete access key %v. Here's why: %v\n", keyId, err) } return err } // ListAccessKeys lists the access keys for the specified user. func (wrapper UserWrapper) ListAccessKeys(ctx context.Context, userName string) ([]types.AccessKeyMetadata, error) { var keys []types.AccessKeyMetadata result, err := wrapper.IamClient.ListAccessKeys(ctx, &iam.ListAccessKeysInput{ UserName: aws.String(userName), }) if err != nil { log.Printf("Couldn't list access keys for user %v. Here's why: %v\n", userName, err) } else { keys = result.AccessKeyMetadata } return keys, err } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Go *. + [AttachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.AttachRolePolicy) + [CreateAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateAccessKey) + [CreatePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreatePolicy) + [CreateRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateRole) + [CreateUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateUser) + [DeleteAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteAccessKey) + [DeletePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeletePolicy) + [DeleteRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteRole) + [DeleteUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUser) + [DeleteUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUserPolicy) + [DetachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DetachRolePolicy) + [PutUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.PutUserPolicy) ------ #### [ Java ] **SDK pour Java 2.x** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/iam#code-examples). Créez des fonctions qui encapsulent les actions de l’utilisateur IAM. ``` /* To run this Java V2 code example, set up your development environment, including your credentials. For information, see this documentation topic: https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html This example performs these operations: 1. Creates a user that has no permissions. 2. Creates a role and policy that grants Amazon S3 permissions. 3. Creates a role. 4. Grants the user permissions. 5. Gets temporary credentials by assuming the role. Creates an Amazon S3 Service client object with the temporary credentials. 6. Deletes the resources. */ public class IAMScenario { public static final String DASHES = new String(new char[80]).replace("\0", "-"); public static final String PolicyDocument = "{" + " \"Version\": \"2012-10-17\"," + " \"Statement\": [" + " {" + " \"Effect\": \"Allow\"," + " \"Action\": [" + " \"s3:*\"" + " ]," + " \"Resource\": \"*\"" + " }" + " ]" + "}"; public static String userArn; public static void main(String[] args) throws Exception { final String usage = """ Usage: \s Where: username - The name of the IAM user to create.\s policyName - The name of the policy to create.\s roleName - The name of the role to create.\s roleSessionName - The name of the session required for the assumeRole operation.\s bucketName - The name of the Amazon S3 bucket from which objects are read.\s """; if (args.length != 5) { System.out.println(usage); System.exit(1); } String userName = args[0]; String policyName = args[1]; String roleName = args[2]; String roleSessionName = args[3]; String bucketName = args[4]; Region region = Region.AWS_GLOBAL; IamClient iam = IamClient.builder() .region(region) .build(); System.out.println(DASHES); System.out.println("Welcome to the AWS IAM example scenario."); System.out.println(DASHES); System.out.println(DASHES); System.out.println(" 1. Create the IAM user."); User createUser = createIAMUser(iam, userName); System.out.println(DASHES); userArn = createUser.arn(); AccessKey myKey = createIAMAccessKey(iam, userName); String accessKey = myKey.accessKeyId(); String secretKey = myKey.secretAccessKey(); String assumeRolePolicyDocument = "{" + "\"Version\": \"2012-10-17\"," + "\"Statement\": [{" + "\"Effect\": \"Allow\"," + "\"Principal\": {" + " \"AWS\": \"" + userArn + "\"" + "}," + "\"Action\": \"sts:AssumeRole\"" + "}]" + "}"; System.out.println(assumeRolePolicyDocument); System.out.println(userName + " was successfully created."); System.out.println(DASHES); System.out.println("2. Creates a policy."); String polArn = createIAMPolicy(iam, policyName); System.out.println("The policy " + polArn + " was successfully created."); System.out.println(DASHES); System.out.println(DASHES); System.out.println("3. Creates a role."); TimeUnit.SECONDS.sleep(30); String roleArn = createIAMRole(iam, roleName, assumeRolePolicyDocument); System.out.println(roleArn + " was successfully created."); System.out.println(DASHES); System.out.println(DASHES); System.out.println("4. Grants the user permissions."); attachIAMRolePolicy(iam, roleName, polArn); System.out.println(DASHES); System.out.println(DASHES); System.out.println("*** Wait for 30 secs so the resource is available"); TimeUnit.SECONDS.sleep(30); System.out.println("5. Gets temporary credentials by assuming the role."); System.out.println("Perform an Amazon S3 Service operation using the temporary credentials."); assumeRole(roleArn, roleSessionName, bucketName, accessKey, secretKey); System.out.println(DASHES); System.out.println(DASHES); System.out.println("6 Getting ready to delete the AWS resources"); deleteKey(iam, userName, accessKey); deleteRole(iam, roleName, polArn); deleteIAMUser(iam, userName); System.out.println(DASHES); System.out.println(DASHES); System.out.println("This IAM Scenario has successfully completed"); System.out.println(DASHES); } public static AccessKey createIAMAccessKey(IamClient iam, String user) { try { CreateAccessKeyRequest request = CreateAccessKeyRequest.builder() .userName(user) .build(); CreateAccessKeyResponse response = iam.createAccessKey(request); return response.accessKey(); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } return null; } public static User createIAMUser(IamClient iam, String username) { try { // Create an IamWaiter object IamWaiter iamWaiter = iam.waiter(); CreateUserRequest request = CreateUserRequest.builder() .userName(username) .build(); // Wait until the user is created. CreateUserResponse response = iam.createUser(request); GetUserRequest userRequest = GetUserRequest.builder() .userName(response.user().userName()) .build(); WaiterResponse waitUntilUserExists = iamWaiter.waitUntilUserExists(userRequest); waitUntilUserExists.matched().response().ifPresent(System.out::println); return response.user(); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } return null; } public static String createIAMRole(IamClient iam, String rolename, String json) { try { CreateRoleRequest request = CreateRoleRequest.builder() .roleName(rolename) .assumeRolePolicyDocument(json) .description("Created using the AWS SDK for Java") .build(); CreateRoleResponse response = iam.createRole(request); System.out.println("The ARN of the role is " + response.role().arn()); return response.role().arn(); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } return ""; } public static String createIAMPolicy(IamClient iam, String policyName) { try { // Create an IamWaiter object. IamWaiter iamWaiter = iam.waiter(); CreatePolicyRequest request = CreatePolicyRequest.builder() .policyName(policyName) .policyDocument(PolicyDocument).build(); CreatePolicyResponse response = iam.createPolicy(request); GetPolicyRequest polRequest = GetPolicyRequest.builder() .policyArn(response.policy().arn()) .build(); WaiterResponse waitUntilPolicyExists = iamWaiter.waitUntilPolicyExists(polRequest); waitUntilPolicyExists.matched().response().ifPresent(System.out::println); return response.policy().arn(); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } return ""; } public static void attachIAMRolePolicy(IamClient iam, String roleName, String policyArn) { try { ListAttachedRolePoliciesRequest request = ListAttachedRolePoliciesRequest.builder() .roleName(roleName) .build(); ListAttachedRolePoliciesResponse response = iam.listAttachedRolePolicies(request); List attachedPolicies = response.attachedPolicies(); String polArn; for (AttachedPolicy policy : attachedPolicies) { polArn = policy.policyArn(); if (polArn.compareTo(policyArn) == 0) { System.out.println(roleName + " policy is already attached to this role."); return; } } AttachRolePolicyRequest attachRequest = AttachRolePolicyRequest.builder() .roleName(roleName) .policyArn(policyArn) .build(); iam.attachRolePolicy(attachRequest); System.out.println("Successfully attached policy " + policyArn + " to role " + roleName); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } } // Invoke an Amazon S3 operation using the Assumed Role. public static void assumeRole(String roleArn, String roleSessionName, String bucketName, String keyVal, String keySecret) { // Use the creds of the new IAM user that was created in this code example. AwsBasicCredentials credentials = AwsBasicCredentials.create(keyVal, keySecret); StsClient stsClient = StsClient.builder() .region(Region.US_EAST_1) .credentialsProvider(StaticCredentialsProvider.create(credentials)) .build(); try { AssumeRoleRequest roleRequest = AssumeRoleRequest.builder() .roleArn(roleArn) .roleSessionName(roleSessionName) .build(); AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest); Credentials myCreds = roleResponse.credentials(); String key = myCreds.accessKeyId(); String secKey = myCreds.secretAccessKey(); String secToken = myCreds.sessionToken(); // List all objects in an Amazon S3 bucket using the temp creds retrieved by // invoking assumeRole. Region region = Region.US_EAST_1; S3Client s3 = S3Client.builder() .credentialsProvider( StaticCredentialsProvider.create(AwsSessionCredentials.create(key, secKey, secToken))) .region(region) .build(); System.out.println("Created a S3Client using temp credentials."); System.out.println("Listing objects in " + bucketName); ListObjectsRequest listObjects = ListObjectsRequest.builder() .bucket(bucketName) .build(); ListObjectsResponse res = s3.listObjects(listObjects); List objects = res.contents(); for (S3Object myValue : objects) { System.out.println("The name of the key is " + myValue.key()); System.out.println("The owner is " + myValue.owner()); } } catch (StsException e) { System.err.println(e.getMessage()); System.exit(1); } } public static void deleteRole(IamClient iam, String roleName, String polArn) { try { // First the policy needs to be detached. DetachRolePolicyRequest rolePolicyRequest = DetachRolePolicyRequest.builder() .policyArn(polArn) .roleName(roleName) .build(); iam.detachRolePolicy(rolePolicyRequest); // Delete the policy. DeletePolicyRequest request = DeletePolicyRequest.builder() .policyArn(polArn) .build(); iam.deletePolicy(request); System.out.println("*** Successfully deleted " + polArn); // Delete the role. DeleteRoleRequest roleRequest = DeleteRoleRequest.builder() .roleName(roleName) .build(); iam.deleteRole(roleRequest); System.out.println("*** Successfully deleted " + roleName); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } } public static void deleteKey(IamClient iam, String username, String accessKey) { try { DeleteAccessKeyRequest request = DeleteAccessKeyRequest.builder() .accessKeyId(accessKey) .userName(username) .build(); iam.deleteAccessKey(request); System.out.println("Successfully deleted access key " + accessKey + " from user " + username); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } } public static void deleteIAMUser(IamClient iam, String userName) { try { DeleteUserRequest request = DeleteUserRequest.builder() .userName(userName) .build(); iam.deleteUser(request); System.out.println("*** Successfully deleted " + userName); } catch (IamException e) { System.err.println(e.awsErrorDetails().errorMessage()); System.exit(1); } } } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK for Java 2.x *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/PutUserPolicy) ------ #### [ JavaScript ] **SDK pour JavaScript (v3)** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/iam#code-examples). Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte. ``` import { CreateUserCommand, GetUserCommand, CreateAccessKeyCommand, CreatePolicyCommand, CreateRoleCommand, AttachRolePolicyCommand, DeleteAccessKeyCommand, DeleteUserCommand, DeleteRoleCommand, DeletePolicyCommand, DetachRolePolicyCommand, IAMClient, } from "@aws-sdk/client-iam"; import { ListBucketsCommand, S3Client } from "@aws-sdk/client-s3"; import { AssumeRoleCommand, STSClient } from "@aws-sdk/client-sts"; import { retry } from "@aws-doc-sdk-examples/lib/utils/util-timers.js"; import { ScenarioInput } from "@aws-doc-sdk-examples/lib/scenario/index.js"; // Set the parameters. const iamClient = new IAMClient({}); const userName = "iam_basic_test_username"; const policyName = "iam_basic_test_policy"; const roleName = "iam_basic_test_role"; /** * Create a new IAM user. If the user already exists, give * the option to delete and re-create it. * @param {string} name */ export const createUser = async (name, confirmAll = false) => { try { const { User } = await iamClient.send( new GetUserCommand({ UserName: name }), ); const input = new ScenarioInput( "deleteUser", "Do you want to delete and remake this user?", { type: "confirm" }, ); const deleteUser = await input.handle({}, { confirmAll }); // If the user exists, and you want to delete it, delete the user // and then create it again. if (deleteUser) { await iamClient.send(new DeleteUserCommand({ UserName: User.UserName })); await iamClient.send(new CreateUserCommand({ UserName: name })); } else { console.warn( `${name} already exists. The scenario may not work as expected.`, ); return User; } } catch (caught) { // If there is no user by that name, create one. if (caught instanceof Error && caught.name === "NoSuchEntityException") { const { User } = await iamClient.send( new CreateUserCommand({ UserName: name }), ); return User; } throw caught; } }; export const main = async (confirmAll = false) => { // Create a user. The user has no permissions by default. const User = await createUser(userName, confirmAll); if (!User) { throw new Error("User not created"); } // Create an access key. This key is used to authenticate the new user to // Amazon Simple Storage Service (Amazon S3) and AWS Security Token Service (AWS STS). // It's not best practice to use access keys. For more information, see https://aws.amazon.com/iam/resources/best-practices/. const createAccessKeyResponse = await iamClient.send( new CreateAccessKeyCommand({ UserName: userName }), ); if ( !createAccessKeyResponse.AccessKey?.AccessKeyId || !createAccessKeyResponse.AccessKey?.SecretAccessKey ) { throw new Error("Access key not created"); } const { AccessKey: { AccessKeyId, SecretAccessKey }, } = createAccessKeyResponse; let s3Client = new S3Client({ credentials: { accessKeyId: AccessKeyId, secretAccessKey: SecretAccessKey, }, }); // Retry the list buckets operation until it succeeds. InvalidAccessKeyId is // thrown while the user and access keys are still stabilizing. await retry({ intervalInMs: 1000, maxRetries: 300 }, async () => { try { return await listBuckets(s3Client); } catch (err) { if (err instanceof Error && err.name === "InvalidAccessKeyId") { throw err; } } }); // Retry the create role operation until it succeeds. A MalformedPolicyDocument error // is thrown while the user and access keys are still stabilizing. const { Role } = await retry( { intervalInMs: 2000, maxRetries: 60, }, () => iamClient.send( new CreateRoleCommand({ AssumeRolePolicyDocument: JSON.stringify({ Version: "2012-10-17", Statement: [ { Effect: "Allow", Principal: { // Allow the previously created user to assume this role. AWS: User.Arn, }, Action: "sts:AssumeRole", }, ], }), RoleName: roleName, }), ), ); if (!Role) { throw new Error("Role not created"); } // Create a policy that allows the user to list S3 buckets. const { Policy: listBucketPolicy } = await iamClient.send( new CreatePolicyCommand({ PolicyDocument: JSON.stringify({ Version: "2012-10-17", Statement: [ { Effect: "Allow", Action: ["s3:ListAllMyBuckets"], Resource: "*", }, ], }), PolicyName: policyName, }), ); if (!listBucketPolicy) { throw new Error("Policy not created"); } // Attach the policy granting the 's3:ListAllMyBuckets' action to the role. await iamClient.send( new AttachRolePolicyCommand({ PolicyArn: listBucketPolicy.Arn, RoleName: Role.RoleName, }), ); // Assume the role. const stsClient = new STSClient({ credentials: { accessKeyId: AccessKeyId, secretAccessKey: SecretAccessKey, }, }); // Retry the assume role operation until it succeeds. const { Credentials } = await retry( { intervalInMs: 2000, maxRetries: 60 }, () => stsClient.send( new AssumeRoleCommand({ RoleArn: Role.Arn, RoleSessionName: `iamBasicScenarioSession-${Math.floor( Math.random() * 1000000, )}`, DurationSeconds: 900, }), ), ); if (!Credentials?.AccessKeyId || !Credentials?.SecretAccessKey) { throw new Error("Credentials not created"); } s3Client = new S3Client({ credentials: { accessKeyId: Credentials.AccessKeyId, secretAccessKey: Credentials.SecretAccessKey, sessionToken: Credentials.SessionToken, }, }); // List the S3 buckets again. // Retry the list buckets operation until it succeeds. AccessDenied might // be thrown while the role policy is still stabilizing. await retry({ intervalInMs: 2000, maxRetries: 120 }, () => listBuckets(s3Client), ); // Clean up. await iamClient.send( new DetachRolePolicyCommand({ PolicyArn: listBucketPolicy.Arn, RoleName: Role.RoleName, }), ); await iamClient.send( new DeletePolicyCommand({ PolicyArn: listBucketPolicy.Arn, }), ); await iamClient.send( new DeleteRoleCommand({ RoleName: Role.RoleName, }), ); await iamClient.send( new DeleteAccessKeyCommand({ UserName: userName, AccessKeyId, }), ); await iamClient.send( new DeleteUserCommand({ UserName: userName, }), ); }; /** * * @param {S3Client} s3Client */ const listBuckets = async (s3Client) => { const { Buckets } = await s3Client.send(new ListBucketsCommand({})); if (!Buckets) { throw new Error("Buckets not listed"); } console.log(Buckets.map((bucket) => bucket.Name).join("\n")); }; ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour JavaScript *. + [AttachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/AttachRolePolicyCommand) + [CreateAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateAccessKeyCommand) + [CreatePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreatePolicyCommand) + [CreateRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateRoleCommand) + [CreateUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateUserCommand) + [DeleteAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteAccessKeyCommand) + [DeletePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeletePolicyCommand) + [DeleteRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteRoleCommand) + [DeleteUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserCommand) + [DeleteUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserPolicyCommand) + [DetachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DetachRolePolicyCommand) + [PutUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/PutUserPolicyCommand) ------ #### [ Kotlin ] **SDK pour Kotlin** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin/services/iam#code-examples). Créez des fonctions qui encapsulent les actions de l’utilisateur IAM. ``` suspend fun main(args: Array) { val usage = """ Usage: Where: username - The name of the IAM user to create. policyName - The name of the policy to create. roleName - The name of the role to create. roleSessionName - The name of the session required for the assumeRole operation. fileLocation - The file location to the JSON required to create the role (see Readme). bucketName - The name of the Amazon S3 bucket from which objects are read. """ if (args.size != 6) { println(usage) exitProcess(1) } val userName = args[0] val policyName = args[1] val roleName = args[2] val roleSessionName = args[3] val fileLocation = args[4] val bucketName = args[5] createUser(userName) println("$userName was successfully created.") val polArn = createPolicy(policyName) println("The policy $polArn was successfully created.") val roleArn = createRole(roleName, fileLocation) println("$roleArn was successfully created.") attachRolePolicy(roleName, polArn) println("*** Wait for 1 MIN so the resource is available.") delay(60000) assumeGivenRole(roleArn, roleSessionName, bucketName) println("*** Getting ready to delete the AWS resources.") deleteRole(roleName, polArn) deleteUser(userName) println("This IAM Scenario has successfully completed.") } suspend fun createUser(usernameVal: String?): String? { val request = CreateUserRequest { userName = usernameVal } IamClient { region = "AWS_GLOBAL" }.use { iamClient -> val response = iamClient.createUser(request) return response.user?.userName } } suspend fun createPolicy(policyNameVal: String?): String { val policyDocumentValue = """ { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": "*" } ] } """.trimIndent() val request = CreatePolicyRequest { policyName = policyNameVal policyDocument = policyDocumentValue } IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient -> val response = iamClient.createPolicy(request) return response.policy?.arn.toString() } } suspend fun createRole( rolenameVal: String?, fileLocation: String?, ): String? { val jsonObject = fileLocation?.let { readJsonSimpleDemo(it) } as JSONObject val request = CreateRoleRequest { roleName = rolenameVal assumeRolePolicyDocument = jsonObject.toJSONString() description = "Created using the AWS SDK for Kotlin" } IamClient { region = "AWS_GLOBAL" }.use { iamClient -> val response = iamClient.createRole(request) return response.role?.arn } } suspend fun attachRolePolicy( roleNameVal: String, policyArnVal: String, ) { val request = ListAttachedRolePoliciesRequest { roleName = roleNameVal } IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient -> val response = iamClient.listAttachedRolePolicies(request) val attachedPolicies = response.attachedPolicies // Ensure that the policy is not attached to this role. val checkStatus: Int if (attachedPolicies != null) { checkStatus = checkMyList(attachedPolicies, policyArnVal) if (checkStatus == -1) { return } } val policyRequest = AttachRolePolicyRequest { roleName = roleNameVal policyArn = policyArnVal } iamClient.attachRolePolicy(policyRequest) println("Successfully attached policy $policyArnVal to role $roleNameVal") } } fun checkMyList( attachedPolicies: List, policyArnVal: String, ): Int { for (policy in attachedPolicies) { val polArn = policy.policyArn.toString() if (polArn.compareTo(policyArnVal) == 0) { println("The policy is already attached to this role.") return -1 } } return 0 } suspend fun assumeGivenRole( roleArnVal: String?, roleSessionNameVal: String?, bucketName: String, ) { val stsClient = StsClient.fromEnvironment { region = "us-east-1" } val roleRequest = AssumeRoleRequest { roleArn = roleArnVal roleSessionName = roleSessionNameVal } val roleResponse = stsClient.assumeRole(roleRequest) val myCreds = roleResponse.credentials val key = myCreds?.accessKeyId val secKey = myCreds?.secretAccessKey val secToken = myCreds?.sessionToken val staticCredentials = StaticCredentialsProvider { accessKeyId = key secretAccessKey = secKey sessionToken = secToken } // List all objects in an Amazon S3 bucket using the temp creds. val s3 = S3Client.fromEnvironment { region = "us-east-1" credentialsProvider = staticCredentials } println("Created a S3Client using temp credentials.") println("Listing objects in $bucketName") val listObjects = ListObjectsRequest { bucket = bucketName } val response = s3.listObjects(listObjects) response.contents?.forEach { myObject -> println("The name of the key is ${myObject.key}") println("The owner is ${myObject.owner}") } } suspend fun deleteRole( roleNameVal: String, polArn: String, ) { val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" } // First the policy needs to be detached. val rolePolicyRequest = DetachRolePolicyRequest { policyArn = polArn roleName = roleNameVal } iam.detachRolePolicy(rolePolicyRequest) // Delete the policy. val request = DeletePolicyRequest { policyArn = polArn } iam.deletePolicy(request) println("*** Successfully deleted $polArn") // Delete the role. val roleRequest = DeleteRoleRequest { roleName = roleNameVal } iam.deleteRole(roleRequest) println("*** Successfully deleted $roleNameVal") } suspend fun deleteUser(userNameVal: String) { val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" } val request = DeleteUserRequest { userName = userNameVal } iam.deleteUser(request) println("*** Successfully deleted $userNameVal") } @Throws(java.lang.Exception::class) fun readJsonSimpleDemo(filename: String): Any? { val reader = FileReader(filename) val jsonParser = JSONParser() return jsonParser.parse(reader) } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Kotlin*. + [AttachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [CreateAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [CreatePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [CreateRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [CreateUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DeleteAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DeletePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DeleteRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DeleteUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DeleteUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [DetachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) + [PutUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html) ------ #### [ PHP ] **Kit SDK pour PHP** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php/example_code/iam#code-examples). ``` namespace Iam\Basics; require 'vendor/autoload.php'; use Aws\Credentials\Credentials; use Aws\S3\Exception\S3Exception; use Aws\S3\S3Client; use Aws\Sts\StsClient; use Iam\IAMService; echo("\n"); echo("--------------------------------------\n"); print("Welcome to the IAM getting started demo using PHP!\n"); echo("--------------------------------------\n"); $uuid = uniqid(); $service = new IAMService(); $user = $service->createUser("iam_demo_user_$uuid"); echo "Created user with the arn: {$user['Arn']}\n"; $key = $service->createAccessKey($user['UserName']); $assumeRolePolicyDocument = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"{$user['Arn']}\"}, \"Action\": \"sts:AssumeRole\" }] }"; $assumeRoleRole = $service->createRole("iam_demo_role_$uuid", $assumeRolePolicyDocument); echo "Created role: {$assumeRoleRole['RoleName']}\n"; $listAllBucketsPolicyDocument = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"s3:ListAllMyBuckets\", \"Resource\": \"arn:aws:s3:::*\"}] }"; $listAllBucketsPolicy = $service->createPolicy("iam_demo_policy_$uuid", $listAllBucketsPolicyDocument); echo "Created policy: {$listAllBucketsPolicy['PolicyName']}\n"; $service->attachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']); $inlinePolicyDocument = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"sts:AssumeRole\", \"Resource\": \"{$assumeRoleRole['Arn']}\"}] }"; $inlinePolicy = $service->createUserPolicy("iam_demo_inline_policy_$uuid", $inlinePolicyDocument, $user['UserName']); //First, fail to list the buckets with the user $credentials = new Credentials($key['AccessKeyId'], $key['SecretAccessKey']); $s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]); try { $s3Client->listBuckets([ ]); echo "this should not run"; } catch (S3Exception $exception) { echo "successfully failed!\n"; } $stsClient = new StsClient(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]); sleep(10); $assumedRole = $stsClient->assumeRole([ 'RoleArn' => $assumeRoleRole['Arn'], 'RoleSessionName' => "DemoAssumeRoleSession_$uuid", ]); $assumedCredentials = [ 'key' => $assumedRole['Credentials']['AccessKeyId'], 'secret' => $assumedRole['Credentials']['SecretAccessKey'], 'token' => $assumedRole['Credentials']['SessionToken'], ]; $s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $assumedCredentials]); try { $s3Client->listBuckets([]); echo "this should now run!\n"; } catch (S3Exception $exception) { echo "this should now not fail\n"; } $service->detachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']); $deletePolicy = $service->deletePolicy($listAllBucketsPolicy['Arn']); echo "Delete policy: {$listAllBucketsPolicy['PolicyName']}\n"; $deletedRole = $service->deleteRole($assumeRoleRole['Arn']); echo "Deleted role: {$assumeRoleRole['RoleName']}\n"; $deletedKey = $service->deleteAccessKey($key['AccessKeyId'], $user['UserName']); $deletedUser = $service->deleteUser($user['UserName']); echo "Delete user: {$user['UserName']}\n"; ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour PHP *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/PutUserPolicy) ------ #### [ Python ] **Kit SDK for Python (Boto3)** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/iam#code-examples). Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte. ``` import json import sys import time from uuid import uuid4 import boto3 from botocore.exceptions import ClientError def progress_bar(seconds): """Shows a simple progress bar in the command window.""" for _ in range(seconds): time.sleep(1) print(".", end="") sys.stdout.flush() print() def setup(iam_resource): """ Creates a new user with no permissions. Creates an access key pair for the user. Creates a role with a policy that lets the user assume the role. Creates a policy that allows listing Amazon S3 buckets. Attaches the policy to the role. Creates an inline policy for the user that lets the user assume the role. :param iam_resource: A Boto3 AWS Identity and Access Management (IAM) resource that has permissions to create users, roles, and policies in the account. :return: The newly created user, user key, and role. """ try: user = iam_resource.create_user(UserName=f"demo-user-{uuid4()}") print(f"Created user {user.name}.") except ClientError as error: print( f"Couldn't create a user for the demo. Here's why: " f"{error.response['Error']['Message']}" ) raise try: user_key = user.create_access_key_pair() print(f"Created access key pair for user.") except ClientError as error: print( f"Couldn't create access keys for user {user.name}. Here's why: " f"{error.response['Error']['Message']}" ) raise print(f"Wait for user to be ready.", end="") progress_bar(10) try: role = iam_resource.create_role( RoleName=f"demo-role-{uuid4()}", AssumeRolePolicyDocument=json.dumps( { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"AWS": user.arn}, "Action": "sts:AssumeRole", } ], } ), ) print(f"Created role {role.name}.") except ClientError as error: print( f"Couldn't create a role for the demo. Here's why: " f"{error.response['Error']['Message']}" ) raise try: policy = iam_resource.create_policy( PolicyName=f"demo-policy-{uuid4()}", PolicyDocument=json.dumps( { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*", } ], } ), ) role.attach_policy(PolicyArn=policy.arn) print(f"Created policy {policy.policy_name} and attached it to the role.") except ClientError as error: print( f"Couldn't create a policy and attach it to role {role.name}. Here's why: " f"{error.response['Error']['Message']}" ) raise try: user.create_policy( PolicyName=f"demo-user-policy-{uuid4()}", PolicyDocument=json.dumps( { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": role.arn, } ], } ), ) print( f"Created an inline policy for {user.name} that lets the user assume " f"the role." ) except ClientError as error: print( f"Couldn't create an inline policy for user {user.name}. Here's why: " f"{error.response['Error']['Message']}" ) raise print("Give AWS time to propagate these new resources and connections.", end="") progress_bar(10) return user, user_key, role def show_access_denied_without_role(user_key): """ Shows that listing buckets without first assuming the role is not allowed. :param user_key: The key of the user created during setup. This user does not have permission to list buckets in the account. """ print(f"Try to list buckets without first assuming the role.") s3_denied_resource = boto3.resource( "s3", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret ) try: for bucket in s3_denied_resource.buckets.all(): print(bucket.name) raise RuntimeError("Expected to get AccessDenied error when listing buckets!") except ClientError as error: if error.response["Error"]["Code"] == "AccessDenied": print("Attempt to list buckets with no permissions: AccessDenied.") else: raise def list_buckets_from_assumed_role(user_key, assume_role_arn, session_name): """ Assumes a role that grants permission to list the Amazon S3 buckets in the account. Uses the temporary credentials from the role to list the buckets that are owned by the assumed role's account. :param user_key: The access key of a user that has permission to assume the role. :param assume_role_arn: The Amazon Resource Name (ARN) of the role that grants access to list the other account's buckets. :param session_name: The name of the STS session. """ sts_client = boto3.client( "sts", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret ) try: response = sts_client.assume_role( RoleArn=assume_role_arn, RoleSessionName=session_name ) temp_credentials = response["Credentials"] print(f"Assumed role {assume_role_arn} and got temporary credentials.") except ClientError as error: print( f"Couldn't assume role {assume_role_arn}. Here's why: " f"{error.response['Error']['Message']}" ) raise # Create an S3 resource that can access the account with the temporary credentials. s3_resource = boto3.resource( "s3", aws_access_key_id=temp_credentials["AccessKeyId"], aws_secret_access_key=temp_credentials["SecretAccessKey"], aws_session_token=temp_credentials["SessionToken"], ) print(f"Listing buckets for the assumed role's account:") try: for bucket in s3_resource.buckets.all(): print(bucket.name) except ClientError as error: print( f"Couldn't list buckets for the account. Here's why: " f"{error.response['Error']['Message']}" ) raise def teardown(user, role): """ Removes all resources created during setup. :param user: The demo user. :param role: The demo role. """ try: for attached in role.attached_policies.all(): policy_name = attached.policy_name role.detach_policy(PolicyArn=attached.arn) attached.delete() print(f"Detached and deleted {policy_name}.") role.delete() print(f"Deleted {role.name}.") except ClientError as error: print( "Couldn't detach policy, delete policy, or delete role. Here's why: " f"{error.response['Error']['Message']}" ) raise try: for user_pol in user.policies.all(): user_pol.delete() print("Deleted inline user policy.") for key in user.access_keys.all(): key.delete() print("Deleted user's access key.") user.delete() print(f"Deleted {user.name}.") except ClientError as error: print( "Couldn't delete user policy or delete user. Here's why: " f"{error.response['Error']['Message']}" ) def usage_demo(): """Drives the demonstration.""" print("-" * 88) print(f"Welcome to the IAM create user and assume role demo.") print("-" * 88) iam_resource = boto3.resource("iam") user = None role = None try: user, user_key, role = setup(iam_resource) print(f"Created {user.name} and {role.name}.") show_access_denied_without_role(user_key) list_buckets_from_assumed_role(user_key, role.arn, "AssumeRoleDemoSession") except Exception: print("Something went wrong!") finally: if user is not None and role is not None: teardown(user, role) print("Thanks for watching!") if __name__ == "__main__": usage_demo() ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK for Python (Boto3)*. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/PutUserPolicy) ------ #### [ Ruby ] **Kit SDK pour Ruby** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples). Créer un utilisateur IAM et un rôle qui accorde l’autorisation de répertorier les compartiments Amazon S3. L’utilisateur n’a que le droit d’assumer le rôle. Après avoir assumé le rôle, utilisez des informations d’identification temporaires pour répertorier les compartiments pour le compte. ``` # Wraps the scenario actions. class ScenarioCreateUserAssumeRole attr_reader :iam_client # @param [Aws::IAM::Client] iam_client: The AWS IAM client. def initialize(iam_client, logger: Logger.new($stdout)) @iam_client = iam_client @logger = logger end # Waits for the specified number of seconds. # # @param duration [Integer] The number of seconds to wait. def wait(duration) puts('Give AWS time to propagate resources...') sleep(duration) end # Creates a user. # # @param user_name [String] The name to give the user. # @return [Aws::IAM::User] The newly created user. def create_user(user_name) user = @iam_client.create_user(user_name: user_name).user @logger.info("Created demo user named #{user.user_name}.") rescue Aws::Errors::ServiceError => e @logger.info('Tried and failed to create demo user.') @logger.info("\t#{e.code}: #{e.message}") @logger.info("\nCan't continue the demo without a user!") raise else user end # Creates an access key for a user. # # @param user [Aws::IAM::User] The user that owns the key. # @return [Aws::IAM::AccessKeyPair] The newly created access key. def create_access_key_pair(user) user_key = @iam_client.create_access_key(user_name: user.user_name).access_key @logger.info("Created accesskey pair for user #{user.user_name}.") rescue Aws::Errors::ServiceError => e @logger.info("Couldn't create access keys for user #{user.user_name}.") @logger.info("\t#{e.code}: #{e.message}") raise else user_key end # Creates a role that can be assumed by a user. # # @param role_name [String] The name to give the role. # @param user [Aws::IAM::User] The user who is granted permission to assume the role. # @return [Aws::IAM::Role] The newly created role. def create_role(role_name, user) trust_policy = { Version: '2012-10-17', Statement: [{ Effect: 'Allow', Principal: { 'AWS': user.arn }, Action: 'sts:AssumeRole' }] }.to_json role = @iam_client.create_role( role_name: role_name, assume_role_policy_document: trust_policy ).role @logger.info("Created role #{role.role_name}.") rescue Aws::Errors::ServiceError => e @logger.info("Couldn't create a role for the demo. Here's why: ") @logger.info("\t#{e.code}: #{e.message}") raise else role end # Creates a policy that grants permission to list S3 buckets in the account, and # then attaches the policy to a role. # # @param policy_name [String] The name to give the policy. # @param role [Aws::IAM::Role] The role that the policy is attached to. # @return [Aws::IAM::Policy] The newly created policy. def create_and_attach_role_policy(policy_name, role) policy_document = { Version: '2012-10-17', Statement: [{ Effect: 'Allow', Action: 's3:ListAllMyBuckets', Resource: 'arn:aws:s3:::*' }] }.to_json policy = @iam_client.create_policy( policy_name: policy_name, policy_document: policy_document ).policy @iam_client.attach_role_policy( role_name: role.role_name, policy_arn: policy.arn ) @logger.info("Created policy #{policy.policy_name} and attached it to role #{role.role_name}.") rescue Aws::Errors::ServiceError => e @logger.info("Couldn't create a policy and attach it to role #{role.role_name}. Here's why: ") @logger.info("\t#{e.code}: #{e.message}") raise end # Creates an inline policy for a user that lets the user assume a role. # # @param policy_name [String] The name to give the policy. # @param user [Aws::IAM::User] The user that owns the policy. # @param role [Aws::IAM::Role] The role that can be assumed. # @return [Aws::IAM::UserPolicy] The newly created policy. def create_user_policy(policy_name, user, role) policy_document = { Version: '2012-10-17', Statement: [{ Effect: 'Allow', Action: 'sts:AssumeRole', Resource: role.arn }] }.to_json @iam_client.put_user_policy( user_name: user.user_name, policy_name: policy_name, policy_document: policy_document ) puts("Created an inline policy for #{user.user_name} that lets the user assume role #{role.role_name}.") rescue Aws::Errors::ServiceError => e @logger.info("Couldn't create an inline policy for user #{user.user_name}. Here's why: ") @logger.info("\t#{e.code}: #{e.message}") raise end # Creates an Amazon S3 resource with specified credentials. This is separated into a # factory function so that it can be mocked for unit testing. # # @param credentials [Aws::Credentials] The credentials used by the Amazon S3 resource. def create_s3_resource(credentials) Aws::S3::Resource.new(client: Aws::S3::Client.new(credentials: credentials)) end # Lists the S3 buckets for the account, using the specified Amazon S3 resource. # Because the resource uses credentials with limited access, it may not be able to # list the S3 buckets. # # @param s3_resource [Aws::S3::Resource] An Amazon S3 resource. def list_buckets(s3_resource) count = 10 s3_resource.buckets.each do |bucket| @logger.info "\t#{bucket.name}" count -= 1 break if count.zero? end rescue Aws::Errors::ServiceError => e if e.code == 'AccessDenied' puts('Attempt to list buckets with no permissions: AccessDenied.') else @logger.info("Couldn't list buckets for the account. Here's why: ") @logger.info("\t#{e.code}: #{e.message}") raise end end # Creates an AWS Security Token Service (AWS STS) client with specified credentials. # This is separated into a factory function so that it can be mocked for unit testing. # # @param key_id [String] The ID of the access key used by the STS client. # @param key_secret [String] The secret part of the access key used by the STS client. def create_sts_client(key_id, key_secret) Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret) end # Gets temporary credentials that can be used to assume a role. # # @param role_arn [String] The ARN of the role that is assumed when these credentials # are used. # @param sts_client [AWS::STS::Client] An AWS STS client. # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role. def assume_role(role_arn, sts_client) credentials = Aws::AssumeRoleCredentials.new( client: sts_client, role_arn: role_arn, role_session_name: 'create-use-assume-role-scenario' ) @logger.info("Assumed role '#{role_arn}', got temporary credentials.") credentials end # Deletes a role. If the role has policies attached, they are detached and # deleted before the role is deleted. # # @param role_name [String] The name of the role to delete. def delete_role(role_name) @iam_client.list_attached_role_policies(role_name: role_name).attached_policies.each do |policy| @iam_client.detach_role_policy(role_name: role_name, policy_arn: policy.policy_arn) @iam_client.delete_policy(policy_arn: policy.policy_arn) @logger.info("Detached and deleted policy #{policy.policy_name}.") end @iam_client.delete_role({ role_name: role_name }) @logger.info("Role deleted: #{role_name}.") rescue Aws::Errors::ServiceError => e @logger.info("Couldn't detach policies and delete role #{role.name}. Here's why:") @logger.info("\t#{e.code}: #{e.message}") raise end # Deletes a user. If the user has inline policies or access keys, they are deleted # before the user is deleted. # # @param user [Aws::IAM::User] The user to delete. def delete_user(user_name) user = @iam_client.list_access_keys(user_name: user_name).access_key_metadata user.each do |key| @iam_client.delete_access_key({ access_key_id: key.access_key_id, user_name: user_name }) @logger.info("Deleted access key #{key.access_key_id} for user '#{user_name}'.") end @iam_client.delete_user(user_name: user_name) @logger.info("Deleted user '#{user_name}'.") rescue Aws::IAM::Errors::ServiceError => e @logger.error("Error deleting user '#{user_name}': #{e.message}") end end # Runs the IAM create a user and assume a role scenario. def run_scenario(scenario) puts('-' * 88) puts('Welcome to the IAM create a user and assume a role demo!') puts('-' * 88) user = scenario.create_user("doc-example-user-#{Random.uuid}") user_key = scenario.create_access_key_pair(user) scenario.wait(10) role = scenario.create_role("doc-example-role-#{Random.uuid}", user) scenario.create_and_attach_role_policy("doc-example-role-policy-#{Random.uuid}", role) scenario.create_user_policy("doc-example-user-policy-#{Random.uuid}", user, role) scenario.wait(10) puts('Try to list buckets with credentials for a user who has no permissions.') puts('Expect AccessDenied from this call.') scenario.list_buckets( scenario.create_s3_resource(Aws::Credentials.new(user_key.access_key_id, user_key.secret_access_key)) ) puts('Now, assume the role that grants permission.') temp_credentials = scenario.assume_role( role.arn, scenario.create_sts_client(user_key.access_key_id, user_key.secret_access_key) ) puts('Here are your buckets:') scenario.list_buckets(scenario.create_s3_resource(temp_credentials)) puts("Deleting role '#{role.role_name}' and attached policies.") scenario.delete_role(role.role_name) puts("Deleting user '#{user.user_name}', policies, and keys.") scenario.delete_user(user.user_name) puts('Thanks for watching!') puts('-' * 88) rescue Aws::Errors::ServiceError => e puts('Something went wrong with the demo.') puts("\t#{e.code}: #{e.message}") end run_scenario(ScenarioCreateUserAssumeRole.new(Aws::IAM::Client.new)) if $PROGRAM_NAME == __FILE__ ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Ruby *. + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/AttachRolePolicy) + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateAccessKey) + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreatePolicy) + [CreateRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateRole) + [CreateUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateUser) + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteAccessKey) + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeletePolicy) + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteRole) + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUser) + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUserPolicy) + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DetachRolePolicy) + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/PutUserPolicy) ------ #### [ Rust ] **SDK pour Rust** Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le [référentiel d’exemples de code AWS](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/iam#code-examples). ``` use aws_config::meta::region::RegionProviderChain; use aws_sdk_iam::Error as iamError; use aws_sdk_iam::{config::Credentials as iamCredentials, config::Region, Client as iamClient}; use aws_sdk_s3::Client as s3Client; use aws_sdk_sts::Client as stsClient; use tokio::time::{sleep, Duration}; use uuid::Uuid; #[tokio::main] async fn main() -> Result<(), iamError> { let (client, uuid, list_all_buckets_policy_document, inline_policy_document) = initialize_variables().await; if let Err(e) = run_iam_operations( client, uuid, list_all_buckets_policy_document, inline_policy_document, ) .await { println!("{:?}", e); }; Ok(()) } async fn initialize_variables() -> (iamClient, String, String, String) { let region_provider = RegionProviderChain::first_try(Region::new("us-west-2")); let shared_config = aws_config::from_env().region(region_provider).load().await; let client = iamClient::new(&shared_config); let uuid = Uuid::new_v4().to_string(); let list_all_buckets_policy_document = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"s3:ListAllMyBuckets\", \"Resource\": \"arn:aws:s3:::*\"}] }" .to_string(); let inline_policy_document = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\": \"sts:AssumeRole\", \"Resource\": \"{}\"}] }" .to_string(); ( client, uuid, list_all_buckets_policy_document, inline_policy_document, ) } async fn run_iam_operations( client: iamClient, uuid: String, list_all_buckets_policy_document: String, inline_policy_document: String, ) -> Result<(), iamError> { let user = iam_service::create_user(&client, &format!("{}{}", "iam_demo_user_", uuid)).await?; println!("Created the user with the name: {}", user.user_name()); let key = iam_service::create_access_key(&client, user.user_name()).await?; let assume_role_policy_document = "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"{}\"}, \"Action\": \"sts:AssumeRole\" }] }" .to_string() .replace("{}", user.arn()); let assume_role_role = iam_service::create_role( &client, &format!("{}{}", "iam_demo_role_", uuid), &assume_role_policy_document, ) .await?; println!("Created the role with the ARN: {}", assume_role_role.arn()); let list_all_buckets_policy = iam_service::create_policy( &client, &format!("{}{}", "iam_demo_policy_", uuid), &list_all_buckets_policy_document, ) .await?; println!( "Created policy: {}", list_all_buckets_policy.policy_name.as_ref().unwrap() ); let attach_role_policy_result = iam_service::attach_role_policy(&client, &assume_role_role, &list_all_buckets_policy) .await?; println!( "Attached the policy to the role: {:?}", attach_role_policy_result ); let inline_policy_name = format!("{}{}", "iam_demo_inline_policy_", uuid); let inline_policy_document = inline_policy_document.replace("{}", assume_role_role.arn()); iam_service::create_user_policy(&client, &user, &inline_policy_name, &inline_policy_document) .await?; println!("Created inline policy."); //First, fail to list the buckets with the user. let creds = iamCredentials::from_keys(key.access_key_id(), key.secret_access_key(), None); let fail_config = aws_config::from_env() .credentials_provider(creds.clone()) .load() .await; println!("Fail config: {:?}", fail_config); let fail_client: s3Client = s3Client::new(&fail_config); match fail_client.list_buckets().send().await { Ok(e) => { println!("This should not run. {:?}", e); } Err(e) => { println!("Successfully failed with error: {:?}", e) } } let sts_config = aws_config::from_env() .credentials_provider(creds.clone()) .load() .await; let sts_client: stsClient = stsClient::new(&sts_config); sleep(Duration::from_secs(10)).await; let assumed_role = sts_client .assume_role() .role_arn(assume_role_role.arn()) .role_session_name(format!("iam_demo_assumerole_session_{uuid}")) .send() .await; println!("Assumed role: {:?}", assumed_role); sleep(Duration::from_secs(10)).await; let assumed_credentials = iamCredentials::from_keys( assumed_role .as_ref() .unwrap() .credentials .as_ref() .unwrap() .access_key_id(), assumed_role .as_ref() .unwrap() .credentials .as_ref() .unwrap() .secret_access_key(), Some( assumed_role .as_ref() .unwrap() .credentials .as_ref() .unwrap() .session_token .clone(), ), ); let succeed_config = aws_config::from_env() .credentials_provider(assumed_credentials) .load() .await; println!("succeed config: {:?}", succeed_config); let succeed_client: s3Client = s3Client::new(&succeed_config); sleep(Duration::from_secs(10)).await; match succeed_client.list_buckets().send().await { Ok(_) => { println!("This should now run successfully.") } Err(e) => { println!("This should not run. {:?}", e); panic!() } } //Clean up. iam_service::detach_role_policy( &client, assume_role_role.role_name(), list_all_buckets_policy.arn().unwrap_or_default(), ) .await?; iam_service::delete_policy(&client, list_all_buckets_policy).await?; iam_service::delete_role(&client, &assume_role_role).await?; println!("Deleted role {}", assume_role_role.role_name()); iam_service::delete_access_key(&client, &user, &key).await?; println!("Deleted key for {}", key.user_name()); iam_service::delete_user_policy(&client, &user, &inline_policy_name).await?; println!("Deleted inline user policy: {}", inline_policy_name); iam_service::delete_user(&client, &user).await?; println!("Deleted user {}", user.user_name()); Ok(()) } ``` + Pour plus de détails sur l’API, consultez les rubriques suivantes dans la *Référence des API du kit AWS SDK pour Rust*. + [AttachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.attach_role_policy) + [CreateAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_access_key) + [CreatePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_policy) + [CreateRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_role) + [CreateUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_user) + [DeleteAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_access_key) + [DeletePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_policy) + [DeleteRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_role) + [DeleteUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user) + [DeleteUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user_policy) + [DetachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.detach_role_policy) + [PutUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.put_user_policy) ------ # Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2 Les applications qui s'exécutent sur une instance Amazon EC2 doivent inclure des AWS informations d'identification dans les demandes d' AWS API. Vous pouvez demander à vos développeurs de stocker les AWS informations d'identification directement dans l'instance Amazon EC2 et d'autoriser les applications de cette instance à utiliser ces informations d'identification. Toutefois, dans ce cas, ils doivent gérer les informations d'identification, les transmettre en toute sécurité à chaque instance, puis mettre à jour chaque instance Amazon EC2 lorsqu'il convient d'effectuer une mise à jour des informations d'identification. Ceci représente beaucoup de travail supplémentaire. Au lieu de cela, il est recommandé d'utiliser un rôle IAM pour gérer les informations d'identification *temporaires* pour les applications qui s'exécutent sur une instance Amazon EC2. Lorsque vous utilisez un rôle, vous n'avez pas besoin de distribuer d'informations d'identification à long terme (telles que des informations de connexion ou des clés d'accès) à une instance Amazon EC2. Le rôle fournit plutôt des autorisations temporaires que les applications peuvent utiliser lorsqu'elles appellent d'autres AWS ressources. Lorsque vous lancez une instance Amazon EC2, vous spécifiez un rôle IAM à associer à celle-ci. Les applications qui s'exécutent sur l'instance peuvent ensuite utiliser les informations d'identification de sécurité temporaires fournies pour le rôle pour signer les demandes d'API. L'utilisation de rôles pour l'octroi d'autorisations à des applications qui s'exécutent sur des instances Amazon EC2 requiert une configuration supplémentaire. Une application exécutée sur une instance Amazon EC2 est extraite du système AWS d'exploitation virtualisé. En raison de cette séparation supplémentaire, vous avez besoin d'une étape supplémentaire pour attribuer un AWS rôle et les autorisations associées à une instance Amazon EC2 et les mettre à la disposition de ses applications. Cette étape supplémentaire est la création d'un *[profil d'instance](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)* attaché à l'instance. Le profil d'instance contient le rôle et peut fournir les informations d'identification temporaires du rôle à une application qui s'exécute sur l'instance. Ces informations d'identification temporaires peuvent ensuite être utilisées dans les appels d'API de l'application pour accéder aux ressources et restreindre l'accès aux ressources spécifiées par le rôle uniquement. **Note** Chaque instance Amazon EC2 ne peut se voir attribuer qu'un seul rôle à la fois, et toutes les applications de l'instance partagent le même rôle et les mêmes autorisations. Lorsque vous exploitez Amazon ECS pour gérer vos instances Amazon EC2, vous pouvez attribuer des rôles aux tâches Amazon ECS qui peuvent être différenciés du rôle de l'instance Amazon EC2 sur laquelle elles s'exécutent. L'attribution d'un rôle à chaque tâche est conforme au principe de l'accès au moindre privilège et permet un contrôle plus précis des actions et des ressources. Pour plus d'informations, veuillez consulter la rubrique [Using IAM roles with Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-iam-roles.html) dans le *Guide des bonnes pratiques pour Amazon Elastic Container Service*. Une telle utilisation des rôles présente plusieurs avantages. Dans la mesure où les informations d'identification des rôles sont temporaires et font automatiquement l'objet d'une mise à jour, vous n'avez pas à les gérer ni à vous soucier de risques de sécurité à long terme. Par ailleurs, si vous utilisez le même rôle pour plusieurs instances, toute modification apportée au rôle se propage automatiquement à toutes les instances. **Note** Même si un rôle est généralement attribué à une instance Amazon EC2 lors du lancement, un rôle peut également être attaché à une instance Amazon EC2 en cours d'exécution. Pour savoir comment attacher un rôle à une instance en cours d'exécution, consultez [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role). **Topics** + [Comment fonctionnent les rôles pour les instances Amazon EC2 ?](#roles-usingrole-ec2instance-roles) + [Autorisations requises pour l'utilisation de rôles avec Amazon EC2](#roles-usingrole-ec2instance-permissions) + [Comment puis-je commencer ?](#roles-usingrole-ec2instance-get-started) + [Informations connexes](#roles-usingrole-ec2instance-related-info) ## Comment fonctionnent les rôles pour les instances Amazon EC2 ? Dans l'illustration suivante, un développeur exécute une application sur une instance Amazon EC2 qui requiert l'accès à un compartiment S3 nommé `amzn-s3-demo-bucket-photos`. Un administrateur crée la fonction du service `Get-pics` et attache le rôle à l'instance Amazon EC2. Le rôle inclut une politique d'autorisations qui accorde un accès en lecture seule au compartiment S3 spécifié. Il inclut également une politique d'approbation qui permet à l'instance Amazon EC2 d'endosser le rôle et de récupérer les informations d'identification temporaires. Lorsque l'application s'exécute sur l'instance, elle peut accéder au compartiment photos en utilisant les informations d'identification temporaires du rôle. L'administrateur n'a pas besoin d'accorder au développeur l'autorisation d'accéder au compartiment photos et le développeur n'a à aucun moment besoin de partager ou gérer les informations d'identification. ![\[Application sur une instance Amazon EC2 accédant à une ressource AWS\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-usingrole-ec2roleinstance.png) 1. L'administrateur utilise IAM pour créer le rôle **Get-pics**. Dans la politique d'approbation du rôle, l'administrateur spécifie que seules les instances Amazon EC2 peuvent endosser le rôle. Dans la politique d'autorisation du rôle, l'administrateur définit des autorisations en lecture seule pour le compartiment `amzn-s3-demo-bucket-photos`. 1. Un développeur lance une instance Amazon EC2 et lui affecte le rôle `Get-pics`. **Note** Si vous utilisez la console IAM, le profil d'instance est géré de manière quasiment transparente pour vous. Toutefois, si vous utilisez l'API AWS CLI or pour créer et gérer le rôle et l'instance Amazon EC2, vous devez créer le profil d'instance et lui attribuer le rôle séparément. Ensuite, lorsque vous lancez l'instance, vous devez spécifier le nom du profil d'instance à la place du nom de rôle. 1. Lorsque l'application est en cours d'exécution, elle obtient des informations d'identification de sécurité temporaires à partir des [métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) Amazon EC2, comme décrit dans [Extraction des informations d'identification de sécurité à partir des métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials). Il s'agit d'[informations d'identification de sécurité temporaires](id_credentials_temp.md) qui représentent le rôle et sont valides pendant une période limitée. Dans certains cas [AWS SDKs](https://aws.amazon.com/tools/), le développeur peut utiliser un fournisseur qui gère les informations d'identification de sécurité temporaires de manière transparente. (La documentation individuelle AWS SDKs décrit les fonctionnalités prises en charge par ce SDK pour la gestion des informations d'identification.) Sinon, l'application peut obtenir les informations d'identification temporaires directement à partir des métadonnées d'instance de l'instance Amazon EC2. Les informations d'identification et les valeurs associées se trouvent dans la catégorie `iam/security-credentials/role-name` (dans cet exemple, `iam/security-credentials/Get-pics`) des métadonnées. Si l'application extrait les informations d'identification des métadonnées de l'instance, elle peut les mettre en cache. 1. À l'aide des informations d'identification temporaires obtenues, l'application peut accéder au compartiment photos. Compte tenu de la politique attachée au rôle **Get-pics**, l'application dispose d'autorisations en lecture seule. Les informations d'identification de sécurité temporaires disponibles sur l'instance font automatiquement l'objet d'une mise à jour avant leur expiration, de manière à ce qu'un jeu d'identifiants valide soit toujours disponible. L'application doit simplement obtenir un nouvel ensemble d'informations d'identification à partir des métadonnées de l'instance avant l'expiration des informations d'identification actuelles. Il est possible d'utiliser le AWS SDK pour gérer les informations d'identification afin que l'application n'ait pas besoin d'inclure de logique supplémentaire pour actualiser les informations d'identification. Par exemple, instanciation de clients avec les fournisseurs d'informations d'identification de profil d'instance. En revanche, si l'application extrait les informations d'identification de sécurité temporaires des métadonnées d'instance, puis les met en cache, elle doit obtenir un ensemble d'informations d'identification actualisé toutes les heures, ou au moins 15 minutes avant l'expiration des informations d'identification actuelles. Le délai d'expiration est inclus dans les informations renvoyées dans la catégorie `iam/security-credentials/role-name`. ## Autorisations requises pour l'utilisation de rôles avec Amazon EC2 Pour lancer une instance avec un rôle, le développeur doit avoir l'autorisation de lancer des instances Amazon EC2 et de transmettre des rôles IAM. L'exemple de politique suivant permet aux utilisateurs d'utiliser le AWS Management Console pour lancer une instance avec un rôle. La politique inclut des caractères génériques (`*`) pour autoriser un utilisateur à transmettre n'importe quel rôle et à réaliser les actions Amazon EC2 énumérées. L'action `ListInstanceProfiles` permet aux utilisateurs d'afficher tous les rôles disponibles dans l' Compte AWS. **Example Exemple de politique qui autorise les utilisateurs à lancer une instance avec n'importe quel rôle à l'aide de la console Amazon EC2** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "IamPassRole", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" } } }, { "Sid": "ListEc2AndListInstanceProfiles", "Effect": "Allow", "Action": [ "iam:ListInstanceProfiles", "ec2:Describe*", "ec2:Search*", "ec2:Get*" ], "Resource": "*" } ] } ``` ### Restreindre les rôles pouvant être transmis aux instances Amazon EC2 (en utilisant) PassRole Vous pouvez utiliser l'autorisation `PassRole` pour spécifier les rôles qu'un utilisateur peut transmettre à une instance Amazon EC2 lors de son lancement. Cela évite que l'utilisateur exécute des applications ayant davantage d'autorisations qu'il n'en possède, autrement dit qu'il soit en mesure d'obtenir des droits élevés. Par exemple, supposons qu'une utilisatrice nommée Alice soit uniquement autorisée à lancer des instances Amazon EC2 et à utiliser des compartiments Amazon S3, mais que le rôle qu'elle transmet à une instance Amazon EC2 dispose d'autorisations permettant d'utiliser IAM et Amazon DynamoDB. Dans ce cas, il est possible qu'Alice soit en mesure de lancer l'instance, de s'y connecter, d'obtenir des informations d'identification de sécurité temporaires, puis d'effectuer plus d'actions IAM ou DynamoDB qu'elle n'est autorisée à le faire. Pour limiter les rôles qu'un utilisateur peut transmettre à une instance Amazon EC2, vous pouvez créer une politique qui autorise l'action `PassRole`. Ensuite, vous attachez la politique à l'utilisateur (ou à un groupe IAM auquel il appartient) qui lancera les instances Amazon EC2. Dans l'élément `Resource` de la politique, vous répertoriez les rôles que l'utilisateur peut transmettre aux instances Amazon EC2. Lorsque l'utilisateur lance une instance et lui associe un rôle, Amazon EC2 vérifie si l'utilisateur est autorisé à transmettre ce rôle. Il est entendu que vous devez également vous assurer que le rôle que l'utilisateur est autorisé à transmettre n'inclut pas plus d'autorisations qu'il n'est censé en avoir. **Note** L'action d'API `PassRole` est différente de `RunInstances` ou `ListInstanceProfiles`. Il s'agit plutôt d'une autorisation qui AWS vérifie chaque fois qu'un ARN de rôle est transmis en tant que paramètre à une API (ou que la console le fait au nom de l'utilisateur). Elle permet à un administrateur de contrôler les rôles susceptibles d'être transmis et par quels utilisateurs. Dans le cas présent, elle veille à ce que l'utilisateur soit autorisé à attacher un rôle spécifique à une instance Amazon EC2. **Example Exemple de politique qui autorise un utilisateur à lancer une instance Amazon EC2 avec un rôle spécifique** Dans l'exemple suivant, la politique autorise les utilisateurs à lancer une instance avec un rôle à l'aide de l'API Amazon EC2. L'élément `Resource` spécifie l'Amazon Resource Name (ARN) d'un rôle. En spécifiant l'ARN, la politique accorde à l'utilisateur l'autorisation de transmettre uniquement le rôle `Get-pics`. Si l'utilisateur tente de spécifier un autre rôle lors du lancement d'une instance, l'action échoue. L'utilisateur est autorisé à exécuter n'importe quelle instance, qu'il s'agisse de transmettre un rôle ou non. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/Get-pics" } ] } ``` ### Permettre à un rôle de profil d'instance de passer à un rôle dans un autre compte Vous pouvez permettre à une application qui s'exécute sur une instance Amazon EC2 d'exécuter des commandes dans un autre compte. Pour ce faire, vous devez autoriser le rôle d'instance Amazon EC2 dans le premier compte pour passer à un rôle dans le second compte. Imaginons que vous en utilisiez deux Comptes AWS et que vous souhaitiez autoriser une application exécutée sur une instance Amazon EC2 à exécuter des [AWS CLI](https://aws.amazon.com/cli/)commandes dans les deux comptes. Supposons que l'instance Amazon EC2 existe dans le compte `111111111111`. Cette instance inclut le rôle de profil d'instance `abcd` qui permet à l'appli d'effectuer les tâches Amazon S3 `amzn-s3-demo-bucket1` en lecture seule sur le compartiment dans le même compte `111111111111`. Toutefois, l'application doit également être autorisée à endosser le rôle `efgh` entre comptes pour accéder au compartiment `amzn-s3-demo-bucket2` Amazon S3 dans le compte `222222222222`. ![\[Le schéma montre comment un développeur lance une instance Amazon EC2 dont le rôle est d’accéder aux photos d’un compartiment Amazon S3.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/roles-instance-profile-cross-account.png) Le rôle de profil d'instance Amazon EC2 `abcd` doit disposer des autorisations suivantes pour autoriser l'application à accéder au compartiment Amazon S3 `amzn-s3-demo-bucket1` : ***Politique d'autorisations de rôle `abcd` du compte 111111111111*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1/*", "arn:aws:s3:::amzn-s3-demo-bucket1" ] }, { "Sid": "AllowIPToAssumeCrossAccountRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/efgh" } ] } ``` ------ Le rôle `abcd` doit faire confiance au service Amazon EC2 pour endosser le rôle. Pour ce faire, le rôle `abcd` doit avoir la politique de confiance suivante : ***Politique de confiance de rôle `abcd` du compte 111111111111*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "abcdTrustPolicy", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"Service": "ec2.amazonaws.com"} } ] } ``` ------ Supposons que le rôle `efgh` entre comptes permet aux tâches Amazon S3 en lecture seule sur le compartiment `amzn-s3-demo-bucket2` dans le même compte `222222222222`. Pour ce faire, le rôle `efgh` entre comptes doit avoir la politique d'autorisations suivante : ***Politique d'autorisations de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAccountLevelS3Actions", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowListAndReadS3ActionOnMyBucket", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket2/*", "arn:aws:s3:::amzn-s3-demo-bucket2" ] } ] } ``` ------ Le rôle `efgh` doit autoriser le rôle de profil d'instance `abcd` à l'endosser. Pour ce faire, le rôle `efgh` doit avoir la politique de confiance suivante : ***Politique de confiance de rôle `efgh` du compte 222222222222*** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "efghTrustPolicy", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"} } ] } ``` ------ ## Comment puis-je commencer ? Pour comprendre le fonctionnement des rôles avec les instances Amazon EC2, vous devez utiliser la console IAM pour créer un rôle, lancer une instance Amazon EC2 utilisant ce rôle, puis examiner l'instance en cours d'exécution. Vous pouvez examiner les [métadonnées de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) pour voir comment les informations d'identification temporaires du rôle sont mises à la disposition d'une instance. Il est également possible d'étudier la façon dont une application exécutée sur l'instance peut utiliser un rôle donné. Consultez les ressources suivantes pour en savoir plus. + [Didacticiel des rôles IAM sur les instances Amazon EC2](https://www.youtube.com/watch?v=TlCuOjviOhk). Cette vidéo montre comment utiliser un rôle IAM avec une instance Amazon EC2 pour contrôler ce qu'une application peut faire lorsqu'elle est exécutée sur l'instance. La vidéo montre comment l'application (écrite dans le AWS SDK) peut obtenir des informations d'identification de sécurité temporaires via le rôle. + Procédures SDK. La documentation du AWS SDK inclut des procédures pas à pas qui montrent une application exécutée sur une instance Amazon EC2 qui utilise des informations d'identification temporaires pour les rôles afin de lire un compartiment Amazon S3. Chacune des procédures suivantes comporte des étapes similaires, avec un langage de programmation différent : + [Configuration de rôles IAM pour Amazon EC2 avec le kit SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) dans le *Manuel du développeur AWS SDK pour Java * + [Lancer une instance Amazon EC2 à l'aide du kit SDK pour .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/run-instance.html) dans le *Manuel du développeur AWS SDK pour .NET * + [Création d'une instance Amazon EC2 avec le kit SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ec2-example-create-instance.html) dans le *Manuel du développeur AWS SDK pour Ruby * ## Informations connexes Pour en savoir plus sur la création de rôles pour des instances Amazon EC2, consultez les informations suivantes : + Pour de plus amples informations sur l’[utilisation de rôles IAM avec des instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), accédez au *Guide de l’utilisateur Amazon EC2*. + Pour créer un rôle, consultez [Création d’un rôle IAM](id_roles_create.md) + Pour plus d'informations sur l'utilisation d'informations d'identification de sécurité temporaires, consultez [Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md). + Si vous utilisez l'API ou l'interface de ligne de commande (CLI) IAM vous devez créer et gérer les profils d'instance IAM. Pour plus d'informations sur les profils d'instance, consultez [Utilisation des profils d’instance](id_roles_use_switch-role-ec2_instance-profiles.md). + Pour plus d’informations sur les informations d’identification de sécurité temporaires pour les rôles dans les métadonnées d’instance, consultez [Extraction des informations d’identification de sécurité à partir des métadonnées d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials) dans le *Guide de l’utilisateur Amazon EC2*. # Utilisation des profils d’instance Utilisez un profil d'instance pour transmettre un rôle IAM à une instance EC2. Pour de plus amples informations sur les rôles IAM, consultez [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) dans le *Guide de l’utilisateur Amazon EC2*. ## Gestion de profils d'instance (console) Si vous utilisez le AWS Management Console pour créer un rôle pour Amazon EC2, la console crée automatiquement un profil d'instance et lui donne le même nom que le rôle. Lorsque vous utilisez ensuite la console Amazon EC2 pour lancer une instance avec un rôle IAM, vous pouvez sélectionner un rôle à associer à l'instance. Sur la console, la liste qui s'affiche est une liste de noms de profils d'instance. La console ne crée pas de profil d'instance pour un rôle qui n'est pas associé à Amazon EC2. Vous pouvez utiliser le AWS Management Console pour supprimer des rôles IAM et des profils d'instance pour Amazon EC2 si le rôle et le profil d'instance portent le même nom. Pour en savoir plus sur la suppression de profils d'instance, veuillez consulter [Suppression de rôles ou de profils d’instance](id_roles_manage_delete.md). **Note** Pour mettre à jour les autorisations d’une instance, remplacez son profil d’instance. Nous vous déconseillons de supprimer un rôle d’un profil d’instance, car cette modification peut prendre jusqu’à une heure avant de prendre effet. ## Gestion des profils d'instance (AWS CLI ou AWS API) Si vous gérez vos rôles à partir de l'API AWS CLI ou de l' AWS API, vous créez des rôles et des profils d'instance en tant qu'actions distinctes. Étant donné que les rôles et les profils d'instance peuvent porter des noms différents, vous devez connaître les noms de vos profils d'instance, ainsi que ceux des rôles qu'ils contiennent. De cette façon, vous pouvez choisir le profil d'instance correct lorsque vous lancez une instance EC2. Vous pouvez attacher des balises à vos ressources IAM, y compris les profils d'instance, pour les identifier, les organiser et contrôler l'accès. Vous pouvez baliser les profils d'instance uniquement lorsque vous utilisez l' AWS API AWS CLI or. **Note** Un profil d'instance peut contenir un seul rôle IAM, mais un rôle peut être inclus dans plusieurs profils d'instance. Cette limite est d'un rôle par profil d'instance ne peut pas être augmentée. Vous pouvez supprimer le rôle existant, puis ajouter un autre rôle à un profil d'instance. Vous devez ensuite attendre que le changement apparaisse dans l'ensemble pour des AWS raisons de [cohérence éventuelle](https://en.wikipedia.org/wiki/Eventual_consistency). Pour forcer la modification, vous devez [dissocier le profil d'instance](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html), puis [associer le profil d'instance](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html), ou vous pouvez arrêter votre instance, puis la redémarrer. ### Gestion de profils d'instance (AWS CLI) Vous pouvez utiliser les AWS CLI commandes suivantes pour utiliser les profils d'instance d'un AWS compte. + Création d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) + Balisage d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html) + Affichage de la liste des balises d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html) + Suppression des balises d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html) + Ajout d'un rôle à un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) + Affichage d'une liste de profils d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html), [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html) + Obtention d'informations sur un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html) + Suppression d'un rôle d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html) + Suppression d'un profil d'instance : [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html) Vous pouvez également attacher un rôle à une instance EC2 déjà en cours d'exécution à l'aide des commandes suivantes. Pour de plus amples informations, veuillez consulter la section [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role). + Attachement d'un profil d'instance avec un rôle à une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) + Obtention d'informations sur un profil d'instance attaché à une instance EC2 : [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) + Détachement d'un profil d'instance avec un rôle d'une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) ### Gestion des profils d'instance (AWS API) Vous pouvez appeler les opérations d' AWS API suivantes pour travailler avec des profils d'instance dans un Compte AWS. + Création d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) + Balisage d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) + Affichage de la liste des balises d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) + Suppression des balises d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) + Ajout d'un rôle à un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) + Affichage d'une liste de profils d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html), [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html) + Obtention d'informations sur un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html) + Suppression d'un rôle d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html) + Suppression d'un profil d'instance : [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) Vous pouvez également attacher un rôle à une instance EC2 déjà en cours d'exécution en appelant les opérations suivantes. Pour de plus amples informations, veuillez consulter la section [Rôles IAM pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role). + Attachement d'un profil d'instance avec un rôle à une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html) + Obtention d'informations sur un profil d'instance attaché à une instance EC2 : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html) + Détachement d'un profil d'instance avec un rôle d'une instance EC2 arrêtée ou en cours d'exécution : [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)