Cloud-init Proxmox : templates, snippets et secrets en 2026

Cloud-init Proxmox désigne l'intégration native, dans Proxmox VE, de l'outil open source cloud-init, qui configure une machine virtuelle dès son premier démarrage : nom d'hôte, réseau, compte d'exploitation, clés SSH, paquets. L'hyperviseur génère un petit lecteur virtuel au format NoCloud, l'invité le lit, applique la configuration et devient exploitable quelques instants après avoir été cloné depuis un template. Cette mécanique accélère les déploiements, mais elle transporte aussi des données sensibles : mots de passe hachés, fichiers user-data, jetons d'enrôlement. En 2026, avec Proxmox VE 9.2 et cloud-init 26.2, la vraie question n'est plus de savoir s'il faut automatiser, mais comment le faire sans semer de secrets. Ce guide, complémentaire du guide complet Proxmox VE, détaille la préparation des templates, l'usage des snippets cicustom et les contrôles de sécurité à appliquer.

Cloud-init dans Proxmox VE : définition et fonctionnement

Côté hyperviseur, Proxmox VE ne pousse rien par le réseau. D'après la documentation officielle Cloud-Init Support de Proxmox VE, l'hyperviseur génère une image ISO contenant les données de configuration et l'attache à la VM par un lecteur CD-ROM virtuel, généralement déclaré sur ide2. Au premier démarrage, cloud-init détecte ce lecteur, lit son contenu et applique les réglages demandés.

Le format de ce lecteur dépend du paramètre citype. Proxmox VE utilise par défaut le format NoCloud pour les systèmes Linux et ConfigDrive v2 pour Windows, un troisième format, OpenNebula, restant disponible. Le choix découle du type de système déclaré dans la VM, le paramètre ostype, mais il peut être forcé en ligne de commande lorsqu'une image particulière l'exige.

Le lecteur NoCloud transporte jusqu'à quatre documents distincts. Le user-data décrit les utilisateurs, les clés, les paquets et les commandes ; le network-config décrit les interfaces ; le meta-data contient au minimum l'identifiant d'instance ; le vendor-data fournit des valeurs par défaut que le user-data peut surcharger. La documentation NoCloud de cloud-init 26.2 précise que cet identifiant sert à détecter un premier démarrage.

Cette notion d'instance-id est centrale. Les modules cloud-init dits « par instance », comme la création des utilisateurs ou la génération des clés d'hôte SSH, ne s'exécutent qu'une seule fois pour un identifiant donné. Si l'identifiant change, cloud-init considère qu'il démarre une nouvelle machine et rejoue ces étapes. Ce comportement a des conséquences directes sur les clones, les mises à jour de configuration et la stabilité des empreintes SSH.

Du template au premier démarrage : l'architecture en cinq étapes

Le cycle de vie d'une VM cloud-init sous Proxmox VE suit une chaîne simple, du téléchargement de l'image jusqu'au serveur configuré. Chaque maillon possède ses propres contrôles de sécurité, et une faiblesse en amont se propage à toutes les machines clonées en aval. Le schéma ci-dessous résume cette chaîne et les points de contrôle associés à chaque étape.

1. Image source : téléchargement d'une image cloud officielle au format qcow2 et vérification de son empreinte.
2. VM modèle : création de la VM, import du disque, ajout du lecteur cloud-init et de la console série.
3. Template : conversion en modèle figé, qui ne démarre plus et sert uniquement de base aux clones.
4. Clone : clone lié ou complet, puis paramétrage du réseau, des clés SSH et des éventuels fichiers personnalisés.
5. Premier démarrage : Proxmox VE génère l'ISO, que cloud-init applique au fil de ses étapes Local, Network, Config et Final.

Les étapes de démarrage de cloud-init s'enchaînent dans un ordre précis. L'étape locale identifie la source de données et prépare la configuration réseau, l'étape réseau récupère et traite le user-data, puis les étapes de configuration et finale exécutent les modules, dont l'installation des paquets et les commandes personnalisées. Un échec à l'une de ces étapes se lit dans le journal /var/log/cloud-init.log de l'invité.

