Les deux depots prives sont miroites via un jeton de lecture seule
(vault_miroir_amont). Ils restent lisibles sur la forge de patient 0 : c'est
ainsi que son poste les clone, en anonyme, sans detenir de justificatif.
Le gabarit de voute reclamait encore proxmox_api_token_id/secret d'un tenant qui
ne doit pas les detenir : depuis la separation des voutes, le jeton du cluster
appartient a l'hebergeur, et proxmox_api.voute() lui donne raison quand les deux
portent la cle. Un jeton pose dans le tenant serait ignore.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ansible-vault` chiffre avec la cle de voute de l'exploitant — le mot de passe n'a jamais
transite, seul son chemin. Les valeurs sont tirees au hasard (40 caracteres) et n'ont ete
affichees nulle part. La voute est ignoree par git : seul le gabarit est versionne.
CAS PARTICULIER, `vault_backup_ssh_privkey` : une VRAIE paire de cles ed25519 a ete
generee. La privee est en voute ; la PUBLIQUE est dans cle-publique-sauvegarde.txt, a
poser sur le depot restic le jour venu. Une cle publique n'est pas un secret.
DEUX SECRETS MANQUENT DELIBEREMENT — `proxmox_api_token_id` et `_secret`. Ils
n'ont pas le prefixe `vault_` et echappaient au reperage : le gabarit les nomme
desormais. Ils doivent etre CREES DANS PROXMOX, propres a patient 0 (Datacenter >
Permissions > API Tokens). Recopier le jeton d'un autre tenant leur donnerait la meme
clef, et on ne pourrait plus en revoquer un sans revoquer l'autre.
P18 refuse donc encore patient 0, et c'est le comportement voulu : la preuve attend une
action humaine, elle ne l'invente pas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aujourd'hui, tout ce qui fabrique Chezlepro vit sur `eregion` — une machine HORS FLOTTE,
montee a la main, que Set-OPS ne deploie pas, ne sauvegarde pas et ne prouve pas. Un
ecosysteme entier depend d'un point unique que le moteur ignore.
Patient 0 le remplace par le plus petit ecosysteme COMPLET (PKI, DNS, edge, courriel,
PostgreSQL, forge — six machines), bati par le moteur, sauvegarde par le moteur, verifie
par le harnais. On ne deplace pas le point unique de defaillance : on l'elimine.
Derive du modele `forge`, avec trois ecarts assumes :
- INDEX 29 (10.29.0.0/16, VLAN 1291-1296), choisi libre : 13 lab, 17 Chezlepro,
23 Technolibre ; les index bas (1, 11) ont deja force deux renumerotages.
- `federe: false` — patient 0 est EXCLU des devis du site tant qu'il n'est pas
materialise. Une flotte en cours de reconstruction n'a pas a se voir reserver des VLAN
et des regles pour un ecosysteme qui n'existe pas (c'est exactement ce qui avait
injecte les adresses d'un tenant perime dans le pare-feu partage, le 2026-08-12).
A basculer a `true` AVANT `make sdn-appliquer`, le jour du deploiement.
- `forge-01` recoit 80G au lieu du defaut : elle hebergera les depots de TOUTE la
lignee, pas seulement les siens.
Le modele `forge` dont il derive etait lui-meme perime sur deux points, corriges ici :
`client_pki` liste a la main alors que l'integration est devenue universelle, et un FQDN
expose reste en `exemple.internal`. Les modeles PRIVES ne sont pas couverts par le
harnais — P17 ne decouvre que le modele public.
VERIFIE : les quatre registres valident, le gabarit de voute couvre les 20 secrets exiges,
l'inventaire est genere et applique. Et sur l'instance de l'exploitant, en pleine
reconstruction : `make verifier` -> 38 OK, 0 echec, 0 saute ; les devis ne voient
toujours que Chezlepro et Technolibre.
CE QUI N'EST PAS ICI, ET NE LE SERA JAMAIS : le mot de passe de la voute. C'est le seul
objet que la reproduction exige d'un humain — le mettre dans la forge reviendrait a
enfermer la cle dans le coffre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
