Set-OPS-Public/docs/modeles_vm/debian13-proxmox.md

Golden template Debian 13 Proxmox

Pour qui : qui fabrique ou audite le gabarit d'or — ce que Set-OPS ajoute à une Debian 13 minimale, et pourquoi chaque ajout est là.

Objet

Ce document justifie les ajouts appliqués par Set-OPS à une installation Debian 13 minimale pour obtenir le golden template Proxmox.

Le template doit rester un socle commun, clonable et sécuritaire. Il ne doit pas devenir un serveur applicatif ni intégrer des dépendances propres à un rôle final.

État de départ

L'état de départ attendu est décrit dans :

docs/procedure-template-debian13-proxmox.md

Résumé :

Debian 13 minimal
aucun environnement graphique
SSH installé
partition EFI
partition racine ext4
pas de LVM
pas de swap
disque agrandissable
CloudInit Drive Proxmox présent
ciuser et clé SSH injectés par Cloud-Init
aucun secret
aucune donnée propre à un clone final

La carte réseau du gabarit porte mtu=1

mtu=1 est la valeur Proxmox qui signifie « hérite du pont » (virtio uniquement) — et non « MTU de 1 octet ». Tout clone naît donc au MTU du pont auquel il est réellement attaché : 1450 sur une zone SDN EVPN (VXLAN coûte 50 octets), 1500 sur un pont classique.

Sans elle, l'invité naît à 1500 quel que soit le pont. La panne qui en découle est sournoise et invisible tant que toutes les VM vivent sur le même hyperviseur — elles communiquent alors par le pont local, sans encapsulation. Mesuré le 2026-08-10 : zones à 1450, les quatorze invités à 1500, aucun symptôme, parce que les quatorze étaient sur asgard.

Écrire 1450 en dur serait faux hors SDN ; hériter reste juste dans les deux mondes, et le jour où la fabric passera aux trames jumbo.

Ce réglage se perd à chaque recapture du gabarit — le vérifier fait partie de la recapture. cloner_vm_debian.yml le repose de toute façon à chaque clone, et make mtu-mesurer contrôle le résultat sur la flotte.

Runbook du playbook prepare

Objectif

Le playbook debian13_proxmox_preparer.yml transforme une VM Debian 13 minimale en socle golden template.

Il installe les composants communs, configure l'accès Ansible, applique le durcissement template-safe et prépare la VM pour cloud-init.

Il ne fait pas le nettoyage final avant conversion en template.

Prérequis côté VM

Avant de lancer le playbook, la VM doit respecter ces conditions :

Debian installé et démarré
réseau fonctionnel
SSH joignable depuis le poste Ansible
CloudInit Drive présent côté Proxmox
utilisateur Ansible initial injecté par Cloud-Init
clé publique SSH injectée par Cloud-Init
sudo ou accès root possible
APT fonctionnel
aucun rôle applicatif déjà installé
VM destinée à devenir un template, pas un serveur de production

Vérifications utiles depuis le poste Ansible :

ssh ansible@<ip-de-la-VM-modele>   # l'adresse est celle que tu lui as donnee, pas une derivee du plan
ansible -i "$SETOPS_INVENTAIRE" modeles_vm -m ping
ansible -i "$SETOPS_INVENTAIRE" modeles_vm -m setup

SETOPS_INVENTAIRE est exporté par le Makefile, qui résout le nom de l'inventaire (INVENTAIRE_LAB essaie lab, puis principal, puis production) — cette instance-ci n'a pas de lab/, et un chemin écrit en dur y échouait. Adapter l'utilisateur et l'adresse IP selon l'inventaire ainsi résolu.

Prérequis côté dépôt

Avant l'exécution :

git status --short
make syntaxe-modele

L'inventaire doit contenir la VM dans le groupe :

modeles_vm

Les variables du template sont dans :

instance/inventories/<inventaire>/group_vars/modeles_vm.yml

Commande de préparation

Lancement lorsque l'accès par clé et sudo sont fonctionnels :

make preparer-modele

Le flux make suppose que SSH par clé et sudo NOPASSWD sont déjà fonctionnels pour ansible.

Déroulement attendu

Le playbook :

1. vérifie que la cible est Debian ;
2. avertit si la version majeure n'est pas Debian 13 ;
3. installe les paquets communs ;
4. active qemu-guest-agent ;
5. installe et configure cloud-init ;
6. configure le compte technique Ansible ;
7. active la synchronisation du temps ;
8. configure SSH ;
9. applique le durcissement template-safe ;
10. prépare nftables sans l'activer ;
11. affiche le statut cloud-init.