Le modèle « template plus clone lié » est rapide parce que le clone partage les blocs du disque de base et n'écrit que ses différences. Ce gain a une contrepartie : tous les clones héritent du contenu du template, y compris d'éventuels fichiers oubliés, historiques de commandes ou identifiants temporaires. Le soin apporté au template conditionne donc la sécurité du parc entier. Le guide d'optimisation Proxmox VE détaille les compromis de performance entre clone lié et clone complet.

Préparer un template cloud-init Proxmox fiable

Choisir et vérifier l'image source

La documentation Proxmox VE recommande de préparer soi-même ses images plutôt que d'adopter sans examen une image prête à l'emploi, afin de savoir exactement ce qui est installé. En pratique, la plupart des équipes partent des images cloud officielles des distributions, puis les durcissent. Ce compromis reste acceptable à condition de contrôler l'origine et l'intégrité de chaque fichier téléchargé.

Pour Debian 13, la variante adaptée aux VM est genericcloud, identique à generic avec un jeu réduit de pilotes matériels. Attention à un piège de nommage : la variante Debian appelée « nocloud » n'exécute pas cloud-init et démarre directement sur une invite root ; elle n'a rien à voir avec la source de données NoCloud. Debian recommande de télécharger image et fichier SHA512SUMS en HTTPS depuis ses serveurs officiels, tandis qu'Ubuntu publie des empreintes signées par GPG.

Créer la VM modèle et le lecteur cloud-init

La séquence suivante crée une VM modèle à partir de l'image Debian 13, importe le disque sur un stockage LVM-thin, ajoute le lecteur cloud-init et la console série qu'attendent de nombreuses images cloud. Les identifiants de VM, noms de stockage, chemins et noms de fichiers sont des exemples à adapter à votre environnement.

wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2
wget https://cloud.debian.org/images/cloud/trixie/latest/SHA512SUMS
sha512sum --ignore-missing -c SHA512SUMS

qm create 9000 --name tpl-debian13 --ostype l26 --memory 2048 --cores 2 \
  --cpu x86-64-v2-AES --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --agent enabled=1
qm set 9000 --scsi0 local-lvm:0,import-from=/root/debian-13-genericcloud-amd64.qcow2
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0 --serial0 socket --vga serial0
qm set 9000 --ciuser exploit --sshkeys /root/cles/admins-ed25519.pub --ipconfig0 ip=dhcp
qm template 9000

Le contrôle sha512sum doit afficher « OK » pour l'image téléchargée ; tout autre résultat impose de supprimer le fichier. L'option import-from copie le disque cloud vers le stockage cible, et le réglage boot order=scsi0 évite que le firmware virtuel tente de démarrer sur le lecteur cloud-init. Pour le type de processeur et les options matérielles du modèle, le guide des paramètres avancés des VM Proxmox VE 9.1 aide à faire les bons choix.

Généraliser un template cloud-init avant sa conversion

Une image cloud qui n'a jamais démarré peut être convertie directement en template. Si vous démarrez la VM modèle pour la personnaliser, par exemple pour installer l'agent invité QEMU ou un agent de supervision, il faut la généraliser avant conversion. La commande cloud-init clean --logs --seed --machine-id efface l'état de cloud-init, ses journaux et son répertoire seed, puis réinitialise l'identifiant machine.

La référence des commandes cloud-init présente l'option --machine-id comme une bonne pratique lors du clonage d'une image de référence, pour que chaque clone génère un identifiant unique. Complétez ce nettoyage par la suppression de l'historique shell, des comptes temporaires et de tout fichier d'identifiants utilisé pendant la personnalisation, puis éteignez la VM avant d'exécuter qm template.

