Set-OPS-Public/docs/depots-prives-conception.md

Dépôts privés sur la forge du site — conception du chantier

Pour qui : le mainteneur qui décide de ce chantier puis le conduit, et quiconque se demande pourquoi un runner ne lit que ses propres dépôts.

Préparé le 2026-10-11. Rien n'est changé tant que les décisions D1 à D3 ne sont pas prises.

1. Le constat

Sur la forge du site, l'organisation genome porte cinq dépôts, tous publics :

Dépôt	Contenu	Qui en a besoin
set-ops-public	le moteur	tous les runners
set-ops-modeles	les modèles génériques	le runner du site
site-chezlepro	la carte de la fabric, le plan du site	le runner du site
ops-chezlepro	le plan, l'inventaire et la face de Chezlepro	son runner, le runner du site
ops-technolibre	le plan, l'inventaire et la face de Technolibre	son runner, le runner du site

Mesuré le 2026-10-11 : depuis le runner de Technolibre, git ls-remote sans identifiant lit la tête de ops-chezlepro (b4fbd85) et de site-chezlepro (51dae24). Chaque locataire peut donc lire le plan de l'autre, et la carte du site. Aucun n'en a besoin : chaque runner de locataire ne clone que le moteur et son propre dépôt ; ce que le site lui donne arrive par la fiche déposée dans son dépôt.

D'où ça vient : le 2026-09-12, à la première reconstruction du site, les dépôts créés privés ont cassé le clonage anonyme des runners. Ils sont passés publics, avec l'argument que seuls ceux qui ont franchi la frontière joignent la forge (scripts/forge_amorcer.py). Les autres locataires en font partie.

2. La cible

• Publics : set-ops-public et set-ops-modeles. Ils sont génériques, identiques pour tous.
• Privés : site-chezlepro et chaque ops-<locataire>.
• Le runner du site lit et pousse tous les dépôts avec sa clé, déjà enregistrée comme clé de déploiement en écriture par genome_pousser.yml. Mesuré le 2026-10-11 : il lit les cinq dépôts en SSH, avec une vérification stricte de la clé d'hôte. Rien à créer pour lui.
• Le runner d'un locataire lit son seul dépôt, avec une clé de déploiement en lecture seule : la clé publique de son runner, déjà déclarée au plan (ssh_baseline_cles_admin) et dont la privée lui est remise à l'armement depuis sa voûte (vault_runner_cle_ssh).
• Aucun secret ne change de main. Le locataire publie la clé publique de son runner dans sa face réseau ; le site l'enregistre sur le dépôt de ce locataire, avec ses propres identifiants d'administration de la forge (vault_forgejo_admin, déjà dans sa voûte).

3. Le nœud : l'insémination

Le site amorce le runner d'un locataire avant que celui-ci ait reçu sa clé stable (elle arrive à l'armement, geste humain, après). Pendant l'insémination, le rôle serveur_ops clone pourtant le dépôt du locataire : avec un dépôt privé, ce clonage échoue. Même chose au premier déploiement du runner du site, dont la clé est neuve.