Résultat attendu

Une première exécution peut changer la VM.

Une relance sur une VM déjà préparée doit idéalement finir avec :

failed=0
changed=0

Un résultat changed=0 à la relance est le signal que le playbook est idempotent dans l'état actuel.

Erreurs fréquentes

Symptôme	Cause probable	Action
UNREACHABLE	IP, SSH, utilisateur ou clé SSH incorrecte.	Vérifier l'inventaire résolu ($SETOPS_INVENTAIRE), cloud-init et tester ssh.
échec become	Sudo NOPASSWD absent ou utilisateur non autorisé.	Corriger l'accès sudo initial, puis relancer make preparer-modele.
échec APT	DNS, passerelle, miroir Debian ou verrou APT.	Vérifier réseau, DNS et processus APT en cours.
erreur handler SSH	Handler manquant ou nom notify incohérent.	Vérifier les handlers du rôle SSH avant de relancer.
avertissement Debian non 13	La cible n'est pas Debian 13.	Ne pas convertir en template Debian 13 sans justification.

Point d'arrêt

Après prepare, ne pas convertir immédiatement la VM en template.

Exécuter d'abord :

make verifier-modele

Le playbook de vérification contrôle notamment Debian 13, les paquets requis, l'absence de swap actif, l'absence d'environnement graphique, les services de base, nftables désactivé, sudo NOPASSWD et le durcissement SSH effectif.

Le nettoyage final se lance seulement après validation complète :

make nettoyer-modele CONFIRMER=true

Ne pas lancer le cleanup final sur une VM encore en diagnostic ou sur un serveur final.

Préparation Ansible

Le playbook applique les rôles suivants :

common_packages
qemu_guest_agent
cloud_init
sudo_ansible
chrony
ssh_baseline
systemd_ssh_auto
motd
hardening_packages
sysctl_durcissement
core_dumps
unattended_upgrades
apparmor
auditd
fail2ban_ssh
journald
ssh_durcissement
nftables_socle

Justification des ajouts

Rôle	Ajout ou changement	Justification	Limite volontaire
common_packages	Installe les outils système et diagnostic de base.	Permet l'administration locale, le dépannage réseau, l'exécution fiable d'Ansible et les opérations de maintenance courantes.	Aucun service applicatif spécialisé n'est installé.
qemu_guest_agent	Installe et active qemu-guest-agent.	Donne à Proxmox une visibilité propre sur l'état de la VM et facilite les opérations d'arrêt, IP reporting et gestion depuis l'hyperviseur.	Ne remplace pas la supervision applicative.
cloud_init	Installe cloud-init et cloud-guest-utils, puis active les services cloud-init.	Donne au clone son identité initiale : hostname, utilisateur, clé SSH, IP, DNS et agrandissement de disque.	Cloud-init ne sert pas à configurer les applications.
sudo_ansible	Crée ou maintient le compte technique et son sudo NOPASSWD.	Permet l'administration automatisée par Ansible sans stocker de mot de passe dans le dépôt.	Ce compte doit rester technique et contrôlé.
chrony	Installe et active la synchronisation du temps.	Un temps correct est nécessaire pour TLS, journaux, audit, Kerberos/LDAP futur, monitoring et corrélation d'incidents.	La source NTP définitive peut être ajustée plus tard par inventaire.
ssh_baseline	Pose la base SSH : root interdit, clé publique obligatoire, mot de passe désactivé.	Force un accès administrateur par clé dès la construction du template.	Cloud-init doit avoir injecté le ciuser et sa clé avant Ansible.
systemd_ssh_auto	Désactive le comportement systemd.ssh_auto si demandé.	Évite une exposition SSH automatique via mécanismes transitoires non désirés dans un template serveur.	Ne remplace pas la politique SSH principale.
motd	Déploie un message d'accueil sobre.	Identifie le contexte de l_instance et rappelle que la machine est gérée par Set-OPS.	Ne doit pas contenir d'information sensible.
hardening_packages	Installe les paquets de sécurité communs.	Fournit les briques nécessaires au durcissement sans configurer de service applicatif.	Les politiques strictes par rôle restent appliquées sur les clones.
sysctl_durcissement	Applique des paramètres noyau de sécurité.	Réduit des comportements réseau et noyau risqués avec des réglages standards pour serveur Linux.	Les réglages spécifiques à une charge de travail peuvent être ajustés par rôle.
core_dumps	Désactive les core dumps.	Limite le risque de fuite de secrets ou données sensibles dans des dumps mémoire.	Un serveur de debug peut réactiver un comportement adapté hors template.
unattended_upgrades	Configure les mises à jour automatiques de sécurité.	Réduit l'exposition aux vulnérabilités connues sur les clones qui restent proches du socle.	Les redémarrages automatiques restent désactivés par défaut.
apparmor	Installe et active AppArmor.	Ajoute une couche de confinement standard Debian avec faible coût opérationnel.	Les profils applicatifs spécifiques seront gérés par les rôles applicatifs.
auditd	Installe auditd et des règles de base.	Fournit une trace système utile pour exploitation, investigation et conformité minimale.	Les règles lourdes ou propres à une application ne vont pas dans le template.
fail2ban_ssh	Active une protection SSH simple contre les essais répétés.	Réduit le bruit et les attaques opportunistes sur SSH sans dépendre d'une plateforme centrale.	Ne remplace pas un pare-feu ni une politique d'accès réseau.
journald	Limite l'usage disque et la rétention des journaux.	Évite qu'une VM issue du template remplisse son disque à cause des logs système.	La centralisation des logs viendra plus tard si nécessaire.
ssh_durcissement	Ajoute les paramètres SSH plus stricts : port, délais, tentatives, keepalive, forwarding et tunnels désactivés.	Réduit la surface d'exposition SSH sans dépendre d'un rôle applicatif.	Les exceptions, comme un bastion ou du forwarding contrôlé, doivent être portées par un rôle dédié.
nftables_socle	Installe nftables et prépare une configuration, mais garde le service désactivé par défaut.	Prépare le standard pare-feu sans risquer de couper l'accès au template ou aux clones.	L'activation se fait par rôle serveur avec règles adaptées.