Retour terrain : Cas typique rencontré en mission — le template est construit à la main puis cloné pendant des mois : chaque nouvelle VM démarre avec un retard de correctifs que la mise à jour au premier démarrage ne rattrape que si elle est activée. Les équipes matures confient la construction à un pipeline : contrôle d'empreinte de l'image, nettoyage cloud-init, analyse de secrets, scan de vulnérabilités, puis démarrage d'un clone de test. Reconstruire le template à chaque cycle de correctifs devient alors une simple routine.

Paramètres natifs ou snippets cicustom : que choisir ?

Proxmox VE propose deux façons d'alimenter cloud-init. Les paramètres natifs de l'onglet Cloud-Init (utilisateur, mot de passe, clés SSH, adresses IP, DNS, mise à jour des paquets) génèrent automatiquement les documents user-data, network-config et meta-data. L'option cicustom remplace un ou plusieurs de ces documents par des fichiers YAML que vous rédigez vous-même, appelés snippets.

Le remplacement se fait document par document : un fichier user personnalisé se substitue à toute la partie user générée, tandis que le réseau reste produit automatiquement s'il n'est pas lui aussi personnalisé. Conséquence pratique, l'utilisateur, les clés et le mot de passe saisis dans l'interface ne sont plus transmis dès qu'un user-data personnalisé est déclaré. La commande qm cloudinit dump 9000 user exporte la configuration générée, base utile pour écrire la vôtre.

Les snippets exigent un stockage dont le type de contenu inclut snippets. Sur le stockage local par défaut, la commande pvesm set local --content iso,vztmpl,backup,snippets active ce type ; la liste remplaçant l'existante, reprenez-y les types déjà utilisés. Les fichiers se placent alors dans /var/lib/vz/snippets/. La référence se déclare ensuite avec qm set 201 --cicustom "user=local:snippets/base-debian13.yaml", en combinant au besoin les clés user, network, meta et vendor.

Un clone se paramètre en quelques commandes : qm clone 9000 201 --name app-01, puis qm set 201 --ipconfig0 ip=10.10.20.21/24,gw=10.10.20.1 et, si nécessaire, qm disk resize 201 scsi0 +18G. Les images cloud livrent un disque de quelques gigaoctets que le module growpart de cloud-init étend au démarrage. Le volume de disque, de mémoire et de processeur à attribuer suit la méthode décrite dans l'article sur le dimensionnement Proxmox.

Le paramètre ciupgrade, activé par défaut, déclenche une mise à jour des paquets après le premier démarrage. C'est un réglage favorable à la sécurité, puisque le clone ne reste pas figé au niveau de correctifs du template, mais il suppose un accès à un miroir de paquets et allonge la mise en service. Dans un réseau isolé, prévoyez un miroir interne plutôt que de désactiver la mise à jour.

Écrire un user-data cloud-init sûr pour vos VM Proxmox

Un cloud-config minimal et durci

Un bon user-data décrit l'état attendu sans transporter de secret. L'exemple ci-dessous crée un compte d'exploitation sans mot de passe utilisable, n'accepte que des clés SSH, désactive la connexion root et l'authentification par mot de passe, installe l'agent invité et configure la synchronisation horaire. La clé publique est volontairement tronquée et les noms de serveurs sont fictifs.

#cloud-config
users:
  - name: exploit
    groups: [sudo]
    shell: /bin/bash
    lock_passwd: true
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza...tronquee admin1@poste-admin
disable_root: true
ssh_pwauth: false
package_update: true
package_upgrade: true
packages:
  - qemu-guest-agent
  - chrony
ntp:
  enabled: true
  ntp_client: chrony
  servers: [ntp1.lab.local, ntp2.lab.local]
runcmd:
  - [systemctl, enable, --now, qemu-guest-agent]

Les modules utilisés sont standards : users crée le compte et dépose les clés, ssh_pwauth: false désactive l'authentification par mot de passe du serveur SSH, et le module ntp configure chrony vers vos serveurs internes. Une horloge juste conditionne la validité des journaux et des certificats ; l'article consacré au NTP sur Proxmox détaille l'architecture de temps côté hôtes.

