Zone des instances de provider : celle du consommateur, plus de zone default fictive #2

New issue

Open

opened 2026-10-30 21:49:36 +00:00 by julien.blond · 0 comments

julien.blond commented

2026-10-30 21:49:36 +00:00

Owner

Constat

Un service qui ne déclare pas de zone, dont les providers livrés (providers/postgresql.loaf, providers/redis.loaf), est placé dans une zone default même quand les patrons de la stack ne la définissent pas : Flows.zone_of en fabrique une, de niveau default. Les flux, les règles de pare-feu et le placement (hamac.lp, zone_of/2) raisonnent alors sur une zone hors du treillis, alors que la spécification (manifest-spec.typ, « Zone et flux ») demande E042 pour une zone que les patrons ne définissent pas.

Exemple : dans examples/hr-stack, hr_api (zone rh) consomme une instance de postgresql, qui se retrouve en zone default.

Contrainte du treillis

Une instance de provider contient les données de son consommateur. Dans le modèle Bell-LaPadula, elle porte donc exactement l'étiquette du consommateur (même niveau, mêmes catégories) : plus sensible, le consommateur ne pourrait plus la lire (lecture vers le haut, E040) ; moins sensible, les données descendraient vers une zone moins protégée. Hamac crée une instance par consommation, ce qui permet de respecter cette règle.

Proposition

Défaut : l'instance d'un provider prend la zone de son consommateur (flux, pare-feu, placement). Pas de changement de vocabulaire.
Plus de zone fictive : un service sans zone n'est admis que si les patrons définissent une zone default (E042 sinon), comme le dit déjà la spécification.
Zone de données d'un patron (vocabulaire hamac 0.3.0) : data_zone name dans le bloc zone d'un patron, pour les architectures en tiers (base dans un segment de données séparé par sa propre frontière). La zone de données doit porter la même étiquette que la zone (règle ::error du vocabulaire).
Choix forcé par la stack (vocabulaire hamac 0.3.0) : zone name à côté de provider, limité à une zone de même étiquette que le consommateur.

Les points 1 et 2 ne changent pas le vocabulaire ; 3 et 4 font passer le module hamac en 0.3.0 et demandent la mise à jour de la spécification (« Patrons », « Stack », catalogue).

## Constat Un service qui ne déclare pas de zone, dont les providers livrés (`providers/postgresql.loaf`, `providers/redis.loaf`), est placé dans une zone `default` même quand les patrons de la stack ne la définissent pas : `Flows.zone_of` en fabrique une, de niveau `default`. Les flux, les règles de pare-feu et le placement (`hamac.lp`, `zone_of/2`) raisonnent alors sur une zone hors du treillis, alors que la spécification (`manifest-spec.typ`, « Zone et flux ») demande E042 pour une zone que les patrons ne définissent pas. Exemple : dans `examples/hr-stack`, `hr_api` (zone `rh`) consomme une instance de `postgresql`, qui se retrouve en zone `default`. ## Contrainte du treillis Une instance de provider contient les données de son consommateur. Dans le modèle Bell-LaPadula, elle porte donc exactement l'étiquette du consommateur (même niveau, mêmes catégories) : plus sensible, le consommateur ne pourrait plus la lire (lecture vers le haut, E040) ; moins sensible, les données descendraient vers une zone moins protégée. Hamac crée une instance par consommation, ce qui permet de respecter cette règle. ## Proposition 1. **Défaut** : l'instance d'un provider prend la zone de son consommateur (flux, pare-feu, placement). Pas de changement de vocabulaire. 2. **Plus de zone fictive** : un service sans zone n'est admis que si les patrons définissent une zone `default` (E042 sinon), comme le dit déjà la spécification. 3. **Zone de données d'un patron** (vocabulaire `hamac` 0.3.0) : `data_zone name` dans le bloc `zone` d'un patron, pour les architectures en tiers (base dans un segment de données séparé par sa propre frontière). La zone de données doit porter la même étiquette que la zone (règle `::error` du vocabulaire). 4. **Choix forcé par la stack** (vocabulaire `hamac` 0.3.0) : `zone name` à côté de `provider`, limité à une zone de même étiquette que le consommateur. Les points 1 et 2 ne changent pas le vocabulaire ; 3 et 4 font passer le module `hamac` en 0.3.0 et demandent la mise à jour de la spécification (« Patrons », « Stack », catalogue).

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#2

No description provided.

Rows
Columns