Récupérer des métadonnées d'instance - Amazon Elastic Compute Cloud

Récupérer des métadonnées d'instance

Puisque vos métadonnées d'instance sont disponibles à partir de votre instance en cours d'exécution, vous n'avez pas besoin d'utiliser la console Amazon EC2, ni la AWS CLI. Cela peut être utile lorsque vous écrivez des scripts à exécuter depuis votre instance. Par exemple, vous pouvez accéder à l'adresse IP locale de votre instance à partir des métadonnées d'instance afin de gérer une connexion à une application externe.

Les métadonnées d'instance sont divisées en plusieurs catégories. Pour obtenir une description de chaque catégorie de métadonnées d'instance, consultez Catégories de métadonnées d'instance.

Pour voir toutes les catégories de métadonnées d'instance depuis une instance en cours d'exécution, utilisez l'URI IPv4 ou IPv6 ci-après.

IPv4

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

IPv6

http://[fd00:ec2::254]/latest/meta-data/

Les adresses IP sont des adresses de lien local et sont uniquement valables à partir de l'instance. Pour plus d'informations, consultez Link-local address sur Wikipedia.

Note

Les exemples de cette section utilisent l'adresse IPv4 du service de métadonnées d'instance : 169.254.169.254. Si vous récupérez des métadonnées d'instance pour les instances EC2 sur l'adresse IPv6, assurez-vous d'activer et d'utiliser l'adresse IPv6 à la place : fd00:ec2::254. L'adresse IPv6 du service de métadonnées d'instance est compatible avec les commandes IMDSv2. L'adresse IPv6 est uniquement accessible sur instances reposant sur le système Nitro.

Le format de la commande est différent selon que vous utilisez IMDSv1 ou IMDSv2. Par défaut, vous pouvez utiliser les deux services de métadonnées d'instance. Pour imposer l'utilisation de IMDSv2, consultez Utiliser IMDSv2.

Vous pouvez utiliser un outil tel que cURL, comme illustré dans l'exemple suivant.

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/

Pour que la commande récupère les métadonnées d'instance à partir d'une instance Windows, reportez-vous à la section Récupérer des métadonnées d'instance dans le Guide de l'utilisateur Amazon EC2 pour les instances Windows.

Coûts

Vous n'êtes pas facturé pour les requêtes HTTP utilisées pour récupérer les métadonnées d'instance et les données utilisateur.

Considérations

Pour éviter les problèmes liés à la récupération des métadonnées d'instance, tenez compte de ce qui suit :

  • Les kits SDK AWS utilisent les appels IMDSv2 par défaut. Si l'appel IMDSv2 ne reçoit aucune réponse, le kit SDK tente de nouveau l'appel et, s'il échoue à nouveau, utilise IMDSv1. Cela peut entraîner un retard. Dans un environnement de conteneur, si la limite de saut est de 1, la réponse de IMDSv2 ne revient pas car un aller vers le conteneur est considéré comme un saut réseau supplémentaire. Pour éviter le processus de retour vers IMDSv1 et le retard qui en résulte, dans un environnement de conteneur, nous vous recommandons de définir la limite de saut à 2. Pour plus d'informations, consultez Configurer les options de métadonnées d'instance.

  • Pour IMDSv2, vous devez utiliser /latest/api/token lors de la récupération du jeton. L'envoi de requêtes PUT à tout chemin spécifique d'une version, par exemple /2021-03-23/api/token, a pour effet que le service de métadonnées retourne des erreurs 403 Interdit. Ce comportement est prévu.

Réponses et messages d'erreur

Toutes les métadonnées d'instance sont retournées sous forme de texte (type de contenu HTTP text/plain).

Une requête pour une ressource de métadonnées spécifique retourne la valeur appropriée ou un code d'erreur HTTP 404 - Not Found si la ressource n'est pas disponible.