La règle sudo sans mot de passe est un compromis fréquent pour un compte dépourvu de mot de passe ; restreignez-la selon votre politique d'élévation de privilèges, par exemple en imposant un bastion et la journalisation des commandes. Vérifiez aussi le nom d'hôte : la commande qm cloudinit dump <vmid> user montre qu'il figure dans la partie user générée, il disparaît donc si un snippet commun remplace ce document.

Valider le fichier avant tout déploiement

Une erreur de syntaxe YAML ne bloque pas toujours le démarrage : cloud-init se contente souvent d'un avertissement dans ses journaux et livre une VM sans clé SSH ni durcissement. La commande cloud-init schema -c base-debian13.yaml --annotate, lancée sur un poste ou une VM disposant de cloud-init, valide le fichier contre le schéma officiel et annote chaque erreur à la ligne concernée.

Après le premier démarrage d'une VM de test, cloud-init status --long indique si l'exécution s'est terminée correctement, avec des codes de sortie exploitables en intégration continue : 0 en cas de succès, 2 en cas d'erreurs récupérables et 1 en cas d'échec. Intégrez cette vérification au pipeline qui publie vos snippets, au même titre qu'une analyse automatique de secrets sur le dépôt.

Où se cachent les secrets d'un déploiement cloud-init ?

Un secret placé dans un user-data ne reste jamais à un seul endroit. Il est écrit sur l'hyperviseur, recopié dans le lecteur ISO, lu par l'invité, mis en cache sur son disque et parfois répété dans les journaux. Suivre ce trajet permet de comprendre pourquoi aucun secret durable ne doit figurer dans un user-data, qu'il s'agisse d'un mot de passe, d'une clé d'API ou d'une clé privée.

• Configuration de la VM : le fichier stocké sous /etc/pve contient le hachage du mot de passe, les clés publiques et les références cicustom ; le système de fichiers du cluster le réplique sur tous les nœuds.
• Stockage des snippets : les fichiers YAML résident dans un répertoire local ou sur un partage NFS ou CephFS, lisible par quiconque accède à ce partage.
• Volume cloud-init : l'ISO générée est un volume du stockage de la VM, présenté à l'invité comme un CD-ROM lisible par root et, selon les distributions, par les membres du groupe cdrom.
• Disque de l'invité : cloud-init conserve une copie du user-data dans /var/lib/cloud/instance/user-data.txt, et la sortie des commandes runcmd est consignée dans /var/log/cloud-init-output.log.
• Diagnostics et sauvegardes : l'archive produite par cloud-init collect-logs inclut le user-data, et les sauvegardes de VM embarquent leur configuration.
• Dépôts de code : les snippets versionnés dans Git y laissent un historique durable, même après la suppression d'un secret dans la dernière version.

Ces chiffres portent sur le code en général, mais les fichiers user-data en sont un cas typique : ce sont des fichiers de configuration, souvent copiés depuis un exemple, versionnés par commodité et partagés entre équipes. Le même rapport indique que les dépôts internes sont environ six fois plus susceptibles de contenir des secrets codés en dur que les dépôts publics, ce qui relativise le sentiment de sécurité d'un dépôt privé.

Remplacer les secrets cloud-init par un jeton d'amorçage

La bonne architecture consiste à ne transmettre par cloud-init qu'un élément d'amorçage de courte durée : un jeton d'enrôlement à usage unique pour l'outil de gestion de configuration, ou un identifiant de rôle dont le secret associé expire après quelques minutes dans un coffre-fort de secrets. L'agent ainsi enrôlé récupère ensuite les vrais secrets par un canal authentifié, et le jeton initial devient inutilisable.

