Set-OPS-Public/docs/remise-au-client.md

Pour qui : l'hébergeur, le jour où il remet un écosystème à celui qui en est le propriétaire. À lire avant de fabriquer le paquet, pas pendant.

Remettre un écosystème à son propriétaire

1. Le problème que ce document ferme

La livraison se terminait par une phrase : « tes clés te seront remises séparément ». Ce qui se passait ensuite n'était écrit nulle part — ni ce qu'on remet, ni dans quel ordre, ni ce qu'on garde. Le geste qui donne le contrôle d'une organisation était le seul geste lourd du dépôt sans procédure, sans outil et sans garde.

Et il portait une faute silencieuse : les clés vivent toutes dans le même dossier (~/.config/setops-vault-*). Remettre « les clés » d'un revers de main, c'est remettre celles du site et celles des autres locataires. Personne ne s'en apercevrait — ni celui qui donne, ni celui qui reçoit.

2. Les deux temps, et pourquoi ils ne se confondent pas

Temps 1 — l'identité. Le client reçoit de quoi gouverner ses gens tout de suite. Temps 2 — la machine. À une date convenue, il reçoit le pouvoir sur ses serveurs, et l'hébergeur le perd.

Ce découpage n'est pas une précaution d'hébergeur : c'est ce qui rend les deux gestes honnêtes.

	Temps 1	Temps 2
Ce qui passe	la clé de sa voûte, sa voûte chiffrée, la racine de son AC	sa clé SSH entre, celle de l'hébergeur sort, la voûte change de mot de passe, les secrets tournent
Ce que le client peut	créer, retirer, habiliter des personnes — sans nous	tout, y compris se passer de nous
Ce que l'hébergeur garde	l'accès machine, parce qu'il exploite encore	rien qui ne lui soit redonné
Quand	le jour de la livraison	à l'échéance inscrite (30 jours par défaut)

Le second temps applique à une livraison ce que migration-tenant.md §6 étape 8 applique déjà à un départ : révoquer, pas transmettre. Sans lui, l'hébergeur garde à vie l'accès aux secrets d'un client qui se croit chez lui — et aucune procédure ne rattrape ça après coup.

3. Temps 1 — le paquet

make ca-racine                      # la racine de SON AC, et son empreinte
make ca-empreinte                   # la même, lue SUR l'AC : le témoin à comparer

make remise-recenser                # ce qui partirait, sans rien écrire
make remise-paquet VERS=/media/…/CLE
make remise-inscrire RECU_PAR="Prénom Nom" COURRIEL="…"

Lance remise-paquet toi-même, dans ton terminal : gpg demande une phrase de passe, et elle ne doit passer ni par un journal, ni par le contexte d'un assistant.

L'outil refuse quatre choses, et chacune ferme une faute réelle :

• une destination dans l'infrastructure — le dépôt de sauvegarde est chiffré par un mot de passe qui vit dans la voûte que ce paquet ouvre ; l'y déposer ferait un coffre dont la clé est à l'intérieur ;
• écraser un paquet existant — c'est peut-être celui qu'on vient de vérifier ;
• partir sans la racine de l'AC — sans elle, le client apprend à cliquer sur « continuer quand même », ce qui vaut pire que pas de TLS du tout ;
• un paquet qu'il n'arrive pas à rouvrir — il est alors supprimé. Un paquet de remise qu'on ne sait pas rouvrir donne le sentiment d'avoir remis.

Il n'emporte que l'écosystème monté : la clé du site et celles des autres locataires vivent dans le même dossier, et c'est une seule ligne de code qui les en écarte (remise.py:_cle_de_voute). Il n'affiche jamais le contenu d'un secret — noms, tailles, empreintes SHA256, rien d'autre.

Deux gestes restent, et ils n'ont pas d'outil : transmettre la phrase de passe par un autre canal que le support, et transmettre l'empreinte de l'AC de la même façon. Séparés, le support et la phrase ne valent rien l'un sans l'autre.

4. Temps 2 — le re-clé

L'ordre ne se permute pas. Retirer sa propre clé avant que celle du client soit posée ferme l'écosystème à tout le monde, et le seul moyen de le réparer est justement celui qu'on vient de retirer.

1. La clé du client entre — son entrée dans ssh_baseline_cles_admin, etat: present.
2. Celle de l'hébergeur sort — etat: absent sur son entrée. On ne la supprime pas du plan : une entrée retirée n'est plus appliquée, donc la clé resterait sur les machines. absent la fait retirer.
3. Déployer, pour que le plan devienne l'état des machines.
4. La voûte change de mot de passe — ansible-vault rekey, la nouvelle clé étant choisie par le client. Le mot de passe de l'hébergeur ne se communique pas.
5. Les secrets applicatifs tournent — voute.py saisir --remplacer, sans écho, puis déploiement.
6. Estampiller : make remise-recleer CONFIRMER=true.

remise-recleer mesure avant d'estampiller, et refuse si l'un des trois faits manque : une clé présente, une clé révoquée, une clé de voûte différente de celle remise au temps 1. Un registre qui dirait « révoqué » pendant que le plan garde la clé de l'hébergeur serait le seul mensonge que ce fichier puisse porter sans que personne ne s'en aperçoive — parce qu'il flatte tout le monde.

5. Le registre — remise.yml chez le locataire

Généré, versionné, dans le dépôt du locataire, à côté de parente.yml : de qui il descend d'un côté, à qui il appartient de l'autre.

Il porte l'organisation, la date du temps 1, qui a remis, qui a reçu, les empreintes SHA256 des pièces remises, l'échéance du temps 2 et son constat. Aucun secret, par construction : une empreinte prouve qu'on a remis ce fichier-là sans rien révéler de son contenu.

Il déclare enfin le responsable désigné. D-18 décide depuis longtemps que chaque locataire en a un ; migration-tenant.md §9 laissait ouverte la question « où est-il déclaré ? ». La réponse est ici, et elle est la seule qui ne devine rien : c'est la personne qui reçoit.

6. La garde

P80 lit les registres de tous les écosystèmes et refuse trois états :

• un registre incomplet — remis à personne, ou sans échéance ;
• un temps 2 échu et non fait : l'hébergeur garde l'accès machine d'un client qui se croit chez lui, et le silence le laisserait devenir un état de fait ;
• un temps 2 déclaré fait pendant que le plan ne révoque aucune clé.

Elle ne juge pas un écosystème sans registre : tous ne sont pas remis, et beaucoup ne le seront jamais — le lab, patient 0, l'écosystème de l'hébergeur lui-même.

7. Ce que cette procédure ne couvre pas

• Ce que le client fait de son paquet. Une clé remise sur un support qu'il laisse dans un tiroir déverrouillé n'est plus notre affaire, et le LISEZ-MOI le lui dit.
• La rotation des secrets applicatifs, qui reste un geste humain : voute.py ne génère pas les valeurs, il les reçoit sans écho. Un script qui engendrerait et écrirait tout seul connaîtrait ce qu'il écrit.
• La preuve que l'hébergeur ne peut plus entrer. Le plan déclare la révocation et le déploiement l'applique ; le vérifier depuis l'extérieur demande d'essayer d'entrer, donc une machine vivante. C'est le même partage que partout ici : le dépôt prouve ce qu'il a demandé, make emancipation-prouver prouve ce qui tient.