Consigne les décisions prises en branchant Kadans sur MinIO (26/07). Trois questions indépendantes : qui déclare les buckets d'une app, qui détient les identifiants capables de les créer, et comment l'app lit les siens.
La décision de fond
Chacun son périmètre (fondateur) : une application déclare ses buckets depuis son propre dépôt. tools fournit le serveur, un module de standardisation et un compte de provisionnement — pas la liste.
Une première version faisait tout porter par l'infra partagée. À ce rythme, chaque bucket de chaque app devient une PR sur le dépôt commun, qui devient le goulot de tout le monde.
Ce que l'ADR consigne aussi
Trois identités, trois portées — root (le seul pipeline minio), provisionneur (les rôles CI ; crée des buckets, ne lit aucun objet), compte de service (le pod ; ses buckets seulement).
La lecture est inconditionnelle, pas déclarée par app : le chemin porte le nom de l'application, donc la règle ne peut exposer que ses propres clés.
Les octets ne passent pas par l'API — et les trois conséquences que ça impose : endpoint public (contenu mixte + résolution hors LAN), CORS aux origines exactes, et pas de basic-auth sur l'ingress S3 (une requête S3 porte sa propre signature ; un défi HTTP Basic casserait un PUT présigné).
Un bucket par cycle de vie, pas par application.
Alternatives écartées
Six, avec leur motif — dont deux que j'avais moi-même proposées et qui étaient plus faibles : faire porter la liste par tools, et déclarer la lecture Vault app par app via kv_read_paths (qui est la trappe pour lire le secret d'une autre app, pas un motif standard).
Deux limites assumées, écrites noir sur blanc
Le provisionneur est un secret partagé entre rôles CI : sa compromission permet de créer des buckets, pas de lire des objets. La suite serait une identité de provisionnement par application, que MinIO ne borne pas simplement aujourd'hui.
Et les noms d'actions d'administration MinIO n'ont pas été éprouvés contre le serveur au moment d'écrire — le premier apply les confirmera ou les corrigera.
Accompagne tools#21 (module + provisionneur), kadans#168 (Kadans déclare ses buckets) et kadans-api#23 (les URL présignées).
Consigne les décisions prises en branchant Kadans sur MinIO (26/07). Trois questions **indépendantes** : qui déclare les buckets d'une app, qui détient les identifiants capables de les créer, et comment l'app lit les siens.
## La décision de fond
**Chacun son périmètre** (fondateur) : une application déclare ses buckets **depuis son propre dépôt**. `tools` fournit le serveur, un module de standardisation et un compte de provisionnement — **pas la liste**.
Une première version faisait tout porter par l'infra partagée. À ce rythme, chaque bucket de chaque app devient une PR sur le dépôt commun, qui devient le goulot de tout le monde.
## Ce que l'ADR consigne aussi
- **Trois identités, trois portées** — root (le seul pipeline `minio`), provisionneur (les rôles CI ; crée des buckets, **ne lit aucun objet**), compte de service (le pod ; ses buckets seulement).
- **La lecture est inconditionnelle**, pas déclarée par app : le chemin porte le nom de l'application, donc la règle ne peut exposer que ses propres clés.
- **Les octets ne passent pas par l'API** — et les trois conséquences que ça impose : endpoint **public** (contenu mixte + résolution hors LAN), CORS aux **origines exactes**, et **pas de basic-auth** sur l'ingress S3 (une requête S3 porte sa propre signature ; un défi HTTP Basic casserait un PUT présigné).
- **Un bucket par cycle de vie**, pas par application.
## Alternatives écartées
Six, avec leur motif — dont **deux que j'avais moi-même proposées** et qui étaient plus faibles : faire porter la liste par `tools`, et déclarer la lecture Vault app par app via `kv_read_paths` (qui est la trappe pour lire le secret d'une **autre** app, pas un motif standard).
## Deux limites assumées, écrites noir sur blanc
Le **provisionneur est un secret partagé** entre rôles CI : sa compromission permet de créer des buckets, pas de lire des objets. La suite serait une identité de provisionnement par application, que MinIO ne borne pas simplement aujourd'hui.
Et les **noms d'actions d'administration MinIO n'ont pas été éprouvés** contre le serveur au moment d'écrire — le premier `apply` les confirmera ou les corrigera.
> Accompagne **tools#21** (module + provisionneur), **kadans#168** (Kadans déclare ses buckets) et **kadans-api#23** (les URL présignées).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Trois questions indépendantes, tranchées lors du branchement de Kadans sur
MinIO (2026-07-26) : qui déclare les buckets d'une app, qui détient les
identifiants capables de les créer, et comment l'app lit les siens.
La décision de fond est du fondateur : CHACUN SON PÉRIMÈTRE. Une application
déclare ses buckets depuis son propre dépôt ; `tools` fournit le serveur, un
module de standardisation et un compte de provisionnement — pas la liste. Une
première version faisait tout porter par l'infra partagée : à ce rythme, chaque
bucket de chaque app devenait une PR sur le dépôt commun.
L'ADR consigne aussi les trois identités et leurs portées (root / provisionneur
/ compte de service), pourquoi la lecture des identifiants est une propriété
inconditionnelle de la plateforme plutôt qu'une déclaration par app, et pourquoi
les octets ne transitent pas par l'API — avec les conséquences que ça impose
(endpoint public, CORS aux origines exactes, pas de basic-auth sur l'ingress S3).
Les alternatives écartées sont listées avec leur motif, dont deux que j'avais
moi-même proposées et qui étaient plus faibles.
Deux limites assumées y figurent : le provisionneur est un secret PARTAGÉ entre
rôles CI (sa compromission permet de créer des buckets, pas de lire des objets),
et les noms d'actions d'administration MinIO n'ont pas été éprouvés contre le
serveur au moment d'écrire.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Consigne les décisions prises en branchant Kadans sur MinIO (26/07). Trois questions indépendantes : qui déclare les buckets d'une app, qui détient les identifiants capables de les créer, et comment l'app lit les siens.
La décision de fond
Chacun son périmètre (fondateur) : une application déclare ses buckets depuis son propre dépôt.
toolsfournit le serveur, un module de standardisation et un compte de provisionnement — pas la liste.Une première version faisait tout porter par l'infra partagée. À ce rythme, chaque bucket de chaque app devient une PR sur le dépôt commun, qui devient le goulot de tout le monde.
Ce que l'ADR consigne aussi
minio), provisionneur (les rôles CI ; crée des buckets, ne lit aucun objet), compte de service (le pod ; ses buckets seulement).Alternatives écartées
Six, avec leur motif — dont deux que j'avais moi-même proposées et qui étaient plus faibles : faire porter la liste par
tools, et déclarer la lecture Vault app par app viakv_read_paths(qui est la trappe pour lire le secret d'une autre app, pas un motif standard).Deux limites assumées, écrites noir sur blanc
Le provisionneur est un secret partagé entre rôles CI : sa compromission permet de créer des buckets, pas de lire des objets. La suite serait une identité de provisionnement par application, que MinIO ne borne pas simplement aujourd'hui.
Et les noms d'actions d'administration MinIO n'ont pas été éprouvés contre le serveur au moment d'écrire — le premier
applyles confirmera ou les corrigera.🤖 Generated with Claude Code
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
b92da95701toaabedb0f3f