Daniel Allaire
2b55761fba
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>
62 lines
2.8 KiB
Markdown
62 lines
2.8 KiB
Markdown
# 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.
|