Résolution des problèmes 'Accès Refusé' et d'authentification dans l'AWS CLI

Accès Refusé dans l'AWS CLI est frustrant car le message nomme souvent l'appel API échoué mais pas la ligne de politique qui l'a causé. Ces problèmes sont presque toujours liés à des politiques IAM mal configurées, des identifiants temporaires expirés, ou une configuration incorrecte de l'environnement CLI.

L'habitude utile est de diviser le problème en deux questions : qui est l'appelant CLI, et quelle limite de politique empêche cette identité d'effectuer l'action ?

1. Diagnostic initial : Identification de l'appelant et des identifiants

Avant de plonger dans l'analyse complexe des politiques, la première étape consiste à confirmer définitivement quelle identité IAM l'AWS CLI utilise et si ces identifiants sont toujours valides.

Vérifier l'identité actuelle : `sts get-caller-identity`

C'est la commande de diagnostic la plus critique. Elle vous indique exactement quel ARN d'utilisateur, ARN de rôle, ou session de rôle assumé exécute les commandes AWS suivantes.

aws sts get-caller-identity

Sortie attendue :

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Si l'ARN retourné ne correspond pas à l'utilisateur ou au rôle attendu, vous opérez sous le mauvais profil AWS ou les mauvaises variables d'environnement.

Vérifier la configuration du profil et la région

Assurez-vous que le profil AWS correct est utilisé, soit spécifié via le drapeau --profile, soit défini via la variable d'environnement AWS_PROFILE.

# Vérifier les paramètres configurés pour le profil par défaut
aws configure list

# Ou vérifier un profil spécifique
aws configure list --profile prod-admin

Si la sortie ne montre aucune région ou une région incorrecte, les opérations sur les ressources globales ou les services spécifiques à une région (comme les compartiments S3 ou les instances EC2) peuvent échouer, résultant parfois en un Accès Refusé si la ressource n'est pas trouvée là où la CLI cherche.

Astuce : Si la commande sts get-caller-identity elle-même échoue avec une erreur d'authentification, cela indique un problème fondamental avec les clés d'accès (elles peuvent être supprimées, révoquées ou incorrectes).

Gérer les identifiants temporaires

Si vous utilisez un rôle IAM (via STS AssumeRole), la CLI fonctionne avec des identifiants temporaires qui incluent un SessionToken. Ces identifiants expirent après la durée configurée pour la session, souvent une heure dans les configurations par défaut. Bien que l'AWS CLI les rafraîchisse généralement automatiquement lorsqu'ils proviennent de la chaîne de fournisseurs d'identifiants standard, les configurations manuelles peuvent échouer.

Symptôme : Les commandes fonctionnent initialement, mais échouent après une période définie (par exemple, 60 minutes) avec une erreur d'authentification.

Solution : Si vous utilisez un script personnalisé ou un environnement chargé manuellement, assurez-vous que votre méthode pour assumer le rôle inclut un mécanisme pour rafraîchir les identifiants lorsqu'ils expirent.

2. Plongée dans les politiques IAM et l'autorisation

Une fois l'identité utilisée confirmée, l'étape suivante consiste à déterminer pourquoi cette identité manque des autorisations nécessaires. Les échecs d'autorisation AWS sont complexes car plusieurs politiques sont évaluées simultanément.

La hiérarchie d'évaluation des politiques IAM

Les erreurs d'autorisation surviennent généralement à cause de l'un des composants de politique suivants :

Refus explicite : Une déclaration Deny explicite dans toute politique applicable (Identité, Ressource ou Limite) remplace toujours une déclaration Allow.
Autorisation manquante : Aucune politique applicable à l'identité ou à la ressource n'accorde l'action spécifique.

A. Politiques basées sur l'identité (Utilisateurs et Rôles)

Vérifiez les politiques IAM attachées directement à l'utilisateur ou au rôle assumé. Recherchez :

Actions manquantes : La politique liste-t-elle spécifiquement l'action API nécessaire (par exemple, s3:ListBucket, ec2:DescribeInstances) ?
Contraintes de ressources : La politique restreint-elle l'action à des ressources spécifiques en utilisant l'élément Resource ? Une erreur courante est de définir Resource: "*" alors que l'action nécessite un ARN spécifique, ou vice versa.
Conditions : Y a-t-il des conditions (par exemple, adresse IP source, heure de la journée, MFA requis) qui ne sont pas remplies ?

B. Politiques basées sur les ressources (S3, SQS, KMS)

Pour des services comme S3 ou KMS, la ressource elle-même a une politique qui dicte qui peut y accéder. Pour l'accès entre comptes, et pour de nombreuses conceptions spécifiques aux ressources, la politique de la ressource doit également autoriser le principal. Dans le même compte, l'interaction exacte dépend du type de principal et du service, donc ne supposez pas qu'une politique d'identité explique à elle seule chaque résultat.

