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.
# Versions IMDS sur un Snowball Edge
Vous pouvez accéder aux métadonnées d'une instance en cours d'exécution à l'aide d'IMDS version 2 ou IMDS version 1 :
+ Instance Metadata Service version 2 (IMDSv2), une méthode orientée session
+ Service de métadonnées d'instance version 1 (IMDSv1), une méthode de demande-réponse
Selon la version de votre logiciel Snow, vous pouvez utiliser IMDSv1 IMDSv2, ou les deux. Cela dépend également du type d'AMI exécuté dans l'instance EC2 compatible. Certains AMIs, tels que ceux exécutant Ubuntu 20.04, nécessitent IMDSv2. Le service de métadonnées d'instance fait la distinction entre les IMDSv2 demandes IMDSv1 et en fonction de la présence d'`GET`en-têtes `PUT` ou d'en-têtes. IMDSv2utilise ces deux en-têtes. IMDSv1 utilise uniquement l'`GET`en-tête.
AWS encourage l'utilisation de IMDSv2 plutôt que IMDSv1 parce qu'elle IMDSv2 inclut une sécurité accrue. Pour plus d'informations, voir Renforcer [la défense contre les pare-feux ouverts, les proxys inverses et les vulnérabilités SSRF grâce à des améliorations apportées au service de métadonnées d' EC2 instance](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).
## IMDSv2 sur un Snowball Edge
Lorsque vous demandez IMDSv2 des métadonnées d'instance, la demande doit respecter les règles suivantes :
1. Utilisez une demande `PUT` pour lancer une session sur le service des métadonnées d’instance. La `PUT` demande renvoie un jeton de session qui doit être inclus dans les `GET` demandes suivantes adressées au service de métadonnées d'instance. Le jeton de session qui définit la durée de la session. La durée de la session peut être d'un minimum d'une seconde et d'un maximum de six heures. Pendant cette durée, vous pouvez utiliser le même jeton de session pour les demandes suivantes. Une fois cette durée expirée, vous devez créer un nouveau jeton de session pour les demandes futures. Le jeton est requis pour accéder aux métadonnées à l'aide de IMDSv2.
1. Incluez le jeton dans toutes les demandes `GET` envoyées au service des métadonnées d'instance.
1. Le jeton est une clé spécifique à l'instance. Le jeton n'est pas valide sur les autres instances EC2 compatibles et sera rejeté si vous tentez de l'utiliser en dehors de l'instance sur laquelle il a été généré.
1. La demande `PUT` doit inclure un en-tête spécifiant la durée time-to-live (TTL) du jeton, en secondes, jusqu’à six heures au maximum (21 600 secondes). Le jeton représente une session logique. La durée de vie (TTL) définit la durée de validité du jeton et, par conséquent, la durée de la session.
1. Une fois qu'un jeton est arrivé à expiration, pour pouvoir continuer à accéder aux métadonnées de l'instance, vous devez créer une nouvelle session en utilisant une autre requête `PUT`.
1. Vous pouvez choisir de réutiliser un jeton ou d'en créer un nouveau pour chaque demande. Pour un faible nombre de demandes, il peut être plus facile de générer et d'utiliser immédiatement un jeton chaque fois que vous avez besoin d'accéder au service des métadonnées d'instance. Cependant, pour une plus grande productivité, vous pouvez spécifier une durée plus longue pour le jeton et le réutiliser plutôt que de devoir écrire une demande `PUT` chaque fois que vous avez besoin de demander des métadonnées d’instance. Il n’existe pas de limite pratique au nombre de jetons simultanés, chacun représentant sa propre session.
Le HTTP `GET` et `HEAD` les méthodes sont autorisés dans les demandes de métadonnées d' IMDSv2 instance. `PUT`les demandes sont rejetées si elles contiennent un `X-Forwarded-For` en-tête.
Par défaut, la limite de sauts de réponse (durée de vie) de la réponse aux `PUT` demandes est de 1 au niveau du protocole IP. IMDS for Snow ne permet pas de modifier la limite de sauts des `PUT` réponses.
L'exemple suivant utilise un script shell Linux IMDSv2 pour récupérer les éléments de métadonnées de l'instance de niveau supérieur. Cet exemple :
1. Crée un jeton de session d'une durée de six heures (21 600 secondes) à l'aide de la `PUT` demande.
1. Stocke l'en-tête du jeton de session dans une variable nommée`TOKEN`.
1. Demande les éléments de métadonnées de niveau supérieur à l'aide du jeton.
Utilisez deux commandes pour générer le jeton EC2 compatible. Vous pouvez exécuter les commandes séparément ou en tant que commande unique.
Tout d’abord, générez un jeton à l’aide de la commande suivante.
**Note**
`X-aws-ec2-metadata-token-ttl-seconds`est un en-tête obligatoire. Si cet en-tête n'est pas inclus, vous recevrez un code d'erreur **400 - Paramètres manquants ou non valides**.
```
[ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
```
Utilisez ensuite le jeton pour générer des éléments de métadonnées de haut niveau à l'aide de la commande suivante.
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```
**Note**
En cas d'erreur lors de la création du jeton, un message d'erreur est stocké dans la variable au lieu d'un jeton valide et la commande ne fonctionnera pas.
Vous pouvez stocker le jeton et combiner les commandes. L'exemple suivant combine les deux commandes ci-dessus et stocke l'en-tête du jeton de session dans une variable nommée`TOKEN`.
**Example de commandes combinées**
```
[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/
```
Une fois que vous avez créé un jeton, vous pouvez le réutiliser jusqu’à son expiration. L'exemple de commande suivant obtient l'ID de l'AMI utilisée pour lancer l'instance et le stocke dans le fichier `$TOKEN` créé dans l'exemple précédent.
**Example de la réutilisation d'un jeton**
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id
```
## IMDSv1 sur un Snowball Edge
IMDSv1 utilise le modèle de demande-réponse. Pour demander des métadonnées d'instance, vous devez envoyer une `GET` demande au service de métadonnées d'instance.
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/
```
Les métadonnées de votre instance sont disponibles depuis votre instance en cours d'exécution. Vous n'avez donc pas besoin d'utiliser la EC2 console Amazon ou le AWS CLI pour y accéder. 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 la section [Métadonnées d'instance et données utilisateur prises en charge](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html) dans ce guide.
Pour afficher toutes les catégories de métadonnées d'instance depuis une instance en cours d'exécution, utilisez l' IPv4 URI suivant :
```
http://169.254.169.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](https://en.wikipedia.org/wiki/Link-local_address) sur Wikipedia.
Toutes les métadonnées d’instance sont retournées sous forme de texte (type de contenu HTTP `text/plain`).
Une demande pour une ressource de métadonnées spécifique renvoie la valeur appropriée, ou un code d'erreur HTTP **404 - Not Found**, si la ressource n'est pas disponible.
Une demande de ressource de métadonnées générales (lorsque l'URI se termine par un `/` caractère) renvoie une liste des ressources disponibles, ou un code d'erreur HTTP **404 - Not Found** s'il n'existe aucune ressource de ce type. Les éléments de la liste se trouvent sur des lignes séparées, terminées par des flux de lignes (code de caractères ASCII 10).
Pour les requêtes effectuées via IMDSv1, les codes d'erreur HTTP suivants peuvent être renvoyés :
+ **400 ‐ Paramètres manquants ou non valides** — La `PUT` demande n'est pas valide.
+ **401 ‐ Non autorisé** — La `GET` demande utilise un jeton non valide. Il est recommandé dans ce cas de générer un nouveau jeton.
+ **403 ‐ Interdit** — La demande n'est pas autorisée ou le service de métadonnées de l'instance est désactivé.