Passer à l’utilisation de Service des métadonnées d’instance Version 2

Lorsque vous effectuez la migration vers IMDSv2, nous vous recommandons d’utiliser les outils et le chemin de transition suivants.

Outils facilitant la migration vers IMDSv2

Si votre logiciel utilise IMDSv1, utilisez les outils suivants pour faciliter sa reconfiguration vers IMDSv2.

AWS logiciel

Les dernières versions du AWS SDK AWS CLI et du kit de développement prennent en charge l'IMDSv2. Pour utiliser IMDSv2, veillez à ce que vos instances EC2 possèdent les dernières versions de la CLI et des kits SDK. Pour plus d’informations sur la mise à jour de la CLI, consultez Installation, mise à jour et désinstallation d’ AWS CLI dans le Guide de l’utilisateur AWS Command Line Interface .

Tous les packages logiciels Amazon Linux 2 et Amazon Linux 2023 sont compatibles avec IMDSv2. Dans Amazon Linux 2023, IMDSv1 est désactivé par défaut.

Pour connaître les versions minimales du AWS SDK compatibles avec IMDSv2, consultez. Utilisation d’un kit SDK AWS pris en charge

Analyseur de packages IMDS

L’analyseur de packages IMDS est un outil open source qui identifie et journalise les appels IMDSv1 depuis la phase de démarrage de votre instance. Cela peut aider à identifier le logiciel qui effectue des appels IMDSv1 sur les instances EC2, ce qui vous permet de déterminer exactement ce que vous devez mettre à jour pour que vos instances soient prêtes à utiliser IMDSv2 uniquement. Vous pouvez exécuter l’analyseur de packages IMDS à partir d’une ligne de commande ou l’installer en tant que service. Pour plus d'informations, consultez la section IMDS Packet Analyzer activé. GitHub

CloudWatch

IMDSv2 utilise des sessions basées sur un jeton, mais pas IMDSv1. La MetadataNoToken CloudWatch métrique suit le nombre d'appels au service de métadonnées d'instance (IMDS) qui utilisent IMDSv1. En suivant cette métrique jusqu’à zéro, vous pouvez déterminer si la totalité de votre logiciel a été mis à niveau vers IMDSv2 et le moment auquel cela se produit.

Après avoir désactivé IMDSv1, vous pouvez utiliser la MetadataNoTokenRejected CloudWatch métrique pour suivre le nombre de tentatives et de refus d'un appel IMDSv1. En suivant cette métrique, vous pouvez déterminer si votre logiciel doit être mis à jour pour utiliser IMDSv2.

Pour plus d’informations, consultez Métriques des instances.

Mises à jour des API et des CLI EC2

Pour les nouvelles instances, vous pouvez utiliser l'RunInstancesAPI pour lancer de nouvelles instances qui nécessitent l'utilisation d'IMDSv2. Pour plus d’informations, consultez Configurer les options de métadonnées d’instance pour les nouvelles instances.

Pour les instances existantes, vous pouvez utiliser l'ModifyInstanceMetadataOptionsAPI pour exiger l'utilisation d'IMDSv2. Pour plus d’informations, consultez Configurer les options de métadonnées d’instance pour les instances existantes.

Pour exiger l’utilisation de IMDSv2 sur toutes les nouvelles instances lancées par des groupes Auto Scaling, ces derniers peuvent utiliser un modèle de lancement ou une configuration de lancement. Lorsque vous créez un modèle de lancement ou une configuration de lancement, vous devez configurer les paramètres MetadataOptions pour exiger l’utilisation de IMDSv2. Le groupe Auto Scaling lance de nouvelles instances à l’aide du nouveau modèle de lancement ou de la nouvelle configuration de lancement, mais les instances existantes ne sont pas affectées. Pour les instances existantes d'un groupe Auto Scaling, vous pouvez utiliser l'ModifyInstanceMetadataOptionsAPI pour exiger l'utilisation d'IMDSv2 sur les instances existantes, ou mettre fin aux instances et le groupe Auto Scaling lancera de nouvelles instances de remplacement avec les paramètres des options de métadonnées d'instance définis dans le nouveau modèle de lancement ou dans la nouvelle configuration de lancement.

Utilisation d’une AMI qui configure IMDSv2 par défaut