Exemple : Tenter d'accéder à un compartiment S3 (Politique de ressource) qui a un Deny explicite pour tous les utilisateurs en dehors d'un point de terminaison VPC spécifique entraînera un Accès Refusé, indépendamment de la politique IAM de l'utilisateur.

C. Limites d'autorisation et SCP

Si votre organisation utilise AWS Organizations, les politiques de contrôle de service (SCP) définissent les autorisations maximales autorisées dans un compte. De même, les limites d'autorisation limitent les autorisations maximales qu'une entité IAM peut jamais posséder.

Si la SCP ou la limite refuse l'action requise, l'opération CLI échouera, même si la politique d'identité accorde l'autorisation.

Outil pratique : Simulateur de politiques IAM

Lors du dépannage d'échecs complexes, le simulateur de politiques IAM dans la console de gestion AWS est inestimable. Vous pouvez tester une action spécifique (par exemple, s3:GetObject) contre une ressource spécifique (par exemple, arn:aws:s3:::my-bucket/key) et spécifier l'entité IAM, vous aidant à identifier exactement quelle déclaration de politique cause le refus.

3. Scénarios courants 'Accès Refusé' et solutions

Scénario 1 : Accès S3 refusé (Ressource vs Identité)

L'Accès Refusé S3 est notoire car il peut provenir soit de la politique utilisateur, soit de la politique de compartiment.

Cause	Diagnostic	Solution
Autorisation manquante dans la politique de compartiment	`sts get-caller-identity` fonctionne, mais `aws s3 ls` échoue.	Modifiez la politique de compartiment pour autoriser explicitement l'ARN appelant à effectuer les actions nécessaires (`s3:ListBucket`, `s3:GetObject`).
Autorisations KMS Decrypt manquantes	L'accès aux objets chiffrés échoue (même si la politique S3 le permet).	Assurez-vous que l'entité IAM a les autorisations pour utiliser la clé KMS sous-jacente (`kms:Decrypt`) qui a chiffré l'objet.
Payeur demandé	Les tentatives de téléchargement de fichiers volumineux échouent.	Si le compartiment nécessite `Requester Pays`, la commande CLI doit inclure le drapeau `--request-payer requester`.

Scénario 2 : Refus implicite dû à des échecs de condition

De nombreuses politiques utilisent des conditions qui imposent les meilleures pratiques de sécurité, comme l'exigence d'une authentification multi-facteurs (MFA).

Si votre politique inclut une condition comme :

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

Et que vous tentez d'exécuter une commande sans MFA authentifié, l'action sera implicitement refusée.

Solution : Pour les commandes nécessitant MFA, vous devez d'abord créer une session STS authentifiée avec votre appareil MFA :

# 1. Obtenir des identifiants temporaires en utilisant votre jeton MFA
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Exporter les AccessKeyId, SecretAccessKey et SessionToken résultants en tant que variables d'environnement pour votre session CLI.

Scénario 3 : Région manquante ou incorrecte

Bien que ce ne soit pas toujours une erreur Accès Refusé, essayer d'effectuer une action sur une ressource sans spécifier la région correcte conduit souvent à des échecs d'autorisation ou de ressource introuvable, surtout lors du travail avec des services régionaux comme EC2, DynamoDB ou EKS.

Solution : Définissez explicitement la région dans votre commande ou assurez-vous que votre profil est correctement configuré.

aws ec2 describe-instances --region us-west-2

Vérifications spécifiques aux services qui font gagner du temps

Les erreurs IAM sont plus faciles à déboguer lorsque vous cessez de traiter AWS comme un seul système d'autorisation. Chaque service ajoute son propre modèle de ressource et ses propres clés de condition.

