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é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 Adresses lien-local dans ce guide de l’utilisateur et l’article Adresse lien-local
Note
Les exemples de cette section utilisent l’adresse IPv4 de l’IMDS : 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 de l’IMDS est compatible avec les commandes IMDSv2. L'adresse IPv6 n'est accessible que sur les instances créées sur le système AWS Nitro.
Le format de la commande est différent selon que vous utilisez IMDSv1 ou IMDSv2. Par défaut, vous pouvez utiliser les deux versions de l’IMDS. Pour imposer l’utilisation de IMDSv2, consultez Utiliser IMDSv2.
Vous pouvez utiliser un outil tel que cURL, comme illustré dans l’exemple suivant.
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 :
-
Dans un environnement de conteneurs, nous vous recommandons de fixer la limite de saut à 2.
Les AWS SDK 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, en particulier dans un environnement de conteneurs. 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/tokenlors 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. -
Si IMDSv2 est requis, IMDSv1 ne fonctionne pas.
Vous pouvez vérifier si IMDSv2 est requis pour une instance en procédant comme suit : sélectionnez l’instance pour en afficher les détails, puis vérifiez la valeur de IMDSv2. La valeur est soit Obligatoire (seul IMDSv2 peut être utilisé) ou Facultatif (IMDSv2 et IMDSv1 peuvent être utilisés).
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 demandePUTn’est pas valide. -
401 - Unauthorized– La demandeGETutilise 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 l’IMDS 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.
Exemples
- Obtenir les versions disponibles des métadonnées d’instance
- Obtenir les éléments de métadonnées de niveau supérieur
- Obtenir la liste des clés publiques disponibles
- Montrer les formats pour lesquels une clé publique 0 est disponible
- Obtenir la clé publique 0 (au format clé OpenSSH)
- Obtenir l’ID de sous-réseau d’une instance
- Obtenir les identifications d’une instance
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
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.
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.
Obtenir la liste des clés publiques disponibles
Cet exemple permet d’obtenir la liste des clés publiques disponibles.
Montrer les formats pour lesquels une clé publique 0 est disponible
Cet exemple montre les formats pour lesquels une clé publique 0 est disponible.
Obtenir la clé publique 0 (au format clé OpenSSH)
Cet exemple permet d’obtenir la clé publique 0 (au format clé OpenSSH).
Obtenir l’ID de sous-réseau d’une instance
Cet exemple permet d’obtenir l’ID de sous-réseau pour une instance.
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.
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.
Limitation des demandes
Nous limitons les requêtes envoyées par chaque instance à l’IMDS et appliquons des limites au nombre de connexions simultanées possible depuis une instance vers l’IMDS.
Si vous utilisez l'IMDS pour récupérer des informations d'identification de AWS sécurité, évitez de demander des informations d'identification lors de chaque transaction ou simultanément à partir d'un grand nombre de threads ou de processus, car cela pourrait entraîner un ralentissement. Nous vous conseillons plutôt de placer les informations d’identification en cache jusqu’à ce que leur date d’expiration approche. Pour plus d’informations sur le rôle IAM et les informations d’identification de sécurité associées au rôle, consultez Extraire les informations d’identification de sécurité à partir des métadonnées d’instance.
Si vous rencontrez des limitations alors que vous tentez d’accéder à l’IMDS, renvoyez une requête avec une stratégie de backoff exponentiel.
Limiter l’accès à l’IMDS
Vous pouvez envisager d’utiliser des règles de pare-feu locales pour désactiver l’accès à l’IMDS à partir de certains processus, voire tous.
Note
Pour les instances basées sur le système AWS Nitro, l'IMDS est accessible depuis votre propre réseau lorsqu'un appareil réseau au sein de votre VPC, tel qu'un routeur virtuel, transmet des paquets à l'adresse IMDS et que le contrôle source/destination par défaut sur l'instance est désactivé. Pour empêcher une source extérieure à votre VPC d'atteindre l'IMDS, nous vous recommandons de modifier la configuration de l'appliance réseau afin de supprimer les paquets contenant l'adresse IPv4 de destination de l'IMDS 169.254.169.254 et, si vous avez activé le point de terminaison IPv6, l'adresse IPv6 de l'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 à l’IMDS, à 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-ownertrustworthy-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
ownercorrespond 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 à l’IMDS à l’utilisateur root uniquement.
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.
