Daniel Allaire
1493059271
L edge n expose qu a sa zone d administration (plus de pair externe) ; le public passera par le web frontal. Le devis Proxmox recoit les flux externe depuis +t<i>-internet (RFC 1918 exclus en nomatch) et depuis l admin quand le poste en est client. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
54 lines
2.8 KiB
YAML
54 lines
2.8 KiB
YAML
---
|
|
# Flux réseau de l'edge nginx (propriété du rôle). Voir docs/flux-conception.md.
|
|
# Cas « edge » : ingress depuis l'extérieur (frontière publique) + egress vers les backends,
|
|
# ces derniers dérivés des `expose:` des applications (pair: expositions).
|
|
flux:
|
|
# PAS D'`externe` (2026-09-29). L'edge expose les interfaces web de l'ecosysteme a SA
|
|
# zone d'administration, et a personne d'autre ; ce qui sera publie sur l'Internet le sera
|
|
# par le WEB FRONTAL. Les deux entrees `externe` qui figuraient ici posaient a la frontiere
|
|
# « WAN, n'importe qui -> edge 80/443 » chez chaque locataire — une ouverture que rien ne
|
|
# devait porter (le pare-feu Proxmox de l'edge la rejetait deja).
|
|
- sens: ingress
|
|
port: 80
|
|
protocole: tcp
|
|
pair: admin
|
|
chiffrement: clair
|
|
raison: "HTTP depuis le reseau d'administration — redirection permanente vers HTTPS."
|
|
# L'edge sert AUSSI les hôtes du tenant : les FQDN publiés (`expose`) n'existent qu'ici,
|
|
# et un service interne qui doit joindre un autre service passe par son nom publié — pas
|
|
# par une adresse. C'est le cas de toute découverte OIDC : oauth2-proxy interroge
|
|
# `https://auth.<domaine>/.well-known/…`, servi par l'edge.
|
|
#
|
|
# Sans cette déclaration, le flux existait d'un seul côté : `serveur_oauth2_proxy`
|
|
# déclarait `egress 443 → edge`, la matrice était satisfaite (nginx déclare bien 443),
|
|
# mais le devis est-ouest SAUTE `pair: externe` — il relève de la frontière. Aucune règle
|
|
# d'hyperviseur n'était donc émise, et oauth2-proxy expirait sur `10.27.16.11:443`.
|
|
# Constaté le 2026-08-07.
|
|
- sens: ingress
|
|
port: 443
|
|
protocole: tcp
|
|
pair: flotte
|
|
chiffrement: tls-requis
|
|
raison: "HTTPS depuis le tenant : les FQDN publiés vivent à l'edge (découverte OIDC, appels inter-services par nom)."
|
|
- sens: egress
|
|
port: derive
|
|
protocole: tcp
|
|
pair: expositions
|
|
chiffrement: tls-cible
|
|
raison: "Proxy vers les backends exposés (host:port dérivés des expose ; TLS interne = roadmap edge→backends)."
|
|
|
|
# L'EXPLOITANT administre les services par leur interface web, et il n'est ni un
|
|
# hote du tenant ni un visiteur d'Internet : il arrive du reseau d'administration,
|
|
# un troisieme chemin que rien ne declarait. Resultat au 2026-08-07 : le sysadmin
|
|
# ne pouvait atteindre AUCUNE interface web de la flotte qu'il administre — ce qui
|
|
# contredisait le runbook de reprise (docs/autorisation.md §6), lequel suppose
|
|
# qu'on ouvre Keycloak dans un navigateur.
|
|
#
|
|
# L'edge SEUL recoit ce droit : c'est le point d'entree unique, et ouvrir les
|
|
# services en direct elargirait la surface sans rien gagner.
|
|
- sens: ingress
|
|
port: 443
|
|
protocole: tcp
|
|
pair: admin
|
|
chiffrement: tls-requis
|
|
raison: "HTTPS depuis le reseau d'administration : l'exploitant administre les services par leur interface web, servie par l'edge."
|