Résolution des problèmes liés aux rôles IAM

Utilisez ces informations pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lors de l'utilisation des rôles IAM.

Je ne parviens pas à endosser un rôle

Vérifiez les éléments suivants :

• Pour permettre aux utilisateurs d'endosser à nouveau le rôle actuel au cours d'une séance de rôle, spécifiez l'ARN du rôle ou l'ARN de l'Compte AWS en tant que principal dans la politique d'approbation des rôles. Les Services AWS qui offrent des ressources de calcul telles qu'Amazon EC2, Amazon ECS, Amazon EKS et Lambda fournissent des informations d'identification temporaires et procèdent à leur mise à jour automatique. 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 ou une politique de 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 du rôle du principal ou l'ARN du Compte AWS, veuillez consulter Modification d'une politique d'approbation de rôle (console).

• Lorsque vous endossez un rôle à l'aide de la AWS Management Console, veillez à utiliser le nom exact de votre rôle. Les noms de rôle sont sensibles à la casse lorsque vous endossez un rôle.

• Lorsque vous endossez un rôle en utilisant l'API AWS STS ou la AWS CLI, veillez à utiliser le nom exact de votre rôle dans l'ARN. Les noms de rôle sont sensibles à la casse lorsque vous endossez un rôle.

• Vérifiez que votre politique IAM vous accorde l'autorisation d'appeler sts:AssumeRole pour le rôle que vous voulez endosser. L'élément Action de votre politique IAM doit vous autoriser à appeler l'action AssumeRole. En outre, l'élément Resource de votre politique IAM doit spécifier le rôle que vous voulez endosser. Par exemple, l'élément Resource peut spécifier un rôle en utilisant son ARN (Amazon Resource Name) ou à l'aide d'un caractère générique (*). Par exemple, au moins une politique s'appliquant à vous doit accorder des autorisations similaires à ce qui suit :

      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"

• Vérifiez que votre identité IAM est balisée avec les balises que la politique IAM requiert. Par exemple, dans la politique d'autorisations suivante, l'élément Condition exige que vous, en tant que principal demandant à endosser le rôle, ayez une balise spécifique. Vous devez être balisé avec department = HR ou department = CS. Dans le cas contraire, vous ne pouvez pas endosser le rôle. Pour en savoir plus sur le balisage des utilisateurs et rôles IAM, veuillez consulter Balisage des ressources IAM.

      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*",
      "Condition": {"StringEquals": {"aws:PrincipalTag/department": [
              "HR",
              "CS"
          ]}}

• Assurez-vous que vous respectez toutes les conditions spécifiées dans la politique d'approbation du rôle. Une Condition peut spécifier une date d'expiration, un ID externe, ou exiger qu'une demande provienne uniquement d'adresses IP spécifiques. Prenons l'exemple suivant. Si la date actuelle se situe après la date spécifiée, la politique ne correspond jamais et, par conséquent, elle ne peut par vous accorder l'autorisation d'endosser le rôle.

      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"
      "Condition": {
          "DateLessThan" : {
              "aws:CurrentTime" : "2016-05-01T12:00:00Z"
          }
      } 

• Vérifiez que l'Compte AWS à partir duquel vous appelez AssumeRole est une entité approuvée pour le rôle que vous endossez. Les entités approuvées sont définies en tant que Principal dans la politique d'approbation d'un rôle. L'exemple suivant est une politique de confiance attachée au rôle que vous voulez endosser. Dans cet exemple, l'ID de compte avec l'utilisateur IAM avec lequel vous vous êtes connecté doit être 123456789012. Si votre numéro de compte n'est pas répertorié dans l'élément Principal de la politique de confiance du rôle, vous ne pouvez pas endosser le rôle. Peu importent les autorisations qui vous sont accordées dans les politiques d'accès. Notez que l'exemple de politique limite les autorisations aux actions susceptibles de se produire entre le 1er juillet 2017 et le 31 décembre 2017 (UTC), inclus. Si vous vous connectez avant ou après ces dates, la politique de correspond pas et vous ne pouvez pas endosser le rôle.

      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
        "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
      }
  

