runner : `serveur_ops_tenant` — le runner d'un tenant recoit enfin sa voute
La doctrine des runners decrit trois portees depuis le 2026-08-22 :
calculer plan -> inventaire aucune voute serveur_ops
configurer roles sur ses machines voute du TENANT <- revendiquee, jamais recue
materialiser creer/detruire des VM voute du SITE serveur_ops_site
La deuxieme ligne etait un trou. RIEN ne deposait jamais la voute d'un tenant sur
son runner. Un runner pouvait deriver son inventaire et ne rien pouvoir en faire :
chaque role qui demande un secret echouait sur son assertion, et l'echec ne disait
pas qu'il manquait un FICHIER, seulement que les valeurs etaient vides.
Decouvert en preparant la reconstruction de Chezlepro. Le runner du SITE peut
materialiser ses quinze machines ; il ne peut pas les configurer, parce que
Chezlepro a sa PROPRE autorite de certification — donc `client_pki` y reclame un
secret de Chezlepro. Le runner du site ne l'a pas, et NE DOIT PAS l'avoir : c'est
la ligne qui rend l'hebergement mutualise defendable.
`serveur_ops_tenant` est le symetrique exact de `serveur_ops_site` : un MARQUEUR,
pas un installateur. Il depose la voute `decrypt: false`, puis RELIT l'en-tete du
fichier depose — une voute dechiffree par accident est une fuite silencieuse. Le
dossier d'inventaire (`principal` ou `production`) se DECOUVRE sur la machine
plutot que d'etre ecrit.
Pourquoi un role a part et non une option de `serveur_ops` : donner sa voute a un
runner est un POUVOIR, pas un reglage. Le declarer au plan force a repondre a
« cette machine a-t-elle le droit de configurer cet ecosysteme ? » — une option
activee par defaut y repondrait a notre place.
CHEZLEPRO LISAIT ENCORE SON GENOME CHEZ PATIENT 0.
Trouve au passage, et bloquant pour la reconstruction : `serveur_ops_forge_amont`
pointait sur `10.29.16.11` — la forge de patient 0, l'amont d'avant que le site
ait la sienne. D-81 a tranche depuis. Laisse tel quel, Chezlepro se serait
reconstruit depuis un moteur perime, sur un reseau que le decoupage en zones a de
toute facon deplace.
Corrige vers la forge du site, PAR SON IP — `forge.genese.internal` appartient a
la zone souveraine du site, et un tenant ne resout que la sienne ; le certificat
SERVI porte bien `IP Address:10.0.33.11`. La racine de l'AC du site est desormais
versionnee a cote de la carte de la fabric a laquelle elle appartient, et son
chemin se DERIVE du symlink `underlay.yml` : il vaut depuis le poste comme depuis
un runner.
Le role est inscrit dans les quatre registres qui l'exigeaient — couches de
deploiement, graphe des dependances, catalogue des services, carte d'orientation.
Ce sont les preuves P08, P38 et P48 qui l'ont reclame, chacune a son tour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 15:30:51 -04:00
|
|
|
---
|
|
|
|
|
# Flux réseau du runner de TENANT. Voir docs/flux-conception.md.
|
|
|
|
|
#
|
insemination : declarer le lien, l'emettre d'un seul cote, et un test rouge
L'insemination avait un nom depuis ce matin ; elle n'avait pas de flux. Deux
declarations, aux deux bouts, et rien d'autre :
serveur_ops_site egress 22/tcp -> serveur_ops_tenant
serveur_ops_tenant ingress 22/tcp <- runner_site partage: true
ETROIT PAR CONSTRUCTION : il vise le GROUPE `serveur_ops_tenant`, qu'un ecosysteme
ne pose que sur une machine. Au socle, il aurait ouvert le SSH du site vers toute
la flotte du tenant.
L'en-tete disait « ce role n'entre JAMAIS chez un tenant ». Frontiere intenable :
`creer-vm` exige `_instance-requise`, et le runner du site avait deja du basculer
son symlink `instance` sur OPS-Chezlepro pour materialiser ses VM. Declarer ne cree
pas ce pouvoir — ca rend limitable un pouvoir qui s'exercait sans borne. Ce qui
reste interdit n'est pas une regle mais un FAIT : il n'a pas la voute du tenant.
LA REGLE EST EMISE D'UN SEUL COTE, et pas celui qu'on croit. Le paquet penetre le
pare-feu par la patte du SITE, pas par le transit : la regle appartient au cote
site du devis. L'emettre aussi depuis l'`ingress` du tenant aurait produit une
seconde regle sur la mauvaise interface — jamais evaluee, indiscernable d'une regle
utile. La declaration du tenant pose sa regle nftables, et elle seule :
ip saddr { 10.0.31.11 } tcp dport 22 accept
L'adresse DERIVE du plan du site. Ecrite a la main, elle aurait survecu au prochain
deplacement du runner sans bruit — le site a deja deplace ses machines le 08-25.
Plan de la frontiere : 2 objets a creer, 0 a retirer, 126 inchanges. RIEN D'APPLIQUE.
P41 APPLIQUEE AU PLAN DU SITE : `resoudre_flux` en avait besoin a son tour ; les
trois lecteurs demenagent dans `underlay` et `devis_opnsense` delegue.
DEUX GARDES ONT TRAVAILLE : P33 a refuse `ingress 22` sur un hote portant deja le
sshd du socle (reponse : `partage: true`, comme `serveur_backup`), et le devis a
refuse d'emettre vers un alias vide.
UN TEST ROUGE DEPUIS TROIS JOURS. `test_adressage_derive` construisait un site avec
un `index` — or un SITE n'en a pas depuis add94f2 (08-25), remplace par
`bande_basse_de`. Invisible parce que le geste quotidien est `make prouver`, qui ne
joue pas les tests. Remis sur le contrat actuel, avec sa contrepartie : sans
`bande_basse_de`, aucun chevauchement n'est tolere.
make verifier : vert. make prouver : CONFORME, 52 OK, 0 echec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-08-28 13:09:28 -04:00
|
|
|
# UN SEUL FLUX, ET C'EST LE LIEN DE FILIATION.
|
|
|
|
|
#
|
|
|
|
|
# Ce rôle ne fait que déposer un fichier ; ce qui consomme la voûte, c'est `serveur_ops`
|
|
|
|
|
# quand il configure les machines de l'écosystème, et ses flux sont déclarés chez lui.
|
|
|
|
|
# Ce rôle n'atteint NI la fabric NI la frontière — c'est exactement ce qui le sépare de
|
|
|
|
|
# `serveur_ops_site`.
|
|
|
|
|
#
|
|
|
|
|
# Mais il porte la marque de l'INSÉMINATION. Un écosystème neuf ne peut pas s'amorcer
|
|
|
|
|
# lui-même : quelqu'un doit poser sa première machine et lui donner de quoi continuer.
|
|
|
|
|
# Ce quelqu'un est le runner du SITE, et ce flux est le seul chemin par lequel il entre —
|
|
|
|
|
# vers cette machine-ci, et vers aucune autre du tenant.
|
|
|
|
|
#
|
|
|
|
|
# POURQUOI IL EST DÉCLARÉ ICI ET PAS AU SOCLE. Au socle, il ouvrirait le SSH du site vers
|
|
|
|
|
# TOUTES les machines du tenant, ce que l'isolation refuse. Déclaré sur ce rôle, il ne
|
|
|
|
|
# vaut que pour les hôtes qui le portent — un seul par écosystème. La portée du pouvoir
|
|
|
|
|
# est celle du groupe, et le groupe est écrit au plan.
|
|
|
|
|
#
|
|
|
|
|
# CE QU'IL NE TRANSPORTE JAMAIS : un secret. Le runner du SITE peut poser le socle, le
|
|
|
|
|
# moteur, le plan et le plancher de résolution — tout cela est public. Il ne détient pas
|
|
|
|
|
# la voûte du tenant (elle est hors dépôt) et n'en connaît pas le mot de passe. C'est
|
|
|
|
|
# l'humain qui arme ce runner, et c'est voulu : voir `docs/filiation-emancipation.md`.
|
|
|
|
|
flux:
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 22
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: runner_site
|
|
|
|
|
chiffrement: ssh
|
|
|
|
|
# CE ROLE N'OUVRE AUCUNE ECOUTE — il emprunte le sshd du socle, comme
|
|
|
|
|
# `serveur_backup`. Sans ce mot, P33 y voit deux roles qui se disputent le port 22
|
|
|
|
|
# sur la meme machine, et elle a raison de le demander : il n'y a que le registre
|
|
|
|
|
# pour distinguer « j'ouvre une ecoute » de « j'autorise une source de plus sur
|
|
|
|
|
# l'ecoute d'un autre ».
|
|
|
|
|
partage: true
|
|
|
|
|
raison: >-
|
|
|
|
|
Insémination : le runner du SITE amorce ce runner-ci — socle, moteur, plan,
|
|
|
|
|
plancher de résolution — jusqu'à ce qu'un humain lui remette sa voûte. Vers cette
|
|
|
|
|
machine seule, jamais vers le reste de l'écosystème.
|