Remède proposé : le colis. Quand un runner ne peut pas encore lire un dépôt privé, le contrôleur qui joue serveur_ops (le runner du site pendant l'insémination, le poste ailleurs) lui apporte ce dépôt en git bundle. Le mécanisme existe déjà : genome_colis.py porte le génome du poste au runner du site. Le runner clone le colis, puis pointe origin vers l'URL SSH de la forge. Ses tirages suivants passent par sa clé, une fois armé.

4. Les décisions à prendre

D1 — Comment le runner d'un locataire lit-il son dépôt ?

• Clé de déploiement en SSH (recommandé). Le runner continue de tirer lui-même ; il garde son autonomie (émancipation, make lancé sur le runner, garde verifier_genome_a_jour). Coût : un flux nouveau, du runner de chaque locataire vers la forge du site, en SSH.
• Colis seulement. Aucun flux nouveau, aucune clé de déploiement pour les locataires : le contrôleur apporte toujours le dépôt. Mais le runner ne tire plus son dépôt lui-même, et sa garde de génome n'a plus de forge à laquelle se comparer.

D2 — Sur quelle écoute SSH ?

• Le sshd de la machine, port 22 (recommandé pour commencer). Le runner du site et le poste l'utilisent déjà pour pousser ; l'utilisateur git y est contraint par la forge. Le flux n'ouvre que les adresses des runners de locataires, pas leurs supernets.
• Le serveur SSH intégré de Forgejo, sur un port dédié. Il n'expose pas le sshd de la machine, mais sa cohabitation avec le sshd existant reste à éprouver avant de s'y fier.

D3 — La preuve. Ce chantier touche l'insémination : je propose de le prouver par une reconstruction complète de Technolibre (raser, créer, inséminer, armer, monter), dépôts privés, avant de reprendre le lot 3b.

5. Ce qui change dans le code

Pièce	Changement
serveur_ops_depots	un drapeau prive: true sur les dépôts instance, tenant et hebergeur
roles/serveur_ops	URL SSH et clé du runner pour les dépôts privés ; colis du contrôleur quand le runner ne peut pas encore les lire ; clé d'hôte de la forge épinglée
contexte.py (face)	la face publie la clé publique de lecture du runner (genome.cle_lecture)
contexte.py (fiche)	la fiche du site publie la clé d'hôte SSH de sa forge, que le runner du locataire épingle
nouvelle cible forge-cles	le site enregistre, d'après les faces, la clé de lecture de chaque locataire sur son dépôt, et retire celles qui ne sont plus publiées
forge_amorcer.py	crée les dépôts privés comme privés
flux	serveur_forge_site : entrée SSH depuis les runners des locataires hébergés (paire nouvelle, résolue depuis les faces) ; serveur_ops : sortie correspondante
genome_etat.yml	lit la forge par SSH ou authentifié : l'API anonyme répondrait 404 pour un dépôt privé
sonde-genome-servi	compte les dépôts de l'organisation authentifié, sinon elle ne verrait plus que les deux publics

Inchangés : sonde-genome-a-jour (son repère ne compare que set-ops-public), le poste (il pousse déjà en SSH), la console (etat_forge lit origin, qui deviendra l'URL SSH).

6. Les preuves à écrire

• Hors ligne (make prouver) : chaque dépôt instance, tenant ou hebergeur est déclaré privé ; chaque face publie une clé de lecture, et cette clé est dans ssh_baseline_cles_admin.
• Sur le terrain (make forge-etancheite), avec témoins :
  • sans identifiant, un dépôt privé refuse et un dépôt public répond ;
  • le runner d'un locataire lit son dépôt et ne lit pas celui de l'autre ;
  • les clés de déploiement de chaque dépôt sont exactement : runner du site en écriture, runner du locataire en lecture.
• Par reconstruction : D3.

7. L'ordre de bascule

Chaque étape se vérifie avant la suivante, et la bascule se défait d'un appel par dépôt (repasser public).

1. Éprouver sur la forge du site, sans rien basculer : enregistrer la clé de lecture du runner de Technolibre sur ops-technolibre, ouvrir le flux pour ce seul runner, et mesurer qu'il lit son dépôt en SSH.
2. Construire le code et les preuves (§5, §6) ; make verifier.
3. Déployer sans basculer : flux et frontière (make frontiere-appliquer CONFIRMER=true, lancé par Daniel), clés de déploiement, remotes SSH sur les trois runners. Les dépôts sont encore publics : chaque runner doit déjà tirer en SSH.
4. Basculer site-chezlepro, ops-chezlepro et ops-technolibre en privé. Mesurer avec make forge-etancheite, puis la veille des trois consoles.
5. Prouver par la reconstruction de Technolibre (D3).
6. Reprendre le lot 3b : les demandes vivent alors dans le dépôt de chaque locataire, lisibles par lui et par le site seulement.