Daniel Allaire 835f8ab6d0 Mise en conformité prouvable : registre d'affirmations + make prouver

Le dépôt fait / explique / prouve ce qu'il affirme, vérifiable en une commande.

- Phase 1 : docs/audit/affirmations.md — 54 affirmations publiques tracées vers
  une commande de preuve et un statut (✅/🟡/❌/⚪).
- Phase 2 : CLAUDE.md réduit à un pointeur mince ; contradiction SSH levée (le
  code applique déjà PasswordAuthentication no + AuthenticationMethods publickey,
  conforme à AGENTS.md) ; section AGENTS « Codex » → « agents IA ».
- Phase 3 : parcours démarrage réparé (QUICKSTART renvoyait à un modèle absent,
  chemins de voûte faux, commandes make périmées) ; make verifier vert
  (ansible-lint 33 → 0 : site.yml généré nommé, pipefail, name[template]) ;
  voûte Proxmox unifiée lue par le clonage (all/vault.yml).
- Phase 4 : make prouver → docs/audit/preuve-<date>.md, harnais rejouable qui
  rappelle l'outillage existant (aucune validation réimplémentée).
- Phase 5 : parcours QUICKSTART prouvé hors-ligne sur le socle ; modèle socle
  rendu valide (autorite interne → auto-heberge) ; split-brain d'inventaire
  corrigé (repli sur le répertoire existant, pas principal/).

make prouver : 15 OK, 0 échec, 1 sautée (voûte). ansible-lint : 0 failure.
Écarts découverts en cours de traitement (AFF-097..100) : tous résolus.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 19:53:18 -04:00

4.7 KiB

Raw Permalink Blame History

Cycle de vie des VM

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.

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 de l'inventaire.

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/production/group_vars/modeles_vm.yml.

Les variables de conformité servent aux VM déployées dans instance/inventories/production/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

4.7 KiB Raw Permalink Blame History