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 :

```text
docs/procedure-template-debian13-proxmox.md
```

Résumé :

```text
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 :

```text
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 :

```bash
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 :

```bash
git status --short
make syntaxe-modele
```

L'inventaire doit contenir la VM dans le groupe :

```text
modeles_vm
```

Les variables du template sont dans :

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

### Commande de préparation

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

```bash
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 :

```text
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 :

```bash
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 :

```bash
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 :

```text
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 :

```text
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 :

```text
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

```bash
make verifier-modele
```

## Validation minimale

Avant de déclarer le template prêt :

```bash
make verifier
make preparer-modele
make verifier-modele
```

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

```text
failed=0
changed=0
```

## Nettoyage

```bash
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 :

```text
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 :

```text
docs/integrations-vm.md
```

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

```text
docs/vm-lifecycle.md
```