Set-OPS-Public/docs/acces-administration.md
Daniel Allaire d90513ca91 acces d'administration : un tunnel WireGuard nominatif, pas le runner en rebond
Le runner detient la voute et les cles SSH : en faire la porte des humains reunirait deux
pouvoirs que le depot separe. Instance `admins` a cote du tunnel site-a-site, un pair par
personne et par appareil, cles publiques seules au plan. Le reseau du tunnel est un reseau
d'administration : pare-feux d'hote, contrat des locataires et regles de bordure en derivent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-17 14:42:48 -04:00

71 lines
3.8 KiB
Markdown

# L'accès d'administration — un tunnel nominatif
> **Pour qui :** celui qui administre le site et ses écosystèmes, et celui qui se demande
> par où un humain entre, avec quelle clé, et ce qu'il peut atteindre une fois entré.
>
> Décidé le 2026-09-17, en réponse à une question : *le runner ne devrait-il pas être le
> rebond SSH des admins ?*
## Pourquoi pas le runner
Le runner du site détient **la clé de la voûte du site** et les clés SSH qui configurent
toutes les machines. En faire la porte des humains réunirait deux pouvoirs que tout le reste
du dépôt sépare :
- une session humaine compromise (un agent SSH transféré de trop) deviendrait le **plan de
contrôle** — pas seulement un rebond ;
- il **ne doit jamais entrer chez un locataire** (charte des responsabilités) ; en faire le
passage obligé des admins créerait ce chemin en fait ;
- il est **reconstructible par le code**, et c'est sa vertu. Un point d'entrée doit survivre à
la reconstruction de ce qu'il sert ;
- « qui est entré » et « qu'est-ce qui a été déployé » cesseraient de se raconter séparément.
## Ce qui a été construit
Un **second** tunnel WireGuard sur la frontière — l'instance `admins`, port 51821 — à côté du
tunnel site-à-site vers le site pair (instance `chezlePro`, port 51820), jamais mêlé à lui.
| | |
|---|---|
| déclaré | `SITE-<nom>/plan/10-intrants.yml`, clé `acces_admin_vpn` |
| réconcilié | `scripts/vpn_admin.py` (`make vpn-admin-plan`, `make vpn-admin-appliquer`) |
| réseau | `10.37.29.0/24`, la frontière en `.1` |
| un pair | **une personne ET un appareil** — révoquer l'appareil perdu ne coupe pas les autres |
| clés | seule la clé **publique** est au plan ; la privée ne quitte jamais l'appareil |
**Le réseau du tunnel est un réseau d'administration, et tout en dérive** : les pare-feux des
machines du site (`resoudre_flux`), le contrat vers les locataires (`site_intrants`, donc les
pare-feux de leurs machines) et les règles de la frontière (`devis_opnsense`). Rien à recopier
— une liste recopiée prend toujours du retard sur celle qu'elle suit.
## Ajouter un appareil
```bash
python3 scripts/vpn_admin.py pair-nouveau --nom prenom-appareil # tire la paire de clés
# coller le bloc `pairs:` rendu dans SITE-<nom>/plan/10-intrants.yml
make vpn-admin-plan # lire ce qui changerait
CONFIRMER=true make vpn-admin-appliquer # poser le pair
python3 scripts/vpn_admin.py config --nom prenom-appareil # la config de l'appareil
make flux && make deployer-groupe GROUPE=serveur_durci # les pare-feux des machines
```
La clé privée ne s'affiche **qu'une fois**, au moment où elle est tirée : elle appartient à
l'appareil. Perdue, on en tire une autre ; l'ancienne se révoque par `etat: absent`.
## Retirer un accès
`etat: absent` sur le pair, puis `CONFIRMER=true make vpn-admin-appliquer`. Le script retire
aussi tout pair **attaché à notre instance que le plan ne déclare plus** : un accès qui
survivrait à la décision de le retirer est exactement ce qu'on ne veut pas.
## Ce que le tunnel donne, et ce qu'il ne donne pas
`AllowedIPs` est **dérivé** de la carte : zones du site, fabric, lien de transit et supernets
des locataires. Ce que la frontière laisse ensuite passer reste décidé par les flux déclarés —
SSH partout, et les consoles d'administration (Grafana, Icinga Web, la forge, le runner).
**Le seul port ouvert sur l'Internet par cette voie est le 51821/udp**, vers l'adresse publique
de la frontière. Tout le reste voyage dans le tunnel.
**Ce qui n'est pas fait** : l'enregistrement des sessions (un rebond dédié le permettrait, pas
un tunnel), et la double authentification — la possession de l'appareil fait foi.