Daniel Allaire
be06def899
Le runner fabriquait sa paire a sa naissance : reconstruit, il avait une identite que la flotte ne connaissait pas (refuse sur les 13 machines de Technolibre). La cle privee vit dans la voute du locataire ; serveur_ops_tenant la remet et exige que sa cle publique soit declaree au plan (garde eprouvee en defaut). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
104 lines
5.9 KiB
YAML
104 lines
5.9 KiB
YAML
---
|
|
# LE RUNNER D'UN TENANT — celui qui CONFIGURE.
|
|
#
|
|
# Le travail d'un runner se divise en trois portées, et chacune a son rôle :
|
|
#
|
|
# calculer plan -> inventaire aucune voûte `serveur_ops`
|
|
# configurer rôles sur ses machines voûte du TENANT CE RÔLE
|
|
# matérialiser créer/détruire des VM voûte du SITE `serveur_ops_site`
|
|
#
|
|
# CE QUI MANQUAIT (2026-08-26). La portée « configurer » était attribuée à `serveur_ops`
|
|
# dans la doctrine — mais rien ne déposait jamais la voûte du tenant sur son runner. Un
|
|
# runner pouvait donc dériver son inventaire et ne rien pouvoir en faire : chaque rôle qui
|
|
# demande un secret échouait sur son assertion, et l'échec ne disait pas qu'il manquait un
|
|
# FICHIER, seulement que les valeurs étaient vides.
|
|
#
|
|
# Découvert en préparant la reconstruction de Chezlepro : le runner du SITE peut
|
|
# matérialiser ses quinze machines, mais ne peut pas les configurer — Chezlepro a sa
|
|
# PROPRE autorité de certification, donc `client_pki` y réclame 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'hébergement mutualisé défendable.
|
|
#
|
|
# POURQUOI UN RÔLE À PART, et non une option de `serveur_ops`. Donner sa voûte à un runner
|
|
# est un POUVOIR, pas un réglage. Le déclarer explicitement au plan force à répondre à la
|
|
# question « cette machine a-t-elle le droit de configurer cet écosystème ? » — alors
|
|
# qu'une option activée par défaut y répondrait à notre place. C'est le même patron que
|
|
# `serveur_artefacts` + `serveur_cache_site` : un installateur, puis un marqueur qui
|
|
# ajoute un pouvoir.
|
|
#
|
|
# QUI PEUT LE DÉCLARER : l'écosystème lui-même, pour SA machine. Un runner de SITE ne le
|
|
# déclare jamais — il porte les plans des tenants en `role: tenant` précisément pour dire
|
|
# qu'il prépare leur terrain sans les piloter.
|
|
|
|
serveur_ops_tenant_utilisateur: "setops"
|
|
serveur_ops_tenant_racine: "/opt/setops"
|
|
|
|
# Le dossier du dépôt de CET écosystème chez le runner, cloné par `serveur_ops`
|
|
# (entrée `role: instance` de `serveur_ops_depots`). Par défaut : celui que le lien
|
|
# `instance` désigne déjà — le pilote et sa voûte ne peuvent pas viser deux écosystèmes.
|
|
serveur_ops_tenant_depot: "{{ serveur_ops_instance | default('') }}"
|
|
|
|
# --- LA VOÛTE DU TENANT ------------------------------------------------------
|
|
#
|
|
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas stocké : 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 — mesuré le 2026-08-24 sur la voûte du site, 776 octets
|
|
# en clair au lieu de 3465 chiffrés, sur une machine où ils n'avaient rien à faire.
|
|
serveur_ops_tenant_voute_source: ""
|
|
serveur_ops_tenant_voute_deposer: true
|
|
|
|
# LE DOSSIER D'INVENTAIRE SE DÉCOUVRE, il ne s'écrit pas. Le dépôt en connaît deux noms
|
|
# — `principal` et `production` — et l'ordre de préférence est celui de
|
|
# `inventory_rules.dossier_inventaire`. Écrire le nom en dur ici le ferait mentir pour
|
|
# l'écosystème qui emploie l'autre.
|
|
serveur_ops_tenant_inventaires_connus:
|
|
- principal
|
|
- production
|
|
|
|
# --- ARMER LE RUNNER : LA CLE DE SA VOUTE ------------------------------------
|
|
#
|
|
# UN RUNNER MAITRE DE SA VOUTE (decision de l'exploitant, 2026-08-28). Deposer le chiffre
|
|
# sans la cle laisse un runner qui calcule son inventaire et ne peut rien en faire : chaque
|
|
# role reclamant un secret echoue sur son assertion, et l'echec ne dit pas qu'il manque un
|
|
# FICHIER — seulement que les valeurs sont vides.
|
|
#
|
|
# `false` PAR DEFAUT, ET CE N'EST PAS DE LA PRUDENCE DECORATIVE. Armer est un ACTE, pas un
|
|
# reglage : c'est le moment ou un humain remet la cle, et c'est le seul geste que la
|
|
# reproduction exige de lui (cf. docs/filiation-emancipation.md). Un defaut a `true`
|
|
# armerait des machines sans que personne ne l'ait decide.
|
|
#
|
|
# LA SOURCE EST UN POINTEUR, JAMAIS UNE VALEUR : le chemin du fichier de mot de passe sur
|
|
# le poste de l'exploitant. Il ne vit dans aucun depot, et rien ici n'en lit le contenu.
|
|
#
|
|
# DESTINATION : `<racine>/.config/setops-vault-<depot-en-minuscules>`, la meme convention
|
|
# que `scripts/voutes.py` — le runner derive donc sa propre liste d'identites sans qu'on
|
|
# ait a la lui ecrire. Hors de tout depot git, en 0600.
|
|
serveur_ops_tenant_cle_deposer: false
|
|
serveur_ops_tenant_cle_source: ""
|
|
serveur_ops_tenant_cle_destination: >-
|
|
{{ serveur_ops_tenant_racine }}/.config/setops-vault-{{ serveur_ops_tenant_depot | lower }}
|
|
|
|
# --- Sonde de supervision -----------------------------------------------------------
|
|
# Le chemin ou le RUNNER lit la voute de son ecosysteme.
|
|
# LE DEPOT VIENT DU ROLE, PAS D'UNE SUPPOSITION : `serveur_ops_tenant_depot` designe
|
|
# deja le dossier clone sur le runner.
|
|
serveur_ops_tenant_sonde_depot: "{{ serveur_ops_tenant_depot }}"
|
|
serveur_ops_tenant_sonde_voute: >-
|
|
/opt/setops/{{ serveur_ops_tenant_sonde_depot }}/inventories/principal/group_vars/all/vault.yml
|
|
|
|
# --- L'IDENTITE SSH DU RUNNER, CONSERVEE DANS LA VOUTE (2026-09-30) ------------------------
|
|
#
|
|
# Le runner fabriquait sa paire de cles a sa naissance (`serveur_ops`). Chaque reconstruction
|
|
# de sa VM lui donnait donc une identite NEUVE, que le plan ne connaissait pas : les machines
|
|
# du locataire, clonees avec la cle DECLAREE (`ssh_baseline_cles_admin`), le refusaient
|
|
# toutes — « Permission denied (publickey) » sur les treize, a la reconstruction de
|
|
# Technolibre du 2026-09-30. Chez Chezlepro, la cle declaree etait deja celle d'un runner
|
|
# disparu.
|
|
#
|
|
# La cle privee vit donc dans la voute du locataire ; l'armement — le geste de l'humain —
|
|
# la remet au runner neuf, qui retrouve l'identite que la flotte attend. Vide = le runner
|
|
# garde la paire qu'il s'est fabriquee (et l'armement le dit).
|
|
serveur_ops_tenant_ssh_cle: "{{ vault_runner_cle_ssh | default('') }}"
|
|
serveur_ops_tenant_ssh_chemin: "{{ serveur_ops_tenant_racine }}/.ssh/id_ed25519"
|