Résoudre les problèmes liés aux rôles IAM - AWS Identity and Access Management
Je ne parviens pas à endosser un rôleUn nouveau rôle est apparu dans mon compte AWSJe ne parviens pas à modifier ou supprimer un rôle dans mon Compte AWSJe ne suis pas autorisé à exécuter : iam : PassRolePourquoi ne puis-je pas endosser un rôle avec une session de 12 heures ? (AWS CLI, AWS API)Je reçois un message d'erreur lorsque j'essaie de changer de rôle dans la IAM console Mon rôle dispose d'une politique qui me permet d'effectuer une action, mais j'obtiens « Accès refusé »Le service n'a pas créé la version de politique par défaut du rôleIl n'existe aucun cas d'utilisation pour un rôle de service dans la console

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ésoudre les problèmes liés aux rôles IAM

Utilisez les informations fournies ici pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec IAM des rôles.

Je ne parviens pas à endosser un rôle

Vérifiez les éléments suivants :

  • Pour permettre aux utilisateurs d'assumer à nouveau le rôle actuel au cours d'une session de rôle, spécifiez le rôle ARN ou en Compte AWS ARN tant que principal dans la politique de confiance des rôles. Services AWS qui fournissent des ressources de calcul telles qu'AmazonEC2, Amazon ECSEKS, Amazon 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 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 le rôle ARN principal Compte AWS ARN, voirMettre à jour une politique de confiance dans les rôles .

  • Lorsque vous assumez un rôle en utilisant le AWS Management Console, assurez-vous d'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 assumez un rôle en utilisant AWS STS API ou AWS CLI, assurez-vous d'utiliser le nom exact de votre rôle dans leARN. Les noms de rôle sont sensibles à la casse lorsque vous endossez un rôle.

  • Vérifiez que votre IAM politique vous autorise à postuler sts:AssumeRole pour le rôle que vous souhaitez assumer. L'Actionélément de votre IAM politique doit vous permettre de passer à l'AssumeRoleaction. En outre, l'Resourceélément de votre IAM politique doit spécifier le rôle que vous souhaitez assumer. Par exemple, l'Resourceélément peut spécifier un rôle par son Amazon Resource Name (ARN) ou par 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 IAM identité est étiquetée avec toutes les balises requises par la IAM politique. 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 IAM utilisateurs et des rôles, consultezTags pour les AWS Identity and Access Management ressources.

        "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'entité Compte AWS à partir de laquelle vous appelez AssumeRole est une entité fiable pour le rôle que vous assumez. 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 de l'IAMutilisateur 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 effectuées 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 pour exiger que les identités transmettent une chaîne personnalisée identifiant la personne ou l'application qui exécute des actions AWS, appelée 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 AWS services nécessitent que vous utilisiez un type unique de rôle de service 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 Créer un rôle lié à 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 . Vous pouvez consulter les rôles liés aux services dans votre compte en accédant à la page IAM Rôles de la IAM 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.

Pour plus d'informations concernant la prise en charge par les services des rôles liés à un service, reportez-vous à la rubrique AWS des 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 ou modifier les autorisations pour 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 IAM console ou uniquement API modifier la description d'un rôle lié à un service. AWS CLI Vous pouvez consulter les rôles liés aux services de votre compte en accédant à la page IAM Rôles 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 des 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 le rôle AWSServiceRoleForAutoScaling lié à un service pour vous 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 des 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, AWS API)

Lorsque vous utilisez les assume-role* CLI opérations AWS STS AssumeRole* API ou pour assumer un rôle, vous pouvez spécifier une valeur pour le DurationSeconds paramètre. 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 Mettre à jour la durée maximale de session 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 un message d'erreur lorsque j'essaie de changer de rôle dans la IAM console

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 :

  • Identifiant de compte ou alias — L' Compte AWS identifiant est un numéro à 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 Compte AWS identifiant. 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 de confiance des rôles ou la politique IAM utilisateur peuvent 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 le biais d'un programme AWS STS, vous pouvez éventuellement 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 JSON de session en ligne à l'aide du Policy paramètre. 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 AWS service, vous devez définir le rôle que le service doit assumer. Dans certains cas, le service crée le rôle de service et sa politique IAM à votre place. Bien que vous puissiez modifier ou supprimer le rôle de service et sa politique de l'intérieurIAM, AWS cela n'est pas recommandé. 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 l'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 ce message d'erreur s'affiche, vous devez apporter des modifications IAM avant de poursuivre l'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 Politiques de gestion des versions IAM.

Pour supprimer un rôle de service et sa politique

  1. Connectez-vous à la IAM console AWS Management Console et ouvrez-la à 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 jointes pour voir quels IAM utilisateurs, groupes ou rôles 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 JSON politique à partir de la politique existante. Créez ensuite la nouvelle stratégie gérée et collez le JSON document comme décrit dans Création de politiques à l'aide de l'JSONéditeur.

    2. Pour chaque identité affectée, joignez la nouvelle politique, puis détachez l'ancienne. Pour de plus amples informations, veuillez consulter Ajouter et supprimer des autorisations IAM d'identité.

  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 IAM console, vous devez le répertorier manuellement en tant que principal approuvé. 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 des 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 AWS CLI commandes ou AWS APId'opérations. Pour créer manuellement un rôle de service à l'aide de la IAM console, effectuez les tâches suivantes :

  1. Créez un IAM rôle à l'aide de votre identifiant de compte. N'attachez pas de politique et n'accordez aucune autorisation. Pour plus de détails, consultez Création d'un rôle pour déléguer des autorisations à un IAM utilisateur.

  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" }

    Remplacez le principal par la valeur de votre service, par exempleIAM.

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