Un mot manquait au vocabulaire des flux. Le runner de SITE declarait son API Proxmox en
`externe`, qui se rend par !SETOPS_INTERNES — or les hyperviseurs SONT en RFC 1918 : la
regle les aurait exclus tout en ayant l'air d'ouvrir le flux. D'ou `fabric`.
Deux flux manquaient :
- serveur_cache_site n'avait aucun egress : la chaine de caches se terminait sur un
cache vide, et ca ne se serait vu qu'au premier apt update d'un ecosysteme neuf ;
- serveur_ops_site n'avait que l'API : le shell des noeuds et l'API de la frontiere
sont deux autres pouvoirs, declares a part.
Le devis ignorait les machines du site — dans aucun plan de tenant, donc invisibles a sa
boucle, zero regle rendue SANS RIEN SIGNALER. Il emet desormais SETOPS_SITE,
SETOPS_FABRIC, SETOPS_ADMIN_SITE et un alias par role, sur opt2 (arrivee reelle du
trafic) et lan pour le SSH, plus le NAT sortant du site.
Le socle s'applique au site : site_inventaire.py range ses machines dans serveur_debian.
Patient 0 ne declare plus serveur_ops_site ni serveur_cache_site : il est un tenant
comme les autres, c'est meme tout ce qu'il prouve. Inventaire regenere.
42 preuves vertes. Devis : 26 regles a creer, 5 a retirer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
40 lines
1.6 KiB
YAML
40 lines
1.6 KiB
YAML
---
|
|
# Flux réseau du runner de SITE. Voir docs/flux-conception.md.
|
|
#
|
|
# Les flux du POUVOIR DE MATERIALISER : API de l'hyperviseur, shell des noeuds, API de
|
|
# la frontiere. Chacun est un pouvoir distinct, donc declare a part. Ce rôle n'entre JAMAIS
|
|
# chez un tenant — c'est `serveur_ops` qui configure les machines, une fois qu'elles
|
|
# existent.
|
|
flux:
|
|
- sens: egress
|
|
port: 8006
|
|
protocole: tcp
|
|
pair: fabric
|
|
chiffrement: tls-requis
|
|
raison: >-
|
|
API de l'hyperviseur : créer, cloner et détruire les VM de la fabric. Le seul flux
|
|
par lequel un écosystème peut en matérialiser un autre.
|
|
|
|
# SSH VERS LES HYPERVISEURS. L'API Proxmox ne fait pas tout : deplacer un disque,
|
|
# lire une configuration reseau, poser un pont — cela passe par le shell du nœud.
|
|
# Le declarer separement de l'API rend visible que ce sont DEUX pouvoirs distincts.
|
|
- sens: egress
|
|
port: 22
|
|
protocole: tcp
|
|
pair: fabric
|
|
chiffrement: ssh
|
|
raison: >-
|
|
Shell des hyperviseurs : ce que l'API ne couvre pas — configuration reseau, ponts,
|
|
deplacement de disques. Un pouvoir distinct de l'API, donc declare a part.
|
|
|
|
# L'API DE LA FRONTIERE. Le runner du site pose les regles et les alias qui laissent
|
|
# passer les flux d'un tenant : sans ce flux, il prepare un terrain injoignable.
|
|
- sens: egress
|
|
port: 443
|
|
protocole: tcp
|
|
pair: fabric
|
|
chiffrement: tls-requis
|
|
raison: >-
|
|
API de la frontiere OPNsense : poser les alias et les regles qui ouvrent les flux
|
|
du tenant qu'on materialise. Preparer le terrain sans cela laisserait un terrain
|
|
injoignable.
|