Daniel Allaire 2b55761fba runner : separer le pouvoir de configurer de celui de materialiser

La ligne de partage est celle des voutes. serveur_ops calcule et configure --
voute du tenant, SSH chez lui. serveur_ops_site materialise -- voute du SITE,
API de l'hyperviseur, jamais de SSH chez un tenant.

Un runner par tenant qui materialiserait mettrait la voute du SITE en N
exemplaires. Un runner unique qui ferait tout traverserait le default-deny
inter-tenant et rendrait l'emancipation impossible.

Le role depose la voute CHIFFREE et relit l'en-tete apres avoir ecrit : sans
`decrypt: false`, Ansible dechiffre la source quand il detient le mot de passe
-- constate le jour meme, 776 octets en clair au lieu de 3465. Controle negatif
fait, la garde mord.

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

2026-08-24 15:30:03 -04:00

2.8 KiB

Raw Blame History

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.

2.8 KiB Raw Blame History