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>
43 lines
2.3 KiB
YAML
43 lines
2.3 KiB
YAML
---
|
|
# LE RUNNER DE SITE — celui qui MATÉRIALISE.
|
|
#
|
|
# Le travail d'un runner se divise en trois, et les deux premières portées appartiennent
|
|
# au TENANT tandis que la troisième appartient à la FABRIC :
|
|
#
|
|
# calculer plan -> inventaire aucune voûte portée OPS (serveur_ops)
|
|
# configurer rôles sur ses machines voûte du TENANT portée OPS (serveur_ops)
|
|
# matérialiser créer/détruire des VM voûte du SITE portée SITE (ce rôle)
|
|
#
|
|
# POURQUOI LA SÉPARATION. Si chaque écosystème portait le pouvoir de matérialiser, la
|
|
# voûte du SITE se retrouverait en N exemplaires — le secret le plus dangereux du système,
|
|
# recopié autant de fois qu'il y a de locataires. C'est précisément ce que la séparation
|
|
# des voûtes (2026-08-22) cherchait à éviter.
|
|
#
|
|
# Et l'inverse serait pire : un runner UNIQUE qui ferait tout devrait entrer en SSH chez
|
|
# tous les tenants, donc traverser le default-deny inter-tenant — et rendrait toute
|
|
# émancipation impossible, puisqu'un écosystème ne pourrait plus se rebâtir sans son hôte.
|
|
#
|
|
# 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 PEUT 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.
|
|
|
|
serveur_ops_site_utilisateur: "setops"
|
|
serveur_ops_site_racine: "/opt/setops"
|
|
|
|
# Le dépôt du SITE, tel qu'il atterrit chez le runner. Il doit avoir été cloné par
|
|
# `serveur_ops` (entrée `role: hebergeur` de `serveur_ops_depots`).
|
|
serveur_ops_site_depot: ""
|
|
|
|
# --- LA VOÛTE DU SITE --------------------------------------------------------
|
|
#
|
|
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas 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: no` EST OBLIGATOIRE sur la copie. Sans lui, Ansible DÉCHIFFRE la source quand
|
|
# il détient le mot de passe — mesuré le 2026-08-24, 776 octets en clair au lieu de 3465
|
|
# chiffrés, sur une machine où ils n'avaient rien à faire.
|
|
serveur_ops_site_voute_source: ""
|
|
serveur_ops_site_voute_deposer: true
|