Pour S3, séparez les actions au niveau du compartiment des actions au niveau de l'objet. s3:ListBucket utilise l'ARN du compartiment, tandis que s3:GetObject et s3:PutObject utilisent les ARN d'objets sous le compartiment. Une politique qui accorde s3:GetObject sur arn:aws:s3:::my-bucket est mal formée ; l'accès aux objets nécessite arn:aws:s3:::my-bucket/*. L'erreur inverse est tout aussi courante pour le listage.

Pour KMS, vérifiez à la fois la politique de clé et la politique IAM. Un rôle peut sembler avoir kms:Decrypt, mais si la politique de clé n'autorise pas ce chemin de rôle, le déchiffrement échoue toujours. Cela se produit lors du téléchargement d'objets S3 chiffrés, du tirage de snapshots EBS chiffrés, ou de la lecture de secrets qui utilisent une clé gérée par le client.

Pour ECR, la connexion Docker et le tirage d'image nécessitent que plusieurs services s'alignent. L'identité CLI peut avoir besoin de ecr:GetAuthorizationToken, et la politique du référentiel peut devoir autoriser les actions de tirage si le référentiel est partagé entre comptes. Si le rôle du nœud de cluster tire l'image, le débogage avec votre profil administrateur personnel ne prouve pas grand-chose ; testez en tant que rôle de nœud ou rôle d'exécution de tâche.

Pour les workflows d'assomption de rôle STS, examinez les deux côtés de la relation de confiance. L'appelant a besoin de l'autorisation d'appeler sts:AssumeRole, et la politique de confiance du rôle cible doit faire confiance à l'appelant. Si un ID externe ou une condition MFA est présent dans la politique de confiance, la commande d'assomption de rôle doit la satisfaire.

La précédence de l'environnement peut tromper les utilisateurs expérimentés

L'AWS CLI ne lit pas seulement ~/.aws/credentials. Elle parcourt une chaîne de fournisseurs d'identifiants qui peut inclure des drapeaux de ligne de commande, des variables d'environnement, des profils nommés, des entrées de cache SSO, des jetons d'identité web, des métadonnées EC2 ou ECS, et des hypothèses de rôle configurées dans le profil. C'est pourquoi aws configure list est plus utile que d'ouvrir un seul fichier.

Un échec local courant ressemble à ceci : vous exécutez export AWS_PROFILE=dev, puis plus tard, vous collez des identifiants de production temporaires dans AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, et AWS_SESSION_TOKEN. Les clés d'environnement peuvent prendre le dessus, donc les commandes qui semblent utiliser dev utilisent en réalité la session exportée. Dans un terminal qui est resté ouvert toute la journée, exécutez :

env | sort | grep '^AWS_'

Si vous changez souvent de compte, utilisez des onglets de terminal séparés, un assistant d'identifiants, ou des scripts wrapper qui impriment l'identité de l'appelant avant les commandes destructrices. La ligne supplémentaire dans la sortie coûte moins cher que la suppression du mauvais compte.

4. Résumé des commandes de diagnostic

Utilisez cette liste de contrôle de commandes pour diagnostiquer rapidement la chaîne d'échec d'autorisation :

Objectif	Commande	But
Vérifier l'identité	`aws sts get-caller-identity`	Confirme l'ARN exécutant la commande.
Vérifier la configuration	`aws configure list`	Vérifie les paramètres du profil, la région et le format de sortie.
Tester la validité de la politique	(Utiliser le simulateur de politiques IAM)	Vérifie si une identité IAM peut effectuer une action API spécifique sur une ressource.
Identifier les refus de politique	`aws cloudtrail lookup-events ...`	Utilisez CloudTrail pour voir l'enregistrement d'événement exact où l'évaluation de la politique a échoué.

Un chemin de débogage réel

Une bonne première passe ressemble à ceci. Exécutez à nouveau la commande défaillante avec le profil et la région écrits explicitement, même si vous pensez que votre shell est déjà configuré :

AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly

Si l'identité est erronée, arrêtez-vous là. Vérifiez AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, et AWS_REGION dans l'environnement. Les identifiants d'environnement peuvent prendre le pas sur un profil et faire agir la CLI comme un rôle que vous avez oublié d'avoir exporté plus tôt. Dans CI, imprimez aws sts get-caller-identity près de l'étape défaillante afin que le journal de construction prouve le rôle utilisé au moment de l'exécution.

Si l'identité est correcte, notez l'action API exacte. Les commandes de haut niveau peuvent cacher cela. aws s3 cp peut nécessiter s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt, ou kms:GenerateDataKey selon la direction, le chiffrement, et si la CLI doit inspecter le compartiment. Lorsque le message d'erreur inclut AccessDenied mais pas l'action, CloudTrail vous donne généralement le nom de l'événement et la ressource.

Pour S3, vérifiez la politique de compartiment, la propriété des objets, les paramètres d'accès public bloqué, la politique du point de terminaison VPC, et la politique de clé KMS. Pour les objets chiffrés par KMS, une autorisation S3 ne suffit pas ; l'appelant a également besoin de l'autorisation KMS pertinente et la politique de clé doit autoriser le chemin du principal. Pour les organisations, vérifiez les SCP avant de modifier les politiques d'identité. Une SCP ne peut pas accorder l'accès, mais elle peut limiter ce que tout principal dans le compte peut faire.

La prévention est surtout une hygiène ennuyeuse : des identifiants de rôle à courte durée de vie, des profils clairement nommés, des politiques de moindre privilège testées contre le véritable ARN, et CloudTrail activé là où les ingénieurs peuvent réellement le consulter. La meilleure solution n'est pas un Action: "*" plus large ; c'est trouver l'action manquante ou la condition de refus qui correspond à la demande.