Plan : la bordure (nœuds, points d'entrée, filtrage, enclaves en push) #5

New issue

Open

opened 2026-10-31 09:14:57 +00:00 by julien.blond · 0 comments

julien.blond commented

2026-10-31 09:14:57 +00:00

Owner

Constat

La spécification décrit l'exposition d'un service (exposure) et la vérification de ses routes en bordure, mais hamac plan ne montre pas la bordure : ni les nœuds qui portent les points d'entrée publics, ni les points d'entrée eux-mêmes, ni le filtrage entre la bordure et les zones. On ne voit donc pas comment un service d'une zone restreinte devient joignable depuis internet.

Principe retenu (zero trust) : la zone dit où un service tourne et quelles données il détient, et règle les flux de service à service ; l'exposition est une porte d'entrée en bordure, où chaque requête est autorisée route par route selon l'identité et les droits de l'utilisateur. Une requête venue d'internet n'est jamais un flux de zone à zone.

Proposition

Nœuds de bordure, hors de toute zone, seuls à avoir une adresse publique ; proposés par le planificateur dès qu'un service est exposé (deux pour la disponibilité).
Points d'entrée : un par exposition (nom public, port, TLS, service et port visés, zone, conditions des routes), affichés par le plan et écrits dans l'infrastructure produite (par exemple ingress "si.example.org", ocp_si, 8000.).
Filtrage : la bordure n'ouvre vers chaque zone que les ports des services exposés ; aucune zone n'ouvre de connexion vers la bordure (réponses seulement).
Tunnel chiffré de la bordure vers les zones quand elles sont sur des sites différents.
Enclaves : une exposition d'un service d'enclave doit être de mode push. La bordure authentifie et autorise l'émetteur, répond elle-même par un accusé de réception (202 Accepted), puis pousse les données à travers la diode ; rien ne sort de l'enclave. Sinon, erreur (nouveau code).
Ce que voit la bordure : en terminant TLS pour vérifier les routes, elle voit en clair tout le trafic des services qu'elle expose.
- (a) par défaut, une bordure reçoit le plancher d'assurance de la zone la plus sensible qu'elle expose ;
- (b) si les machines de bordure n'ont pas ce niveau, le planificateur propose des bordures séparées par niveau de sensibilité ;
- (c) pour un service, tls passthrough : la bordure aiguille sans déchiffrer (SNI), et l'autorisation des routes se fait dans la zone du service.

À faire avant d'implémenter : confronter à l'état de l'art

La conception doit être revue contre les pratiques et références actuelles, entre autres :

accès zero trust et proxys d'identité : BeyondCorp, Identity-Aware Proxy, Cloudflare Access / Tunnel, Pomerium, Teleport ;
autorisation externe en bordure : Envoy ext_authz, OPA, et Biscuit (lots 3 à 5 du projet) avec Sozu ;
identité des services et chiffrement de bout en bout : mTLS, SPIFFE/SPIRE, maillage de services (terminaison TLS au plus près du service) ;
Kubernetes Gateway API (séparation des rôles entre infrastructure, exploitation et application) ;
recommandations de l'ANSSI sur les passerelles d'interconnexion, l'exposition sur internet et les diodes ;
le modèle Bell-LaPadula appliqué à un composant qui voit plusieurs niveaux (passerelle multi-niveaux), pour justifier (a), (b) ou (c).

Hors périmètre

La simulation (hamac simulate) d'une bordure réelle devant les zones, à faire avec le provider Sozu.

## Constat La spécification décrit l'exposition d'un service (`exposure`) et la vérification de ses routes en bordure, mais `hamac plan` ne montre pas la bordure : ni les nœuds qui portent les points d'entrée publics, ni les points d'entrée eux-mêmes, ni le filtrage entre la bordure et les zones. On ne voit donc pas comment un service d'une zone restreinte devient joignable depuis internet. Principe retenu (*zero trust*) : la zone dit où un service tourne et quelles données il détient, et règle les flux de service à service ; l'exposition est une porte d'entrée en bordure, où chaque requête est autorisée route par route selon l'identité et les droits de l'utilisateur. Une requête venue d'internet n'est jamais un flux de zone à zone. ## Proposition 1. **Nœuds de bordure**, hors de toute zone, seuls à avoir une adresse publique ; proposés par le planificateur dès qu'un service est exposé (deux pour la disponibilité). 2. **Points d'entrée** : un par exposition (nom public, port, TLS, service et port visés, zone, conditions des routes), affichés par le plan et écrits dans l'infrastructure produite (par exemple `ingress "si.example.org", ocp_si, 8000.`). 3. **Filtrage** : la bordure n'ouvre vers chaque zone que les ports des services exposés ; aucune zone n'ouvre de connexion vers la bordure (réponses seulement). 4. **Tunnel** chiffré de la bordure vers les zones quand elles sont sur des sites différents. 5. **Enclaves** : une exposition d'un service d'enclave doit être de mode `push`. La bordure authentifie et autorise l'émetteur, répond elle-même par un accusé de réception (`202 Accepted`), puis pousse les données à travers la diode ; rien ne sort de l'enclave. Sinon, erreur (nouveau code). 6. **Ce que voit la bordure** : en terminant TLS pour vérifier les routes, elle voit en clair tout le trafic des services qu'elle expose. - (a) par défaut, une bordure reçoit le plancher d'assurance de la zone la plus sensible qu'elle expose ; - (b) si les machines de bordure n'ont pas ce niveau, le planificateur propose des bordures séparées par niveau de sensibilité ; - (c) pour un service, `tls passthrough` : la bordure aiguille sans déchiffrer (SNI), et l'autorisation des routes se fait dans la zone du service. ## À faire avant d'implémenter : confronter à l'état de l'art La conception doit être revue contre les pratiques et références actuelles, entre autres : - accès *zero trust* et proxys d'identité : BeyondCorp, Identity-Aware Proxy, Cloudflare Access / Tunnel, Pomerium, Teleport ; - autorisation externe en bordure : Envoy `ext_authz`, OPA, et Biscuit (lots 3 à 5 du projet) avec Sozu ; - identité des services et chiffrement de bout en bout : mTLS, SPIFFE/SPIRE, maillage de services (terminaison TLS au plus près du service) ; - Kubernetes Gateway API (séparation des rôles entre infrastructure, exploitation et application) ; - recommandations de l'ANSSI sur les passerelles d'interconnexion, l'exposition sur internet et les diodes ; - le modèle Bell-LaPadula appliqué à un composant qui voit plusieurs niveaux (passerelle multi-niveaux), pour justifier (a), (b) ou (c). ## Hors périmètre La simulation (`hamac simulate`) d'une bordure réelle devant les zones, à faire avec le provider Sozu.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

OSS/hamac#5

No description provided.

Rows
Columns