Lorsque vous lancez une instance, vous pouvez la configurer automatiquement pour utiliser IMDSv2 par défaut (le paramètre HttpTokens est défini sur required) en la lançant avec une AMI configurée avec le paramètre ImdsSupport défini sur v2.0. Vous pouvez définir le paramètre ImdsSupport sur v2.0 lorsque vous enregistrez l’AMI à l’aide de la commande CLI register-image, ou vous pouvez modifier une AMI existante à l’aide de la commande CLI modify-image-attribute. Pour plus d’informations, consultez Configurer l’AMI.

Politiques IAM et politiques de contrôle des services

Vous pouvez utiliser une stratégie IAM ou une politique de contrôle des AWS Organizations services (SCP) pour contrôler les utilisateurs comme suit :

• Impossible de lancer une instance à l'aide de l'RunInstancesAPI à moins que l'instance ne soit configurée pour utiliser IMDSv2.

• Impossible de modifier une instance en cours d'exécution à l'aide de l'ModifyInstanceMetadataOptionsAPI pour réactiver IMDSv1.

La politique IAM ou la politique de contrôle des services doit contenir les clés de condition IAM suivantes :

• ec2:MetadataHttpEndpoint

• ec2:MetadataHttpPutResponseHopLimit

• ec2:MetadataHttpTokens

Si un paramètre de l’appel d’API ou de CLI ne correspond pas à l’état spécifié dans la politique contenant la clé de condition, l’appel de l’API ou de la CLI échoue avec la réponse UnauthorizedOperation.

Vous pouvez en outre choisir une couche de protection supplémentaire afin d’imposer le passage de IMDSv1 à IMDSv2. Au niveau de la couche de gestion des accès, en ce qui concerne les API appelées via les informations d'identification du rôle EC2, vous pouvez utiliser une nouvelle clé de condition dans les politiques IAM ou les politiques de contrôle des AWS Organizations services (SCP). Si vous utilisez la clé de condition ec2:RoleDelivery avec la valeur 2.0 dans vos politiques IAM, les appels d’API effectués avec des informations d’identification de rôle EC2 obtenues à partir de IMDSv1 recevront une réponse UnauthorizedOperation. Vous pouvez aboutir au même résultat plus généralement avec cette condition requise par une SCP. Cela permet de s’assurer que les informations d’identification fournies via IMDSv1 ne peuvent pas être utilisées pour appeler des API, car tout appel d’API ne respectant pas la condition spécifiée recevra une erreur UnauthorizedOperation.

Par exemple les stratégies IAM, consultez Utiliser des métadonnées d’instance. Pour plus d’informations sur les politiques de contrôle des services, consultez Politiques de contrôle des services dans le Guide de l’utilisateur AWS Organizations .

Chemin recommandé pour demander l’accès à IMDSv2

Nous vous recommandons, tout en utilisant les outils mentionnés précédemment, de suivre ce chemin pour la migration vers IMDSv2.

Etape 1 : Au départ

Mettez à jour les kit SDK, les CLI et vos logiciels utilisant des informations d’identification de rôle sur leurs instances EC2 vers des versions compatibles avec IMDSv2. Pour plus d’informations sur la mise à jour de la CLI, consultez Mise à niveau vers la dernière version d’ AWS CLI dans le Guide de l’utilisateur AWS Command Line Interface .

Modifiez ensuite les logiciels accédant directement aux métadonnées de l’instance (en d’autres termes, n’utilisant pas un kit SDK) à l’aide des demandes IMDSv2. Vous pouvez utiliser l’analyseur de packages IMDS pour identifier le logiciel que vous devez modifier pour utiliser les requêtes IMDSv2.

Étape 2 : suivre la progression de votre transition

Suivez la progression de votre transition à l'aide de la CloudWatch métriqueMetadataNoToken. Cette métrique indique le nombre d’appels IMDSv1 à l’IMDS sur vos instances. Pour plus d’informations, consultez Métriques des instances.

Étape 3 : quand il n’y a aucune utilisation de IMDSv1

Lorsque la CloudWatch métrique MetadataNoToken enregistre une utilisation nulle d'IMDSv1, vos instances sont prêtes à passer entièrement à l'utilisation d'IMDSv2. A ce stade, voici ce que vous pouvez faire :

