verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-06 16:18:23 -04:00

7.2 KiB

Raw Blame History

Cycle de vie des VM

Pour qui : l'exploitant — ce qu'une VM traverse, de l'installation à la conformité continue.

Ce document décrit le cycle normal d'une VM Debian, depuis l'installation minimale jusqu'à la conformité continue par Ansible.

Vue d'ensemble

Debian 13 minimale
→ goldenisation du template
→ cleanup final
→ conversion Proxmox en template
→ clonage
→ identité initiale par cloud-init
→ conformité par groupes Ansible
→ intégrations par rôle
→ conformité continue

1. VM vanille

La VM vanille est une Debian 13 minimale installée manuellement ou par procédure Proxmox.

Elle contient seulement le nécessaire pour être joignable et prise en charge :

Debian 13
SSH
réseau fonctionnel
cloud-init installé
CloudInit Drive Proxmox présent
utilisateur initial injecté par Cloud-Init
clé publique SSH injectée par Cloud-Init
sudo ou accès root possible
aucun rôle applicatif
aucun secret

Cette VM n'est pas encore un golden template.

2. Goldenisation

La goldenisation est faite par :

make preparer-modele

Ce playbook ajoute le socle commun au template :

paquets communs
qemu-guest-agent
cloud-init
compte technique Ansible
chrony
SSH socle
durcissement template-safe
nftables préparé mais désactivé

Les détails et justifications sont dans :

docs/modeles_vm/debian13-proxmox.md

3. Validation et cleanup

Après la préparation :

make verifier-modele

Le cleanup final est séparé et protégé :

make nettoyer-modele CONFIRMER=true

Le cleanup ne doit jamais être lancé sur une VM de production.

4. Clonage

Le clone reçoit son identité initiale par Proxmox et cloud-init :

hostname
utilisateur initial
clé SSH
IP ou DHCP
passerelle
DNS
agrandissement disque

Cloud-init ne remplace pas Ansible pour la configuration réelle du serveur.

4bis. Une VM HORS PLAN, pour éprouver

make creer-vm HOTE=idm-01 dérive tout de l'inventaire — VMID, IP, VLAN, pont, stockage. C'est la voie normale, celle qu'emprunte flotte-creer.

Sous elle vit une couche qui ne consulte aucun plan :

make cloner-vm HOTE=essai-nginx VMID=99123 PONT_PROXMOX=t17appl \
     ADRESSE_IP=10.17.21.99 CIDR=24 PASSERELLE=10.17.21.1

Une Debian issue du gabarit doré, sur le réseau que vous choisissez, en deux minutes. Elle n'apparaît nulle part dans le plan.

À quoi ça sert. À honorer une règle du dépôt : éprouver l'outil avant d'écrire le rôle qui l'enveloppe. Avant de mettre un binaire en boîte — vérifier ses options réelles, sa configuration, ce qu'il fait au premier démarrage — on veut une machine vraie, jetable, qui ne salit rien. C'est ce que fournit cloner-vm. Le gabarit modeleSetOPS a lui-même été recapturé ainsi.

Elle est NUE, et c'est à la fois l'intérêt et le danger. Le moteur ne la connaît pas :

l'inventaire ne la contient pas

make raser ne la détruira jamais — il dérive du plan

DNS, certificat, sauvegarde aucun

pare-feu Proxmox, nftables aucune politique

son VMID gardé par aucune preuve contre une collision

Elle ne disparaît donc que si vous la détruisez :
ansible-playbook playbooks/proxmox/supprimer_vm_debian.yml -e vmid=99123
Choisissez un VMID hors des plages dérivées (les tenants occupent <VLAN><hôte><séq>, neuf chiffres) et notez-le. Un VMID oublié squatte le cluster sans que rien ne le signale — c'est exactement ainsi qu'un pont disparu a survécu dix jours dans une déclaration, en août 2026.


l'inventaire	ne la contient pas
`make raser`	ne la détruira jamais — il dérive du plan
DNS, certificat, sauvegarde	aucun
pare-feu Proxmox, nftables	aucune politique
son VMID	gardé par aucune preuve contre une collision

5. Groupes opérationnels

Une VM déployée doit être placée dans les groupes d'inventaire qui décrivent l'état voulu.

Les hôtes prévus mais non créés restent dans hotes_planifies.

Les hôtes joignables par Ansible sont dans hotes_actifs.

Chaque groupe opérationnel doit avoir un playbook homonyme :

serveur_debian   -> playbooks/groupes/serveur_debian.yml
serveur_durci   -> playbooks/groupes/serveur_durci.yml

L'appartenance aux groupes devient la déclaration d'intention :

web-frontal-01 dans serveur_debian -> applique le socle Debian
web-frontal-01 dans serveur_durci -> applique le durcissement commun

Un groupe sans playbook ne doit pas être assigné à une VM de production.

Un playbook de groupe peut être un contrat temporaire sans rôle tant que le service n'est pas encore implémenté. Il doit rester idempotent et explicite.

6. Socle Debian

Le groupe serveur_debian maintient les composants de base :

make deployer-groupe GROUPE=serveur_debian

7. Hardening commun

Le groupe serveur_durci maintient les couches de sécurité communes :

make deployer-groupe GROUPE=serveur_durci

L'accès SSH par mot de passe est désactivé dès le socle. L'activation de nftables doit rester dépendante des règles réseau propres au rôle du serveur.

8. Déploiement par Makefile

L'hôte est d'abord déclaré dans le plan (instance/plan/serveurs.yml) et l'inventaire régénéré (make instancier-appliquer) — hosts.yml est généré, il ne s'édite plus à la main. Pour une VM déjà clonée et démarrée :

make deployer HOTE=web-frontal-01

La cible deployer lit les groupes de l'hôte, cherche les playbooks correspondants dans playbooks/groupes/, puis les applique dans l'ordre des couches — le socle (serveur_debian, serveur_durci) d'abord, puis le rang de docs/couches-deploiement.yml, le même registre que make site.

Ce n'est pas « l'ordre de l'inventaire », et la nuance a coûté un déploiement. Un tri alphabétique plaçait client_metrique avant serveur_step_ca : l'intégration réclamait un certificat que l'autorité, pas encore déployée, ne pouvait pas avoir émis. Constaté le 2026-08-06 sur les deux premières VM — dont l'hôte de l'AC lui-même. La couche « intégrations » dit en toutes lettres déployées en dernier, quand leurs cibles sont debout ; make deployer l'ignorait.

Ensuite, elle lance la vérification post-déploiement :

playbooks/groupes/serveur_debian.yml
playbooks/groupes/serveur_durci.yml
verifier-hote

Pour converger un groupe complet :

make deployer-groupe GROUPE=serveur_debian

Cette commande limite le playbook au croisement entre le groupe demandé et hotes_actifs.

9. Variables template et conformité

Les variables du template servent à construire le golden template dans instance/inventories/<inventaire>/group_vars/modeles_vm.yml.

Les variables de conformité servent aux VM déployées dans instance/inventories/<inventaire>/group_vars/serveur_debian.yml.

Différence attendue :

template      : SSH par clé seulement, pare-feu non activé
conformité VM : même base SSH, règles réseau adaptées aux serveurs finaux

Ne pas durcir une variable de conformité si son application peut couper l'accès sans validation préalable.

10. Intégrations futures

Les intégrations transversales sont ajoutées après socle et durcissement :

DNS interne
PKI interne
identité
supervision
métriques
visualisation

Elles sont documentées dans :

docs/integrations-vm.md

7.2 KiB Raw Blame History