Une VM clonée depuis une image déjà provisionnée par cloud-init démarre parfois avec le même nom d’hôte, les mêmes clés hôte SSH, et la même configuration réseau que la machine source, alors que cloud-init était censé régénérer tout cela au premier démarrage. Ce n’est pas un bug de cloud-init : le clonage a préservé un état que cloud-init interprète comme la preuve qu’il a déjà fait son travail sur cette instance précise.

Ce que cloud-init fait au premier démarrage

cloud-init exécute un ensemble de modules (configuration réseau, génération des clés hôte SSH, exécution des scripts user-data) une seule fois par instance, puis enregistre cet état d’exécution dans /var/lib/cloud/instances/<instance-id>/, un répertoire keyé sur l’identifiant d’instance fourni par le datasource cloud (métadonnées AWS, GCP, ou autre).

# L'ID d'instance qui détermine si cloud-init
# considère qu'il a déjà tourné sur cette machine
cat /var/lib/cloud/data/instance-id

Pourquoi un clone hérite de cet état

Cloner une VM (via un snapshot, une image disque, ou un template d’hyperviseur) copie l’intégralité du disque, /var/lib/cloud/ inclus. Si l’ID d’instance exposé par le nouvel environnement cloud reste identique (un scénario fréquent selon la plateforme de virtualisation utilisée), cloud-init retrouve un répertoire d’état déjà marqué comme traité pour cet ID, et saute purement et simplement sa phase d’initialisation au démarrage.

Le risque concret : des clés hôte SSH dupliquées

Le symptôme le plus sérieux de ce piège est la duplication des clés hôte SSH (/etc/ssh/ssh_host_*_key) entre la machine source et son clone : deux machines partageant la même clé privée SSH host affaiblissent la garantie d’authenticité que ces clés sont censées fournir, un problème de sécurité bien plus grave qu’un simple nom d’hôte incorrect.

Le correctif : nettoyer l’état avant de figer l’image

cloud-init clean supprime l’état d’exécution enregistré, forçant une réexécution complète au prochain démarrage, l’étape à effectuer sur l’image source avant de la figer comme modèle de clonage, jamais après coup sur un clone déjà démarré.

# À exécuter sur l'image source AVANT de la figer
# comme template/golden image pour clonage futur
cloud-init clean --logs

# Force également la régénération des clés hôte SSH
# au prochain démarrage, pas seulement la config réseau
rm -f /etc/ssh/ssh_host_*_key*

À retenir

cloud-init ne s’exécute qu’une seule fois par instance, un état tracké dans /var/lib/cloud/instances/<instance-id>/ et keyé sur l’identifiant d’instance du datasource cloud. Cloner une VM copie cet état avec le reste du disque : si l’ID d’instance ne change pas dans le nouvel environnement, cloud-init saute son initialisation, avec pour conséquence la plus grave une duplication des clés hôte SSH entre machines. cloud-init clean doit être exécuté sur l’image source avant de la figer comme modèle de clonage, jamais après coup sur un clone déjà démarré avec un état déjà corrompu — le même principe que la préparation d’un démarrage déjà vu avec les montages fstab : un état d’initialisation supposé résolu une fois pour toutes peut se révéler faux dans un environnement différent de celui où il a été validé.