Passer au contenu

Comment puis-je résoudre les problèmes de récupération des métadonnées d'instance sur mon instance Linux EC2 ?

Lecture de 8 minute(s)
0

Je n'arrive pas à récupérer les métadonnées de mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2).

Brève description

Amazon EC2 accède localement aux métadonnées d'instance dans l’instance via des requêtes HTTP adressées au point de terminaison IPv4 169.254.169.254 ou au point de terminaison IPv6 [fd00:ec2::254]. Pour accéder aux métadonnées d'instance, vous devez utiliser le service de métadonnées d'instance (IMDS). IMDSv1 ne nécessite pas de jeton d'authentification, mais IMDSv2 requiert un jeton de session pour une sécurité renforcée.

Lorsque vous récupérez des métadonnées d'instance, vous pouvez rencontrer les problèmes suivants :

  • Erreurs de requête HTTP, telles que des délais d'attente et des erreurs HTTP 400 ou 404
  • Échecs de demande de jeton IMDSv2
  • Problèmes de traitement spécifiques au logiciel
  • Interface réseau ou table de routage mal configurée
  • Configurations de passerelle proxy ou NAT qui bloquent l'accès aux métadonnées
  • (IPv6 uniquement) Un point de terminaison IMDSv6 qui n'est pas activé
  • Attachements de profil d'instance Gestion des identités et des accès AWS (AWS IAM) manquants ou obsolètes
  • Pare-feux locaux tels que iptables ou firewalld qui bloquent l'accès à 169.254.169.254
  • Volume de demandes élevé qui entraîne une limitation des demandes de métadonnées

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Résoudre les erreurs de requête HTTP

Effectuez les actions de dépannage suivantes en fonction du code d’erreur HTTP que vous recevez.

(IMDSv1 uniquement) Erreur « 404 - Not Found »

L'erreur HTTP 404 se produit lorsque vous entrez une URL qui n'est pas valide ou lorsque vous avez mis à jour le rôle IAM de votre instance mais que vous ne l'avez pas actualisé.

Pour résoudre cette erreur, vérifiez que vous utilisez la bonne URL. Vous pouvez également détacher puis rattacher le rôle IAM de votre instance.

Puis, démarrez et arrêtez votre instance pour appliquer les modifications.

(IMDSv2 uniquement) Erreur « 400 - Bad Request »

L'erreur HTTP 400 se produit lorsque votre requête PUT utilise un jeton non valide ou lorsque le logiciel envoie des en-têtes incorrects. Par exemple, certains agents FortiGate ou Matillion ne mettent pas en cache ou ne réutilisent pas les jetons IMDSv2.

Pour résoudre cette erreur, exécutez la commande suivante afin de générer un nouveau jeton pour votre requête PUT :

$ TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl

Consultez également les journaux du système ou d’application pour détecter les processus de longue durée qui doivent actualiser leurs jetons.

(IMDSv2 uniquement) Erreur « 401 - Unauthorized »

L'erreur HTTP 401 se produit lorsque votre requête GET utilise un jeton non valide.

Pour résoudre cette erreur, exécutez la commande suivante afin de générer un nouveau jeton pour votre requête GET :

$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

Consultez également les journaux du système ou d’application pour détecter les processus de longue durée qui doivent actualiser leurs jetons.

Erreur « 403 - Forbidden »

L'erreur HTTP 403 se produit lorsque vous désactivez l’IMDS au niveau de l'instance ou lorsqu'un groupe de sécurité, un pare-feu ou une table de routage bloque l'accès à l'instance. Cette erreur peut également se produire si vous devez utiliser IMDSv2, mais que le client utilise IMDSv1.

Pour résoudre ce problème, exécutez la commande describe-instances de l'interface de ligne de commande AWS suivante pour vérifier la configuration de l’IMDS :

aws ec2 describe-instances --instance-ids your_instance_id --query 'Reservations[].Instances[].MetadataOptions'

Remarque : Remplacez your_instance_id par votre ID d'instance.

Si HttpEndpoint est défini sur désactivé, exécutez la commande modify-instance-metadata-options suivante pour activer l’IMDS :

aws ec2 modify-instance-metadata-options --instance-id your_instance_id --http-endpoint enabled

Remarque : Remplacez your_instance_id par votre ID d'instance.

Assurez-vous que votre configuration autorise l'accès HTTP sortant à 169.254.169.254 (pour IPv4) ou [fd00:ec2::254] (pour IPv6) depuis l'instance.

Si votre instance utilise un proxy, une configuration NAT, un équilibreur de charge ou plusieurs points de réseau internes, il est recommandé de configurer HttpPutResponseHopLimit sur 2 ou une valeur supérieure. Configurez une valeur de saut suffisamment élevée pour permettre à la réponse du jeton de traverser les couches du réseau. Par défaut, HttpPutResponseHopLimit autorise 1 saut uniquement. Pour augmenter cette valeur, exécutez la commande modify-instance-metadata-options suivante :

aws ec2 modify-instance-metadata-options --instance-id your_instance_id --http-put-response-hop-limit 2

Remarque : Remplacez your_instance_id par votre ID d'instance.

Vérifier les problèmes de configuration du proxy

Si votre instance utilise un proxy pour accéder à Internet, vous devez exclure l'adresse IP IMDS du trafic proxy. Si tel n'est pas le cas, vous pouvez recevoir des erreurs HTTP 403 et 404 ou recevoir des délais de connexion.