• Compte par défaut

  Vous pouvez configurer IMDSv2 pour qu'il soit obligatoire comme compte par défaut. Lorsqu'une instance est lancée, la configuration de l'instance est automatiquement définie sur la valeur par défaut du compte.

  Pour définir le compte par défaut, procédez comme suit :

  • Console Amazon EC2 : sur le tableau de bord EC2, sous Attributs du compte, Protection et sécurité des données, pour les valeurs par défaut de l'IMDS, définissez le service de métadonnées de l'instance sur Activé et la version des métadonnées sur V2 uniquement (jeton requis). Pour plus d’informations, consultez Définissez IMDSv2 comme valeur par défaut pour le compte.

  • AWS CLI: utilisez la commande CLI modify-instance-metadata-defaults et spécifiez et. --http-tokens required --http-put-response-hop-limit 2

• Nouvelles instances

  Lors du lancement d’une nouvelle instance, vous pouvez effectuer les opérations suivantes :

  • Console Amazon EC2 : dans l’assistant de lancement d’instance, définissez Metadata accessible (Métadonnées accessibles) sur Enabled (Activé) et Metadata version (Version des métadonnées) sur V2 only (token required) (V2 uniquement [jeton obligatoire]). Pour plus d’informations, consultez Configurer l’instance au lancement.

  • AWS CLI: utilisez la commande run-instances CLI et spécifiez que IMDSv2 est requis.

• Instances existantes

  Pour les instances existantes, vous pouvez exécuter les opérations suivantes :

  • Console Amazon EC2 : sur la page Instances, sélectionnez votre instance, choisissez Actions, Paramètres de l’instance, Modifier les options des métadonnées d’instance et, pour IMDSv2, choisissez Requis. Pour plus d’informations, consultez Exigence d’utilisation d’IMDSv2.

  • AWS CLI : utilisez la commande CLI modify-instance-metadata-options pour spécifier que seul l’IMDSv2 doit être utilisé.

  Vous pouvez modifier les options des métadonnées d’instance sur les instances en cours d’exécution, et vous n’avez pas besoin de redémarrer les instances après avoir modifié ces options.

Étape 4 : vérifiez que vos instances ont bien été migrées vers IMDSv2

Vous pouvez vérifier si des instances ne sont pas encore configurées pour l’utilisation d’IMDSv2. En d’autres termes, si IMDSv2 est toujours configuré comme optional. Si des instances sont toujours configurées sur optional, vous pouvez modifier les options des métadonnées d’instance pour rendre IMDSv2 required en répétant l’étape 3 précédente.

Pour filtrer vos instances :

• Console Amazon EC2 : sur la page Instances, filtrez vos instances à l’aide du filtre IMDSv2 = facultatif. Pour plus d’informations sur le filtrage, veuillez consulter la rubrique Filtrer des ressources à l’aide de la console. Vous pouvez également voir si IMDSv2 est requis ou facultatif pour chaque instance : dans la fenêtre Préférences, activez IMDSv2 pour ajouter la colonne IMDSv2 au tableau Instances.

• AWS CLI : utilisez la commande CLI describe-instances et filtrez par metadata-options.http-tokens = optional, comme suit :

  aws ec2 describe-instances --filters "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].[InstanceId]" --output text

Étape 5 : lorsque toutes vos instances ont été migrées sur IMDSv2

Les clés de condition ec2:MetadataHttpTokensec2:MetadataHttpPutResponseHopLimit,, et ec2:MetadataHttpEndpoint IAM peuvent être utilisées pour contrôler l'utilisation des ModifyInstanceMetadataOptionsAPI RunInstanceset des CLI correspondantes. Si une stratégie est créée et qu’un paramètre de l’appel d’API ne correspond pas à l’état spécifié dans la stratégie à l’aide de la clé de condition, l’appel de l’API ou de l’interface de ligne commande échoue avec la réponse UnauthorizedOperation. Par exemple les stratégies IAM, consultez Utiliser des métadonnées d’instance.

En outre, après avoir désactivé IMDSv1, vous pouvez utiliser la MetadataNoTokenRejected CloudWatch métrique pour suivre le nombre de fois qu'un appel IMDSv1 a été tenté et rejeté. Si, après avoir désactivé IMDSv1, vous avez un logiciel qui ne fonctionne pas correctement et que la MetadataNoTokenRejected métrique enregistre les appels IMDSv1, il est probable que ce logiciel doive être mis à jour pour utiliser IMDSv2.