• Identité source : les administrateurs peuvent configurer les rôles de sorte à exiger des identités qu'elles transmettent une chaîne personnalisée identifiant la personne ou l'application qui effectue des actions dans AWS. On appelle cela l'identité source. Vérifiez si le rôle endossé exige qu'une identité source soit définie. Pour de plus amples informations sur l'identité source, veuillez consulter Surveiller et contrôler les actions prises avec les rôles endossés.

Un nouveau rôle est apparu dans mon compte AWS

Certains services AWS nécessitent que vous utilisiez un type de rôle de service unique qui est directement lié au service. Ce rôle lié à un service est prédéfini par le service et comprend toutes les autorisations nécessaires au service. La configuration d'un service est ainsi simplifiée, étant donné que vous n'avez pas besoin d'ajouter manuellement les autorisations requises. Pour obtenir des informations générales sur les rôles liés à un service, veuillez consulter Utilisation des rôles liés à un service.

Vous utilisez peut être déjà un service lorsqu'il commence à prendre en charge des rôles de service liés à un service. Dans ce cas, il est possible que vous receviez un e-mail vous informant d'un nouveau rôle dans votre compte. Ce rôle comprend toutes les autorisations dont le service a besoin pour effectuer des actions en votre nom. Aucune action de votre part n'est requise pour prendre ce rôle en charge. Cependant, vous ne devez pas supprimer le rôle de votre compte. En effet, la suppression risquerait de supprimer des autorisations dont le service a besoin pour accéder aux ressources AWS. Pour afficher les rôles liés à un service de votre compte, allez sur la page IAM Roles (Rôles IAM) de la console IAM. 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.

Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, reportez-vous à la rubrique AWS services qui fonctionnent avec IAM et recherchez les services affichant Oui dans la colonne Rôle lié à un service. Pour plus d'informations sur l'utilisation du rôle lié à un service, sélectionnez le lien Oui.

Je ne parviens pas à modifier ou supprimer un rôle dans mon Compte AWS

Vous ne pouvez pas supprimer ni modifier les autorisations d'un rôle lié à un service dans IAM. Ces rôles comportent des approbations et des autorisations prédéfinies requises par le service afin d'exécuter des actions en votre nom. Vous pouvez utiliser la console IAM, la AWS CLI ou l'API pour modifier uniquement la description d'un rôle lié à un service. 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 Récapitulatif d'un rôle indique aussi que le rôle est lié à un service. Vous pouvez gérer et supprimer ces rôles uniquement via le service lié, si celui-ci prend en charge l'action. Soyez vigilant lorsque vous modifiez ou supprimez un rôle lié à un service car cela peut supprimer des autorisations requises par le service pour accéder aux ressources AWS.

Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, reportez-vous à la rubrique AWS services qui fonctionnent avec IAM et recherchez les services affichant Oui dans la colonne Rôle lié à un service.

Je ne suis pas autorisé à exécuter : iam:PassRole

Lorsque vous créez un rôle lié à un service, vous devez être autorisé à 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 créer un groupe Auto Scaling sans l'autorisation PassRole, vous recevez le message d'erreur suivant :

ClientError: An error occurred (AccessDenied) when calling the PutLifecycleHook operation: User: arn:aws:sts::111122223333:assumed-role/Testrole/Diego is not authorized to perform: iam:PassRole on resource: arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling

Pour corriger cette erreur, demandez à votre administrateur d'ajouter l'autorisation iam:PassRole pour vous.

Pour savoir quels services prennent en charge les rôles liés à un service, veuillez consulter AWS services qui fonctionnent avec IAM. Pour savoir si un service crée automatiquement un rôle lié à un service, sélectionnez le lien Oui pour afficher la documentation du rôle lié à ce service.

Pourquoi ne puis-je pas endosser un rôle avec une session de 12 heures ? (AWS CLI, API AWS)

Lorsque vous utilisez des opérations d'API AWS STS ou des opérations de CLI AssumeRole* assume-role* pour endosser un rôle, vous pouvez spécifier une valeur pour le paramètre DurationSeconds. Vous pouvez spécifier une valeur comprise entre 900 secondes (15 minutes) et la valeur de durée de session maximale définie pour le rôle. Si vous spécifiez une valeur supérieure à ce paramètre, l'opération échoue. La valeur maximale de ce paramètre est de 12 heures. Par exemple, si vous spécifiez une durée de session de 12 heures, mais que votre administrateur a défini la durée de session maximale à 6 heures, votre opération échoue. Pour savoir comment afficher la valeur maximale pour votre rôle, veuillez consulter Affichage du paramètre de durée de session maximale pour un rôle.