Pour exclure les adresses IP IMDS du proxy, exécutez la commande suivante pour définir la variable d'environnement no_proxy :

export no_proxy='169.254.169.254,[fd00:ec2::254]'

Remarque : Certaines applications, telles que Matillion, Fortigate ou des services personnalisés, peuvent ne pas utiliser les paramètres no_proxy au niveau du système. Dans ce scénario, configurez no_proxy dans l'application. Pour une configuration à double pile, veillez à exclure les points de terminaison des métadonnées IPv4 et IPv6.

S’assurer d’avoir activé la prise en charge d’IPv6

Si vous utilisez un sous-réseau IPv6 uniquement, exécutez la commande modify-instance-metadata-options suivante pour activer explicitement la prise en charge d’IPv6 pour l’IMDS :

aws ec2 modify-instance-metadata-options \
  --instance-id your_instance_id \
  --http-protocol-ipv6 enabled

Remarque : Remplacez your_instance_id par votre ID d'instance.

Si vous utilisez des points de terminaison de cloud privé virtuel (VPC) avec des règles de groupe de sécurité strictes, assurez-vous qu'ils autorisent l'accès via le port 80 (HTTP) à l'adresse IP des métadonnées.

Pour les applications Fortigate ou Matillion, vérifiez que le logiciel prend en charge les jetons de session IMDSv2.

Résoudre les problèmes liés à une configuration réseau obsolète, à des associations de rôles IAM obsolètes ou à des problèmes logiciels internes

Redémarrez votre instance.

Vérifier les règles de votre pare-feu local

Pour vérifier si les blocs de pare-feu locaux utilisent iptables pour bloquer l'accès au point de terminaison IMDS, exécutez la commande suivante :

sudo iptables -L

Exemple de sortie d'un point de terminaison bloqué :

Chain OUTPUT (policy ACCEPT)
target     prot opt source    destination
REJECT     tcp  --  anywhere  169.254.169.254  owner UID match 1000-10000 reject-with icmp-port-unreachable

Pour vérifier les règles qui bloquent le trafic vers 169.254.169.254, exécutez la commande suivante :

curl http://169.254.169.254/latest/meta-data/

Si une règle bloque le trafic, vous recevez un résultat similaire à l'exemple suivant :

curl: (7) Failed to connect to 169.254.169.254 port 80 after 0 ms: Connection refused

Pour supprimer la règle de blocage, exécutez la commande suivante :

sudo iptables -D OUTPUT -p tcp -d 169.254.169.254 -m owner --uid-owner 1000-10000 -j REJECT

Si votre instance est de type à double pile, assurez-vous qu'aucune règle de pare-feu IPv6 ne bloque l'adresse IPv4 [fd00:ec2::254]. Si vos iptables sont vides, mais que le trafic est toujours bloqué, vérifiez les démons du pare-feu du système d'exploitation (OS) tels que firewalld ou ufw. Vérifiez également les agents de sécurité, tels que les logiciels antivirus ou de pare-feu, susceptibles d'appliquer des règles cachées.

Vérifier si Amazon EC2 a limité votre requête

Amazon EC2 limite le trafic vers l'IMDS en fonction du nombre de paquets par seconde (PPS). Chaque interface réseau Elastic attachée à l'instance dispose d'un quota maximum de 1024 PPS pour le trafic lié aux métadonnées. Si votre débit PPS dépasse ce quota, des erreurs « HTTP 5xx » s’affichent, la récupération des métadonnées échoue ou l'application expire.

Pour atténuer les problèmes de limitation, procédez comme suit :

  • Implémentez un backoff exponentiel et une logique de nouvelle tentative dans votre application lorsque vous accédez à l’IMDS.
  • Consultez votre fournisseur ou mettez à jour votre logiciel vers la dernière version pour vous assurer qu'il est compatible avec IMDSv2.
  • Lorsque vous utilisez IMDSv2, générez un jeton une seule fois et réutilisez-le pour plusieurs requêtes de métadonnées pendant sa durée de vie (TTL).
  • Effectuez une mise à niveau vers la dernière version d'IMDSv2 pour vous assurer que votre configuration implémente correctement la réutilisation des jetons et le backoff exponentiel.
  • N'interrogez pas fréquemment les métadonnées d’instance.
  • Utilisez la mise en cache des instances dans votre application chaque fois que possible.

Si votre logiciel inonde sans délai les demandes de métadonnées en boucle serrée, vous pouvez rencontrer des problèmes de limitation ou de défaillance des métadonnées. Utilisez les journaux de débogage tcpdump, strace ou d’application pour vérifier les appels répétés fréquents à 169.254.169.254. Pour surveiller les événements de limitation, exécutez la commande suivante pour vérifier le pilote de l'interface réseau pour la métrique linklocal_allowance_exceeded :

ethtool -S eth0

Remarque : Remplacez eth0 par le nom de votre interface réseau. Dans la sortie, vérifiez que linklocal_allowance_exceeded contient une valeur différente de 0 pour identifier la limitation.

Exemple de sortie :

linklocal_allowance_exceeded: 245

L'exemple de sortie précédent montre qu'Amazon EC2 a limité 245 paquets vers l’IMDS en raison d'un dépassement du quota PPS.

Informations connexes

Utilisation d'un proxy sur les instances Amazon EC2

Accéder aux métadonnées d'instance pour une instance EC2

Limiter l'accès au service de métadonnées d'instance

Limitation des requêtes

AWS OFFICIELA mis à jour il y a 6 mois