Une requête pour une ressource de métadonnées générale (l'URI se termine par un /) retourne une liste de ressources disponibles ou un code d'erreur HTTP 404 - Not Found si une telle ressource n'existe pas. Les éléments de la liste se trouvent sur des lignes séparées se terminant par des sauts de ligne (ASCII 10).

Pour les demandes effectuées à l'aide d'Service des métadonnées d'instance Version 2, les codes d'erreur HTTP suivants peuvent être renvoyés :

  • 400 - Missing or Invalid Parameters – La demande PUT n'est pas valide.

  • 401 - Unauthorized – La demande GET utilise un jeton non valide. Il est recommandé dans ce cas de générer un nouveau jeton.

  • 403 - Forbidden – La demande n'est pas autorisée ou le service des métadonnées d'instance est désactivé.

Exemples de récupération des métadonnées d'instance

Les exemples suivants fournissent des commandes que vous pouvez utiliser sur une instance Linux. Pour que les commandes récupèrent les métadonnées d'instance à partir d'une instance Windows, reportez-vous à la section Récupérer des métadonnées d'instance dans le Guide de l'utilisateur Amazon EC2 pour les instances Windows.

Obtenir les versions disponibles des métadonnées d'instance

Cet exemple permet d'obtenir les versions disponibles des métadonnées d'instance. Chaque version fait référence à un build de métadonnées d'instance lorsque de nouvelles catégories de métadonnées d'instance ont été publiées. Les versions de métadonnées d'instance ne sont pas en corrélation avec les versions de l'API Amazon EC2. Les versions antérieures sont disponibles au cas où vous ayez des scripts reposant sur la structure et les informations présentes dans une version précédente.

Note

Pour éviter de devoir mettre à jour votre code chaque fois qu'Amazon EC2 publie un nouveau build des métadonnées d'instance, nous vous recommandons d'utiliser latest dans le chemin d'accès, et non le numéro de version. Par exemple, utilisez latest comme suit :

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

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 ... latest
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 ... latest

Obtenir les éléments de métadonnées de niveau supérieur

Cet exemple permet d'obtenir les éléments de métadonnées de niveau supérieur. Pour plus d'informations, consultez Catégories de métadonnées d'instance.

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname iam/ instance-action instance-id instance-life-cycle instance-type local-hostname local-ipv4 mac metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname iam/ instance-action instance-id instance-type local-hostname local-ipv4 mac metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/

Les exemples suivants permettent d'extraire les valeurs de certains de éléments de métadonnées de niveau supérieur qui ont été obtenus dans l'exemple précédent. Les demandes IMDSv2 utilisent le jeton stocké qui a été créé dans l'exemple de commande précédent, sous réserve qu'il ne soit pas arrivé à expiration.

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-id ami-0abcdef1234567890

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com

Obtenir la liste des clés publiques disponibles

Cet exemple permet d'obtenir la liste des clés publiques disponibles.

IMDSv2
[ec2-user ~]$ `curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key

Montrer les formats pour lesquels une clé publique 0 est disponible

Cet exemple montre les formats pour lesquels une clé publique 0 est disponible.

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key

Obtenir la clé publique 0 (au format clé OpenSSH)

Cet exemple permet d'obtenir la clé publique 0 (au format clé OpenSSH).

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6 b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ 21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4 nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6 b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ 21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4 nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key

Obtenir l'ID de sous-réseau d'une instance

Cet exemple permet d'obtenir l'ID de sous-réseau pour une instance.

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7

Obtenir les identifications d'une instance

Dans les exemples suivants, l'exemple d'instance possède des identifications sur les métadonnées d'instance activées et les identifications d'instance Name=MyInstance et Environment=Dev.

Cet exemple permet d'obtenir toutes les clés d'identification d'une instance.

IMDSv2
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/tags/instance Name Environment
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/tags/instance Name Environment

L'exemple suivant montre la valeur de la clé Name obtenue dans l'exemple précédent. La demande IMDSv2 utilise le jeton stocké qui a été créé dans l'exemple de commande précédent, sous réserve qu'il ne soit pas arrivé à expiration.

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/tags/instance/Name MyInstance
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/tags/instance/Name MyInstance

Limitation des demandes

Nous limitons les requêtes envoyées par chaque instance au service des métadonnées d'instance et appliquons des limites au nombre de connexions simultanées possible depuis une instance vers le service des métadonnées d'instance.

Si vous utilisez le service des métadonnées d'instance pour récupérer les informations d'identification de sécurité AWS, évitez de demander des informations d'identification pendant chaque transaction ou simultanément depuis un grand nombre de threads ou de processus, car cela risque d'entraîner des restrictions. Nous vous conseillons plutôt de placer les informations d'identification en cache jusqu'à ce que leur date d'expiration approche.

Si vous vous retrouvez limité alors que vous tentez d'accéder au service des métadonnées d'instance, renvoyez une requête avec une stratégie d'interruption exponentielle.

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

Vous pouvez envisager d'utiliser des règles de pare-feu locales pour désactiver l'accès au service des métadonnées d'instance à partir de certains ou de tous les processus.

Note

Pour instances reposant sur le système Nitro, IMDS peut être accessible à partir de votre propre réseau lorsqu'une appliance réseau au sein de votre VPC, telle qu'un routeur virtuel, transfère des paquets à l'adresse IMDS et que la valeur par défaut source/destination check (vérification origine/destination) est désactivée sur l'instance. Pour empêcher qu'une source externe à votre VPC n'accède à IMDS, nous vous recommandons de modifier la configuration de l'appliance réseau afin de supprimer les paquets dont l'adresse IPv4 de destination est IMDS 169.254.169.254 et, si vous avez activé le point de terminaison IPv6, dont l'adresse IPv6 de destination est IMDS fd00:ec2::254.

Utilisation d'éléments iptables pour limiter l'accès

L'exemple suivant utilise des éléments Linux iptables et le module owner associé pour empêcher le serveur web Apache (en fonction de son ID utilisateur d'installation par défaut apache) d'accéder à l'adresse 169.254.169.254. Il utilise une règle deny pour rejeter toutes les demandes de métadonnées d'instance (IMDSv1 ou IMDSv2) de tout processus s'exécutant au nom de cet utilisateur.

$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT

Vous pouvez aussi envisager d'autoriser uniquement l'accès à des utilisateurs ou des groupes particuliers à l'aide de règles d'autorisation (allow). Les règles allow peuvent être plus faciles à gérer du point de vue de la sécurité, car elles nécessitent que vous déterminiez quels sont les logiciels ayant besoin d'accéder aux métadonnées d'instance. Si vous utilisez des règles allow, vous risquez moins d'autoriser accidentellement un logiciel à accéder au service des métadonnées en cas de modification ultérieure des logiciels ou de la configuration sur une instance. Vous pouvez également combiner une utilisation de groupes avec des règles allow, afin de pouvoir ajouter et supprimer des utilisateurs dans un groupe autorisé sans avoir à modifier la règle du pare-feu.

L'exemple suivant empêche tous les processus d'accéder au service des métadonnées d'instance, à l'exception des processus qui s'exécutent dans le compte utilisateur trustworthy-user.

$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner trustworthy-user --jump REJECT
Note
  • Pour utiliser des règles de pare-feu locales, vous devez adapter les commandes de l'exemple précédent à vos besoins.

  • Par défaut, les règles iptables ne sont pas persistantes après un redémarrage du système. Elles peuvent être rendues persistantes en utilisant des fonctionnalités du système d'exploitation qui ne sont pas décrites ici.

  • Le module iptables owner correspond uniquement à l'appartenance au groupe si le groupe est le groupe principal d'un utilisateur local donné. Les autres groupes n'ont pas de correspondance.

Utilisation de PF ou de IPFW pour limiter l'accès

Si vous utilisez FreeBSD ou OpenBSD, vous pouvez également envisager d'utiliser PF ou IPFW. Les exemples suivants permettent de limiter l'accès au service des métadonnées d'instance à l'utilisateur racine.

PF

$ block out inet proto tcp from any to 169.254.169.254
$ pass out inet proto tcp from any to 169.254.169.254 user root

IPFW

$ allow tcp from any to 169.254.169.254 uid root
$ deny tcp from any to 169.254.169.254
Note

L'ordre des commandes PF et IPFW a de l'importance. PF prend par défaut la valeur de la dernière règle correspondante et IPFW prend par défaut la valeur de la première règle correspondante.