Daniel Allaire
5d7d2a8918
Le nom par defaut etait fixe : le second export butait sur le premier. Il porte maintenant la date (l heure en plus le meme jour) ; un export de voutes identiques a la derniere archive n ecrit rien. Le LISEZ-MOI et la doc restaurent la plus recente archive. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
130 lines
6.5 KiB
Markdown
130 lines
6.5 KiB
Markdown
> **Pour qui :** l'exploitant, le jour où il réalise que 1 644 octets valent toute
|
|
> l'installation. À faire une fois, puis à refaire quand une clé change.
|
|
|
|
# Sortir les clés du poste
|
|
|
|
## Ce qui est en jeu
|
|
|
|
Le **code** de Set-OPS est répliqué **deux fois** : `eregion` et la forge du site. Les
|
|
**voûtes chiffrées**, elles, n'y sont **pas** — elles sont gitignorées. Chacune vit sur
|
|
ce poste et sur le runner de son écosystème, qui en reçoit une copie chiffrée par
|
|
`serveur_ops_tenant`. *(Corrigé le 2026-09-28 : cette page les disait sur les forges.)*
|
|
|
|
**Elles sortent donc aussi, dans une archive à part** (`make voutes-exporter VERS=<support>`,
|
|
`scripts/exporter_voutes.py`) : déjà chiffrées par `ansible-vault`, elles n'ont pas besoin
|
|
d'une seconde couche ; le script refuse tout fichier dont l'en-tête n'est pas
|
|
`$ANSIBLE_VAULT`, garde le chemin de chaque voûte (elles s'appellent presque toutes
|
|
`vault.yml`) et relit l'archive empreinte par empreinte. Restauration :
|
|
`tar -xf "$(ls -t setops-voutes-*.tar | head -1)" -C <dossier des dépôts>` (la plus récente).
|
|
Chaque export porte sa date (`setops-voutes-<date>-<poste>.tar`, l'heure en plus au second
|
|
export du jour) et n'écrit rien si les voûtes n'ont pas changé depuis la dernière archive.
|
|
**À refaire après toute écriture
|
|
dans une voûte**, comme les clés après toute voûte nouvelle.
|
|
|
|
> **Ce chiffre était trois, et il a baissé sans que rien ne le signale.** Un coffre répliqué deux fois reste
|
|
> solide — mais c'est la **redondance du génome** qui a diminué, pas le chiffrement, et
|
|
> c'est exactement ce que la page *Filiation, signatures & témoins* appelle la vraie mesure
|
|
> de résistance d'une lignée : combien de copies **vivantes**, sur combien de machines
|
|
> distinctes.
|
|
|
|
Les **clés** qui l'ouvrent vivent dans neuf fichiers de ce poste — 1 644 octets — sans
|
|
aucune copie ailleurs. S'y ajoutent les clés SSH par lesquelles on entre sur les
|
|
hyperviseurs, la frontière et chaque machine.
|
|
|
|
Ce qu'on perd avec le poste, par ordre de gravité :
|
|
|
|
| Ce qui disparaît | Conséquence |
|
|
|---|---|
|
|
| Le poste seul | Les mots de passe restic restent lisibles sur les machines vivantes (`/etc/setops/restic.pass`) — récupérable, mais douloureux, et plus aucun déploiement possible entre-temps |
|
|
| Le poste **et** une machine | L'état de cette machine devient illisible |
|
|
| Le poste **et** le site | Terminal |
|
|
|
|
## La manœuvre
|
|
|
|
```bash
|
|
make cles-recenser # voir ce qui sortirait, sans rien écrire
|
|
make cles-exporter VERS=/media/…/CLE # sortir, chiffrer, RELIRE
|
|
```
|
|
|
|
**Lance-la toi-même**, dans ton terminal. `gpg` demande une phrase de passe : elle ne doit
|
|
passer ni par un journal, ni par le contexte d'un assistant. C'est la seule façon de
|
|
s'en assurer.
|
|
|
|
L'outil refuse trois choses, et chacune a été éprouvée en la faisant échouer :
|
|
|
|
- une destination **dans** l'infrastructure — ces clés ouvrent les sauvegardes ; les y
|
|
ranger ferait un coffre dont la clé est à l'intérieur ;
|
|
- **écraser** une archive existante — elle est peut-être la seule ;
|
|
- une archive qu'il **n'arrive pas à rouvrir** — elle est alors supprimée. Une sauvegarde
|
|
de clés qu'on ne sait pas ouvrir est pire que rien : elle donne le sentiment d'être
|
|
protégé.
|
|
|
|
Il ne montre jamais le contenu des clés — seulement leur nom, leur taille et leur
|
|
empreinte. De quoi vérifier sans divulguer.
|
|
|
|
## Les deux gestes qui restent, et qui ne sont pas facultatifs
|
|
|
|
**1. La phrase de passe va ailleurs que le support.** Séparés, ils ne valent rien l'un
|
|
sans l'autre ; ensemble, ils valent l'installation. Un papier dans un autre lieu, ou un
|
|
gestionnaire de mots de passe qui n'est pas sur ce poste.
|
|
|
|
**2. Une seconde copie, dans un autre lieu physique.** Un support unique dans un tiroir
|
|
unique, c'est le problème qu'on vient de fermer, déplacé de quelques mètres.
|
|
|
|
## Les rouvrir — la moitié qui compte
|
|
|
|
Le jour où l'on s'en sert, **le poste est mort**. Le dépôt Set-OPS est répliqué trois
|
|
fois, mais le *cloner* demande la clé SSH… qui est dans l'archive qu'on essaie d'ouvrir.
|
|
Une procédure rangée dans le dépôt serait donc inaccessible exactement quand elle sert.
|
|
|
|
La clé se suffit donc à elle-même. À côté de l'archive :
|
|
|
|
```
|
|
setops-cles-<date>-<poste>.tar.gpg les clés, chiffrées (une archive datée par export)
|
|
restaurer_cles.py le script, autonome
|
|
LISEZ-MOI-RESTAURATION.txt le mode d'emploi, et les commandes manuelles
|
|
```
|
|
|
|
> **Une clé faite avant cette version ne porte pas les compagnons.**
|
|
> `make cles-compagnons VERS=/media/…/CLE` les y dépose **sans refaire l'archive** : ni
|
|
> phrase de passe redemandée, ni risque d'écraser ce qui est déjà vérifié.
|
|
|
|
Sur la machine neuve, il ne faut que `gpg`, `python3` et la phrase de passe :
|
|
|
|
```bash
|
|
A="$(ls -t setops-cles-*.tar* | head -1)" # la plus récente
|
|
python3 restaurer_cles.py "$A" --lister # voir sans rien écrire
|
|
python3 restaurer_cles.py "$A" # remettre en place
|
|
```
|
|
|
|
Le script remet chaque fichier à sa place selon son nom, et **repose les droits à 0600**.
|
|
Ce n'est pas cosmétique : `ssh` refuse une clé privée que d'autres peuvent lire, et son
|
|
message ne dit pas qu'il s'agit d'un droit — une archive extraite depuis un support FAT
|
|
arrive systématiquement dans cet état. Il **refuse** aussi d'écraser une clé déjà là :
|
|
lancé par erreur sur un poste qui fonctionne, il ne détruit rien.
|
|
|
|
Si même ce script refuse de tourner, le LISEZ-MOI porte les commandes manuelles — `gpg`,
|
|
`tar`, `chmod`. **Les deux chemins ont été éprouvés** le 2026-09-05 : export, poste vidé,
|
|
restauration depuis la clé seule, empreintes comparées — identiques, 4 sur 4, droits
|
|
700/600.
|
|
|
|
## L'éprouver pendant qu'on a encore le choix
|
|
|
|
```bash
|
|
make cles-restaurer ARCHIVE=/media/…/setops-cles-*.tar.gpg
|
|
```
|
|
|
|
Il refusera, puisque les clés sont déjà en place — et ce refus est en soi la preuve que
|
|
l'archive s'ouvre et que la phrase de passe est la bonne. C'est le test le moins cher
|
|
qui existe, et il vaut d'être refait après chaque changement de clé.
|
|
|
|
## Quand recommencer
|
|
|
|
Quand une voûte est créée ou sa clé changée (`voutes.py`), quand une paire SSH de runner
|
|
est refaite, et à l'arrivée d'un écosystème. `make cles-recenser` dit en une seconde si
|
|
l'archive rangée est encore complète : compare le nombre de fichiers et les empreintes.
|
|
|
|
## Ce que ça ne couvre pas
|
|
|
|
La **phrase de passe** elle-même : si elle est perdue, l'archive est du bruit. C'est le
|
|
prix du chiffrement, et c'est pour ça que le geste 1 n'est pas décoratif.
|