Si vous utilisez la création de chaînes de rôles (en utilisant un rôle pour endosser un second rôle), votre session est limitée à une heure maximum. Si vous utilisez ensuite le paramètre DurationSeconds pour fournir une valeur supérieure à une heure, l'opération échoue.

Je reçois une erreur lorsque j'essaie de changer de rôle dans la console IAM

Les informations que vous entrez sur la page Changer de rôle doivent correspondre à celles du rôle. Sinon, l'opération échoue et vous recevez l'erreur suivante :

Invalid information in one or more fields. Check your information or contact your administrator.

Si vous recevez cette erreur, confirmez que les informations suivantes sont correctes :

• Account ID or alias (ID de compte ou alias) : l'ID d'Compte AWS est un numéro de 12 chiffres. Votre compte peut avoir un alias, qui est un identifiant convivial tel que le nom de votre entreprise qui peut être utilisé à la place de votre ID d'Compte AWS. Vous pouvez utiliser l'ID de compte ou l'alias dans ce champ.

• Role name (Nom de rôle) : les noms de rôle sont sensibles à la casse. L'ID du compte et le nom du rôle doivent correspondre à ce qui est configuré pour le rôle.

Si vous continuez à recevoir un message d'erreur, contactez votre administrateur pour vérifier les informations précédentes. La politique d'approbation de rôle ou la politique utilisateur IAM peut limiter votre accès. Votre administrateur peut vérifier les autorisations pour ces politiques.

Mon rôle dispose d'une politique qui me permet d'effectuer une action, mais j'obtiens « Accès refusé »

Votre session peut être limitée par les politiques de session. Lorsque vous demandez des informations d'identification de sécurité temporaires par programmation à l'aide de l'outil AWS STS, vous pouvez, si vous le souhaitez, transmettre des politiques de 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. 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 politiques basées sur l'identité du rôle et des politiques de session. Sinon, si votre administrateur ou un programme personnalisé vous fournit des informations d'identification temporaires, ils peuvent avoir inclus une politique de session pour limiter votre accès.

Le service n'a pas créé la version de politique par défaut du rôle

Un rôle de service est un rôle qu'un service endosse pour effectuer des actions dans votre compte en votre nom. Lorsque vous configurez certains environnements de services AWS, vous devez définir un rôle que ce service devra endosser. Dans certains cas, le service crée le rôle de service et sa politique dans IAM pour vous. Bien que vous puissiez modifier ou supprimer le rôle de service et sa politique depuis IAM, AWS ne le recommande pas. Le rôle et la politique sont destinés à être utilisés uniquement par ce service. Si vous modifiez la politique et configurez un autre environnement, lorsque le service tente d'utiliser le même rôle et la même politique, l'opération peut échouer.

Par exemple, lorsque vous utilisez AWS CodeBuild pour la première fois, le service crée un rôle nommé codebuild-RWBCore-service-role. Ce rôle de service utilise la politique nommée codebuild-RWBCore-managed-policy. Si vous modifiez la politique, elle crée une nouvelle version et enregistre cette version en tant que version par défaut. Si vous effectuez une opération ultérieure dans AWS CodeBuild, le service peut essayer de mettre à jour la politique. Si c'est le cas, vous recevez l'erreur suivante :

codebuild.amazon.com did not create the default version (V2) of the codebuild-RWBCore-managed-policy policy that is attached to the codebuild-RWBCore-service-role role. To continue, detach the policy from any other identities and then delete the policy and the role.

Si vous recevez cette erreur, vous devez apporter des modifications dans IAM avant de pouvoir poursuivre votre opération de service. Tout d'abord, définissez la version de la politique par défaut sur V1 et réessayez l'opération. Si V1 a déjà été supprimé, ou si le choix de V1 ne fonctionne pas, nettoyez et supprimez la politique et le rôle existants.

Pour de plus amples informations sur la modification des politiques gérées, veuillez consulter Modification de politiques gérées par le client (console). Pour plus d'informations sur les versions de politique, veuillez consulter Gestion des versions des politiques IAM.

