Daniel Allaire
d3ba520500
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
|
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
serveur_ops_site
Le runner de SITE : celui qui matérialise. Il crée des VM sur la fabric, et rien d'autre.
Pourquoi ce rôle existe séparément
Le travail d'un runner se divise en trois, et la ligne de partage est celle des voûtes :
| voûte requise | portée | rôle | |
|---|---|---|---|
| calculer — plan → inventaire | aucune | tenant | serveur_ops |
| configurer — rôles sur ses machines | tenant | tenant | serveur_ops |
| matérialiser — créer/détruire des VM | SITE | fabric | ce rôle |
Un runner par tenant qui matérialiserait mettrait la voûte du SITE en N exemplaires — le secret le plus dangereux du système, recopié autant de fois qu'il y a de locataires.
Un runner unique qui ferait tout devrait entrer en SSH chez tous les tenants, donc traverser le default-deny inter-tenant. Et il rendrait l'émancipation impossible : un écosystème dont le runner appartient à l'hébergeur ne peut pas se rebâtir sans lui.
Deux pouvoirs, deux rôles, aucun omnipotent. Ce rôle crée des VM vides et n'entre
jamais chez un tenant ; serveur_ops habille des machines et ne touche jamais la fabric.
Qui a le droit de le déclarer
L'écosystème de l'hébergeur, celui qui exploite la fabric. Un tenant ordinaire qui le déclarerait s'arrogerait un pouvoir sur ses voisins.
Ce qu'il dépose, et comment
La voûte du SITE, chiffrée, en 0600. Le mot de passe n'est jamais stocké : le
Makefile ajoute --ask-vault-pass quand aucun fichier de mot de passe n'est défini, et
l'exploitant le tape au moment d'agir.
decrypt: false est obligatoire sur la copie. Sans lui, Ansible déchiffre la source
quand il détient le mot de passe — constaté le 2026-08-24 : 776 octets en clair au lieu de
3465 chiffrés, sur une machine où ils n'avaient rien à faire. Le rôle relit l'en-tête
après avoir écrit et refuse si le fichier n'est pas chiffré.
Colocalisation
Rien n'oblige à lui donner sa propre machine : chez l'hébergeur, les deux pouvoirs résident légitimement au même endroit, et une machine de plus dans un écosystème volontairement maigre se paie. Le déclarer séparément rend le pouvoir visible, ce qui est l'essentiel.
Chez un tenant qui n'est pas l'hébergeur, la question ne se pose pas : le rôle n'a pas à y être.
Variables
| Variable | Rôle |
|---|---|
serveur_ops_site_depot |
dossier du dépôt SITE chez le runner (cloné par serveur_ops) |
serveur_ops_site_voute_source |
chemin de underlay.vault.yml sur le contrôleur |
serveur_ops_site_voute_deposer |
false pour un runner qui lit la carte sans détenir les clés |
Ce que ce rôle ne fait pas
Il n'installe rien, n'ouvre aucun port, ne sauvegarde rien. Il ne fait qu'attribuer un pouvoir — et le rendre lisible dans le plan.