Ses machines n existaient plus depuis le 2026-09-06 (D-83), mais son plan restait sur disque : la federation lui reservait l index 29 et quatre machines du site lui ouvraient SSH, apt, DNS et HTTPS. Les commentaires et documents vivants gardent leur lecon sans le nommer ; les archives restent telles quelles. Pas encore sur le reseau : les regles regenerees attendent le runner du site. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
133 lines
7.3 KiB
Markdown
133 lines
7.3 KiB
Markdown
> **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`](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, 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**.
|