Si un secret doit malgré tout transiter, réduisez sa fenêtre d'exposition : générez-le pour chaque VM, limitez ses droits, faites-le expirer rapidement et retirez-le du snippet après le premier démarrage. Surveillez aussi les commandes runcmd : un echo ou un script trop bavard peut recopier une valeur sensible dans le journal de sortie de cloud-init, qui reste sur le disque de l'invité.

Clés SSH et mots de passe : les règles à appliquer

La documentation Proxmox VE recommande explicitement l'authentification par clé SSH pour les VM provisionnées par cloud-init. Elle précise qu'un mot de passe reste possible mais moins sûr, car Proxmox VE doit en conserver une version chiffrée dans les données cloud-init. Par défaut, l'API hache le mot de passe saisi en clair avant de l'enregistrer dans la configuration de la VM.

Un hachage n'est pas une protection absolue. Quiconque récupère la configuration ou le contenu du lecteur cloud-init peut tenter une attaque hors ligne par dictionnaire, d'autant plus efficace que le mot de passe est court ou réutilisé. Selon le journal des versions Proxmox VE, la version 9.2 publiée le 21 mai 2026 exige désormais le privilège VM.Config.Cloudinit pour extraire ce mot de passe (avis PSA-2026-00017-1).

Bonnes pratiques pour les clés

• Une paire de clés par administrateur, de type Ed25519, protégée par une phrase de passe ou conservée sur un jeton matériel.
• Aucune clé partagée entre plusieurs personnes, ni copiée dans le disque du template lui-même.
• Un fichier de clés publiques versionné et sans lignes de commentaire, que Proxmox VE refuse lors du chargement.
• Un compte d'exploitation dédié, jamais root, accompagné de disable_root et de ssh_pwauth: false.
• Une révocation pilotée par l'outil de gestion de configuration, car retirer une clé de l'onglet Cloud-Init ne garantit pas sa suppression du fichier authorized_keys de l'invité.

Ces règles rejoignent les recommandations de l'ANSSI sur OpenSSH, qui demandent de maîtriser finement la configuration du service, d'en durcir l'installation et d'encadrer strictement son exploitation quotidienne. Le guide Usage sécurisé d'(Open)SSH de l'ANSSI reste la référence française pour le choix des algorithmes, la protection des clés privées et l'imputabilité des accès.

Le mot de passe garde une utilité limitée : l'accès de secours par la console noVNC ou série lorsque le réseau de la VM ne répond plus. Si vous en définissez un, générez-le aléatoirement pour chaque VM, conservez-le dans un coffre-fort et changez-le après usage. La commande qm guest passwd, qui passe par l'agent invité QEMU, permet de le renouveler sans toucher à la configuration cloud-init.

Droits Proxmox : qui peut modifier la configuration cloud-init ?

Dans le modèle de permissions de Proxmox VE, la modification des paramètres cloud-init d'une VM relève du privilège VM.Config.Cloudinit. Ce privilège paraît anodin, puisqu'il ne donne accès ni aux disques ni à la console. Pourtant, celui qui peut ajouter une clé SSH ou changer le mot de passe, puis redémarrer la VM, obtient un accès à l'invité : le privilège VM.Config.Cloudinit équivaut, en pratique, à un accès administrateur à l'invité.

Recensez donc les rôles, y compris les rôles prédéfinis, qui embarquent ce privilège, puis les utilisateurs, groupes et jetons d'API auxquels ils sont attribués. Les jetons utilisés par Terraform, Ansible ou un portail de libre-service doivent être limités aux pools de VM concernés, avec la séparation des privilèges activée. Les commandes pveum role list et pveum acl list fournissent la matière de cette revue.

Le stockage des snippets mérite la même attention. Les fichiers sont lus par les services Proxmox VE exécutés en root lors de la génération du lecteur : quiconque peut écrire dans ce répertoire, sur l'hôte ou via un partage NFS mal exporté, peut injecter des commandes qui s'exécuteront en root dans toutes les VM utilisant le fichier. Réservez l'écriture aux administrateurs et au pipeline de publication. La démarche globale est décrite dans le guide de hardening Proxmox VE.