Pour supprimer un rôle de service et sa politique

1. Connectez-vous à la AWS Management Console et ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.

2. Dans le panneau de navigation, sélectionnez Policies (Politiques).

3. Dans la liste des politiques, sélectionnez le nom de la politique à supprimer.

4. Choisissez l'onglet Entités attachées pour afficher les utilisateurs, groupes ou rôles IAM qui utilisent cette politique. Si l'une de ces identités utilise la politique, effectuez les tâches suivantes :

   1. Créez une nouvelle politique gérée avec les autorisations nécessaires. Pour vous assurer que les identités disposent des mêmes autorisations avant et après vos actions, copiez le document de politique JSON à partir de la politique existante. Créez ensuite la nouvelle politique gérée et collez le document JSON comme décrit dans la section Création de politiques à l'aide de l'éditeur JSON.

   2. Pour chaque identité affectée, joignez la nouvelle politique, puis détachez l'ancienne. Pour de plus amples informations, veuillez consulter Ajout et suppression d'autorisations basées sur l'identité IAM.

5. Dans le panneau de navigation, sélectionnez Roles (Rôles).

6. Dans la liste des rôles, sélectionnez le nom du rôle à supprimer.

7. Cliquez sur l'onglet Relations d'approbation pour afficher les entités qui peuvent endosser le rôle. Si une entité autre que le service est répertoriée, effectuez les tâches suivantes :

   1. Créez un nouveau rôle qui approuve ces entités.

   2. Politique que vous avez créée à l'étape précédente. Si vous avez ignoré cette étape, créez la nouvelle politique gérée maintenant.

   3. Avisez toute personne qui endossait le rôle qu'elle ne peut plus le faire. Donnez-lui des informations sur la façon d'endosser le nouveau rôle et d'avoir les mêmes autorisations.

8. Supprimez la politique.

9. Supprimez le rôle.

Il n'existe aucun cas d'utilisation pour un rôle de service dans la console

Certains services exigent que vous créiez manuellement un rôle de service pour accorder au service les autorisations nécessaires pour effectuer des actions en votre nom. Si le service n'est pas répertorié dans la console IAM, vous devez répertorier manuellement le service en tant que principal de confiance. Si la documentation du service ou de la fonctionnalité que vous utilisez ne contient pas d'instructions pour intégrer le service à la liste des principaux de confiance, soumettez des commentaires pour la page.

Pour créer manuellement un rôle de service, vous devez connaître le principal de service du service qui endossera le rôle. Un principal de service est un identifiant utilisé pour accorder des autorisations à un service. Le principal de service est défini par le service.

Vous pouvez trouver le principal de service pour certains services en vérifiant les éléments suivants :

1. Ouvrir AWS services qui fonctionnent avec IAM.

2. Vérifiez si le service indique Oui dans la colonne Rôles liés à un service .

3. Choisissez le lien Oui pour consulter la documentation du rôle lié à ce service.

4. Recherchez la section Autorisations de rôles liés à un service correspondant à ce service pour afficher le principal du service.

Vous pouvez créer manuellement un rôle de service à l'aide de commandes AWS CLI ou d'opérations d'API AWS. Pour créer manuellement un rôle de service à l'aide de la console IAM, effectuez les tâches suivantes :

1. Créez un rôle IAM à l'aide de votre ID de compte. N'attachez pas de politique et n'accordez aucune autorisation. Pour plus de détails, veuillez consulter Création d'un rôle pour la délégation d'autorisations à un utilisateur IAM..

2. Ouvrez le rôle et modifiez la relation d'approbation. Au lieu d'approuver le compte, le rôle doit approuver le service. Par exemple, mettez à jour l'élément Principal suivant :

   "Principal": { "AWS": "arn:aws:iam::123456789012:root" }

   Modifiez le principal par la valeur de votre service, par exemple, IAM.

   "Principal": { "Service": "iam.amazonaws.com" }

3. Ajoutez les autorisations requises par le service en attachant des politiques d'autorisations au rôle.

4. Revenez au service qui nécessite les autorisations et utilisez la méthode décrite dans la documentation pour informer le service du nouveau rôle de service.