Daniel Allaire
c79aae200d
Le sysadmin ne pouvait atteindre AUCUNE interface web de la flotte qu'il administre : le pare-feu de l'hyperviseur n'autorisait le 443 de l'edge que depuis `+t17-flotte`. Le reseau d'administration est dans `t17-admin`. L'exploitant arrive par un TROISIEME chemin que rien ne declarait : ni `externe` (Internet, affaire de la frontiere), ni `flotte` (le tenant). Le runbook de reprise supposait pourtant qu'on ouvre Keycloak dans un navigateur. `admin` devient un pair declarable — les reseaux de `nftables_admin_ssh`, deja source unique de la garde anti-lockout. `serveur_nginx` le declare pour son 443. L'edge SEUL : ouvrir les services en direct elargirait la surface pour rien. Erreur de methode de ma part : mon premier test utilisait `/dev/tcp` et concluait « atteignable ». Faux — la frontiere repond au SYN a la place de la cible. Je l'avais consigne le matin meme. `make ca-racine` / `make ca-empreinte` : l'hote de l'AC est derive du groupe `serveur_step_ca`, et la sortie insiste sur la comparaison d'empreinte. La racine est un certificat PUBLIC — hors voute, dans le magasin de confiance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
55 lines
2.6 KiB
YAML
55 lines
2.6 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:
|
|
- sens: ingress
|
|
port: 80
|
|
protocole: tcp
|
|
pair: externe
|
|
chiffrement: clair
|
|
raison: "HTTP entrant — redirection permanente vers HTTPS."
|
|
- sens: ingress
|
|
port: 443
|
|
protocole: tcp
|
|
pair: externe
|
|
chiffrement: tls-requis
|
|
raison: "HTTPS entrant — services exposés (terminaison TLS à l'edge)."
|
|
# 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."
|