Instance-id, clones et clés d'hôte SSH : un effet de bord à maîtriser

Proxmox VE calcule l'instance-id du lecteur cloud-init à partir d'un hachage de la configuration générée. Le ticket 1739 du suivi de bogues Proxmox, ouvert en 2018 et toujours assigné en 2026, documente la conséquence : tout changement de configuration cloud-init produit un nouvel instance-id. Au redémarrage suivant, cloud-init croit découvrir une nouvelle machine et rejoue ses modules par instance.

Le symptôme le plus visible est la régénération des clés d'hôte SSH. Un changement de serveur DNS, y compris sur l'hôte lorsque la VM hérite de ses réglages, suffit à modifier l'empreinte présentée par la VM au redémarrage suivant. Les utilisateurs voient alors l'alerte de changement de clé de leur client SSH, et une équipe qui prend l'habitude de l'ignorer perd une protection essentielle contre l'interception de session.

Trois parades existent. La plus propre fige l'identifiant grâce à un meta-data personnalisé, déclaré via cicustom meta=, contenant un instance-id stable pour chaque VM ; qm cloudinit dump n'affichant que la configuration générée, la vérification se fait dans l'invité, dans /run/cloud-init/.instance-id. La deuxième positionne ssh_deletekeys: false. La troisième désactive cloud-init après le provisionnement en créant le fichier /etc/cloud/cloud-init.disabled.

Chaque parade a un coût. Figer l'instance-id oblige à gérer un fichier meta par VM. Conserver les clés d'hôte empêche aussi leur renouvellement automatique lors d'un véritable redéploiement. Désactiver cloud-init supprime la possibilité de modifier le réseau depuis l'interface. Côté détection, un changement de clé d'hôte non rattaché à une demande de changement reste un signal à investiguer, que la supervision peut remonter en comparant les empreintes connues.

Cluster, migration et haute disponibilité : partager les snippets

La documentation Proxmox VE est explicite : les fichiers personnalisés doivent résider sur un stockage compatible avec les snippets et être disponibles sur tous les nœuds vers lesquels la VM peut migrer, faute de quoi elle ne démarre pas. Un snippet présent sur un seul nœud transforme donc une migration planifiée ou une bascule de haute disponibilité en incident de production.

Deux approches fonctionnent. La première utilise un stockage partagé, CephFS ou NFS, déclaré avec le type de contenu snippets sur l'ensemble du cluster. La seconde distribue des fichiers identiques dans le répertoire local de chaque nœud au moyen de l'outil de gestion de configuration. La première simplifie la cohérence des versions, la seconde évite de dépendre d'un partage réseau pour démarrer une VM.

Avec un partage NFS, limitez l'export aux adresses des nœuds, idéalement sur un réseau de gestion dédié, et réservez les droits d'écriture sur les fichiers au compte de publication. Proxmox VE 9.2 a par ailleurs corrigé un défaut qui pouvait renommer le disque cloud-init lors d'une migration, au point qu'il n'était plus reconnu comme tel. Le guide clustering et haute disponibilité Proxmox VE développe les principes d'un cluster tolérant aux pannes.

Windows et Cloudbase-Init : particularités et précautions

Pour les invités Windows, Proxmox VE s'appuie sur Cloudbase-Init, une réimplémentation de cloud-init pour Windows qui ne couvre pas toutes les fonctions de l'original. Elle exige un ostype Windows et le format ConfigDrive v2, choisi par défaut pour ces systèmes. Aucune image cloud Windows prête à l'emploi n'étant disponible gratuitement, le modèle se construit à la main : installation de Windows et de Cloudbase-Init, configuration, puis Sysprep.