Paquets communs

Les paquets communs sont choisis pour l'exploitation réelle :

administration : sudo, acl, bash-completion, tmux, vim, nano
transport      : curl, wget, ca-certificates, gnupg
ansible        : python3, python3-apt, python3-pip
diagnostic     : htop, iotop, iftop, sysstat, lsof, ncdu, tree, file, less
réseau         : dnsutils, iproute2, iputils-ping, net-tools, traceroute, mtr-tiny, tcpdump, netcat-openbsd, socat
maintenance    : rsync, unzip, zip, tar, jq, logrotate, unattended-upgrades, apt-listchanges, needrestart
virtualisation : qemu-guest-agent, cloud-init, cloud-guest-utils
temps          : chrony

Ces paquets sont acceptés dans le template parce qu'ils sont utiles sur presque tous les serveurs et ne transforment pas la VM en serveur applicatif.

Choix de sécurité importants

SSH

État attendu dès la construction :

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey

Le playbook prepare ne doit être lancé qu'après validation de l'accès SSH par clé au compte technique.

Pare-feu

nftables est installé et préparé, mais désactivé par défaut.

Ce choix est volontaire : un pare-feu générique dans un template peut couper l'accès SSH ou bloquer un futur rôle serveur. L'activation doit être faite sur un clone avec des règles correspondant à son usage.

Nettoyage final

Le nettoyage final est séparé et protégé par confirmation explicite. Il ne doit être lancé qu'au moment où la VM est validée et prête à être convertie en template.

Vérification

make verifier-modele

Validation minimale

Avant de déclarer le template prêt :

make verifier
make preparer-modele
make verifier-modele

La relance du playbook de préparation doit idéalement finir avec :

failed=0
changed=0

Nettoyage

make nettoyer-modele CONFIRMER=true

Ne pas lancer le nettoyage final sur un serveur de production ou sur une VM qui n'est pas destinée à devenir un template.

Hors périmètre du template

Les éléments suivants ne doivent pas être installés dans le golden template :

NGINX
PostgreSQL
MariaDB
Docker
Podman
Redis
GitLab
Nextcloud
monitoring complet
agents applicatifs spécialisés
données propres à un clone
secrets
clés privées

Les intégrations futures sont documentées dans :

docs/integrations-vm.md

Le cycle complet VM vanille, golden template, clone et conformité continue est documenté dans :

docs/vm-lifecycle.md