patient 0 : le plan de l'ecosysteme dont les autres descendront
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>
2026-08-20 20:51:00 -04:00
|
|
|
---
|
|
|
|
|
# GABARIT de voute de patient 0 — des NOMS, jamais de valeurs.
|
|
|
|
|
#
|
|
|
|
|
# La voute reelle (group_vars/all/vault.yml, chiffree) se cree a la main :
|
|
|
|
|
# ansible-vault create inventories/production/group_vars/all/vault.yml
|
|
|
|
|
# Son mot de passe ne vit NI ici, NI dans aucun depot : 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.
|
|
|
|
|
#
|
|
|
|
|
# P18 confronte ce gabarit aux secrets que le plan exige, puis la voute reelle a ce
|
|
|
|
|
# gabarit. Une cle qui manque ici passe inapercue jusqu'au deploiement.
|
|
|
|
|
|
|
|
|
|
# --- Exiges par des roles que patient 0 DEPLOIE ---
|
|
|
|
|
vault_backup_ssh_privkey: "" # role client_backup
|
|
|
|
|
vault_bd_forgejo: "" # base 'forgejo'
|
|
|
|
|
vault_forgejo_admin: "" # role serveur_forgejo
|
|
|
|
|
vault_forgejo_internal_token: "" # role serveur_forgejo
|
|
|
|
|
vault_forgejo_oidc: "" # role serveur_forgejo
|
|
|
|
|
vault_forgejo_secret_key: "" # role serveur_forgejo
|
|
|
|
|
vault_openldap_admin: "" # role amorcage_acces (playbook serveur_openldap.yml)
|
|
|
|
|
vault_postgresql_keycloak: "" # role serveur_postgresql
|
|
|
|
|
vault_redis: "" # role serveur_redis
|
|
|
|
|
vault_restic_password: "" # role client_backup
|
|
|
|
|
vault_step_ca_password: "" # role serveur_step_ca
|
|
|
|
|
vault_step_ca_provisioner_password: "" # role client_pki
|
|
|
|
|
|
|
|
|
|
# --- Exiges par le harnais, pour des services que patient 0 NE DEPLOIE PAS ---
|
|
|
|
|
# Ces references vivent dans des roles que patient 0 installe (ex. serveur_backup
|
|
|
|
|
# pousse ses resultats vers Icinga, serveur_postgresql connait les bases des
|
|
|
|
|
# autres). Le perimetre est donc plus large que la flotte : meme question de
|
|
|
|
|
# cadrage que celle corrigee sur P32 le 2026-08-20. Les laisser vides tant que le
|
|
|
|
|
# service correspondant n'existe pas.
|
|
|
|
|
vault_grafana_admin: "" # role serveur_grafana (playbook serveur_grafana.yml)
|
|
|
|
|
vault_grafana_oidc: "" # role serveur_grafana (playbook serveur_grafana.yml)
|
|
|
|
|
vault_icinga_api_depot: "" # role serveur_backup (playbook serveur_backup.yml)
|
|
|
|
|
vault_keycloak_admin: "" # role serveur_keycloak (playbook serveur_keycloak.yml)
|
|
|
|
|
vault_nextcloud_admin: "" # role serveur_nextcloud (playbook serveur_nextcloud.yml)
|
|
|
|
|
vault_nextcloud_oidc: "" # role serveur_nextcloud (playbook serveur_nextcloud.yml)
|
|
|
|
|
vault_oauth2_cookie: "" # role serveur_oauth2_proxy (playbook serveur_oauth2_proxy.yml)
|
|
|
|
|
vault_sysadmin_amorcage: "" # role amorcage_acces (playbook serveur_openldap.yml)
|
2026-08-21 13:00:30 -04:00
|
|
|
|
|
|
|
|
# --- Acces au CLUSTER, exiges hors motif `vault_` ---
|
|
|
|
|
# Ces deux-la ne commencent pas par `vault_` et echappent donc au reperage automatique :
|
|
|
|
|
# c'est P18 qui les exige nommement. Ils ouvrent l'API Proxmox pour cloner les VM.
|
|
|
|
|
#
|
|
|
|
|
# A CREER DANS PROXMOX, propre a patient 0 : Datacenter > Permissions > API Tokens.
|
|
|
|
|
# Un jeton PAR TENANT, revocable seul — recopier celui d'un autre tenant reviendrait a
|
|
|
|
|
# leur donner la meme clef, et a ne plus pouvoir en retirer un sans retirer l'autre.
|
|
|
|
|
# Les poser ensuite : ansible-vault edit inventories/production/group_vars/all/vault.yml
|
|
|
|
|
proxmox_api_token_id: ""
|
|
|
|
|
proxmox_api_token_secret: ""
|