Le mot de passe pose ici une contrainte particulière. La documentation demande de définir l'ostype Windows avant de saisir le mot de passe, sinon Proxmox VE le chiffre et Cloudbase-Init utiliserait la valeur chiffrée comme mot de passe en clair. Autrement dit, pour Windows, le secret doit parvenir à l'invité sous une forme directement exploitable, ce qui renforce l'intérêt d'un mot de passe temporaire et unique par VM.

Après le premier démarrage, changez ce mot de passe initial, puis confiez la gestion du compte administrateur local à Windows LAPS si la machine rejoint un domaine Active Directory ou Microsoft Entra ID. Dans la configuration de Cloudbase-Init, limitez les services de métadonnées au service ConfigDrive et désactivez les modules inutiles : le démarrage est plus rapide et les sources de configuration possibles sont réduites.

Auditer et surveiller vos déploiements cloud-init

Un audit cloud-init se mène des deux côtés : sur l'hyperviseur, où vivent la configuration des VM et les snippets, et dans les invités, où se trouvent les traces d'exécution. Les commandes ci-dessous sont en lecture seule ; les cinq premières se lancent sur un nœud du cluster par un administrateur, les trois dernières dans un invité. Adaptez les chemins et identifiants à vos stockages.

grep -l '^cipassword' /etc/pve/nodes/*/qemu-server/*.conf
grep -H '^cicustom' /etc/pve/nodes/*/qemu-server/*.conf
ls -l /var/lib/vz/snippets/
pveum acl list
qm cloudinit pending 201

sudo cloud-init status --long
sudo grep -n -i -E 'password|token|secret' /var/log/cloud-init-output.log
sudo cat /run/cloud-init/.instance-id

1. Lister les VM qui utilisent encore cipassword et planifier leur passage aux clés SSH.
2. Inventorier les références cicustom et vérifier que chaque fichier existe sur tous les nœuds.
3. Contrôler propriétaire, droits et historique Git de chaque snippet, avec une analyse de secrets automatisée.
4. Revoir les rôles et ACL qui accordent VM.Config.Cloudinit, ainsi que les jetons d'API associés.
5. Vérifier que tous les nœuds exécutent Proxmox VE 9.2 ou une version ultérieure.
6. Dans un échantillon d'invités, contrôler le statut cloud-init, le journal de sortie et le contenu des fichiers authorized_keys.

Côté détection, trois événements méritent une alerte : la modification de la configuration cloud-init d'une VM de production hors fenêtre de changement, l'écriture d'un fichier dans le stockage des snippets par un compte autre que le pipeline, et l'apparition d'une nouvelle empreinte de clé d'hôte SSH. Le journal des tâches Proxmox VE et les journaux système des nœuds alimentent utilement le SIEM pour les deux premiers cas.

Retour terrain : Cas typique rencontré en mission — un snippet user-data contient en clair le jeton d'enregistrement d'un agent de supervision et le mot de passe d'un compte de service réutilisé ailleurs. Le fichier, lisible par tous les comptes du nœud, figure aussi dans l'historique Git et se retrouve dans chaque invité, sur le lecteur cloud-init : l'impact dépasse donc la seule VM. Remédiation : rotation des secrets, purge de l'historique, droits restreints et récupération des secrets au premier démarrage depuis un coffre.

À lire aussi : l'automatisation de Proxmox par scripts.

Questions fréquentes

Conclusion

Cloud-init fait de Proxmox VE une plateforme de provisionnement rapide et reproductible, à condition de traiter chaque maillon comme un élément de sécurité. L'image source se vérifie, le template se généralise et se reconstruit, le user-data se relit comme du code et ne contient aucun secret durable. Les clés SSH remplacent les mots de passe, et le privilège VM.Config.Cloudinit se gère comme un droit d'administration.

Les effets de bord propres à l'intégration Proxmox, comme l'instance-id recalculé à chaque modification ou les snippets absents d'un nœud, se maîtrisent dès lors qu'ils sont connus et testés en lab. Pour replacer cloud-init dans l'ensemble de votre plateforme de virtualisation, le guide complet Proxmox VE constitue le point d'entrée.