refactor(minio) — lever la restriction « un seul bucket par app »

« Pourquoi sommes-nous restreints sur les buckets ? » (fondateur, 26/07) — parce
que JE l'avais décidé, pour rendre tout dérivable d'un seul nom. Rien ne
l'imposait, et la restriction aurait mordu au pas suivant : l'ADR-018 de Kadans
prévoit DEUX paliers de transfert (aperçu 240p régénérable, travail 360p à
garder), donc deux cycles de vie, donc potentiellement deux buckets aux
politiques de purge différentes.

Chaque bucket déclare désormais son app (`app: kadans`). C'est toujours la SEULE
déclaration, au même endroit — mais le nom du bucket redevient libre, et
`kadans-videos` retrouve un nom qui dit ce qu'il contient.

Le compte de service devient par APP et non par bucket : une seule clé, autorisée
sur tous ses buckets et eux seuls. Ajouter un bucket à une app existante ne crée
donc aucune nouvelle clé — le compte existant gagne l'accès. Le secret porte
`MINIO_BUCKETS` (tous) en plus de `MINIO_BUCKET` (le premier), pour que l'app
n'ait pas à les redéclarer de son côté.

Un bucket sans `app:` est ignoré plutôt que de faire échouer le plan : il n'aura
simplement pas de compte de service, ce qui se voit immédiatement et ne casse
rien d'existant.

Vérifié sur le VRAI fichier, pas en théorie : le groupement rend bien
{"kadans" = ["kadans-videos"]}, et avec un second bucket de la même app,
{"kadans" = ["kadans-videos", "kadans-apercus"]} — le cas ADR-018 exact.
tofu fmt propre, tofu validate réussi.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA

minio/README.md

@@ -25,7 +25,7 @@ application vivent avec cette application.
 | Ressources | requests 512 Mi / 100 m · limit 2 Gi — la limite protège les voisins de `tools`, pas MinIO |
 | API S3 | `s3.arcodange.lab` (interne) **et `s3.arcodange.fr`** (public, tunnel Cloudflare → entrypoint `web` + crowdsec) — voir « Pourquoi une exposition publique » |
 | Console | `minio.arcodange.lab` (Traefik) |
-| Buckets | **un par app, nommé comme elle** (`kadans`…), tous **privés** — l'accès passe par des URL signées (ADR-0002 du dossier produit). Le bucket est la SEULE déclaration : compte de service et droits Vault en découlent |
+| Buckets | **privés**, chacun déclarant son app (`app:`) — l'accès passe par des URL signées (ADR-0002 du dossier produit). Le bucket est la SEULE déclaration : compte de service et droits Vault en découlent. Une app peut en avoir plusieurs |
 | Identifiants | **jamais dans le dépôt** : `iac/` les génère dans Vault (`kvv2/minio/config`), le Vault Secrets Operator les matérialise en secret `minio-config`, le chart les lit via `existingSecret` |
 
 Le ServiceAccount du pod est nommé `minio` (et non le `minio-sa` par défaut du
@@ -96,20 +96,21 @@ une phrase claire, qu'échouer au milieu d'un téléversement.
 
 ## Donner à une app l'accès au stockage
 
-**Une seule chose à faire** : ajouter son bucket dans `values.yaml`, **nommé
-comme l'app**.
+**Une seule chose à faire** : déclarer son bucket dans `values.yaml`, en disant
+à quelle app il appartient.
 
 ```yaml
 buckets:
-  - name: mon-app
-    policy: none   # privé : l'accès passe par des URL signées
+  - name: mon-app-fichiers
+    app: mon-app          # ← la seule déclaration
+    policy: none          # privé : l'accès passe par des URL signées
 ```
 
-Tout le reste en découle, sans autre déclaration nulle part :
+Tout le reste en découle, sans rien écrire ailleurs :
 
-- `iac/consumers.tf` **lit ce même fichier** et crée un compte de service
-  `mon-app-app`, borné à ce seul bucket, dont les clés atterrissent dans
-  `kvv2/minio/mon-app` ;
+- `iac/consumers.tf` **lit ce même fichier**, groupe les buckets par app, et crée
+  **un** compte de service `mon-app-app` autorisé sur **tous ses buckets et eux
+  seuls**. Ses clés atterrissent dans `kvv2/minio/mon-app` ;
 - le module Vault central `app_policy` accorde **déjà** à toute app la lecture de
   `kvv2/data/minio/<son nom>` — inconditionnellement, parce que le chemin porte
   le nom de l'app et ne peut donc jamais exposer que ses propres clés. Une app
@@ -117,6 +118,16 @@ Tout le reste en découle, sans autre déclaration nulle part :
 
 Côté app, il reste à écrire une `VaultStaticSecret` sur `kvv2/minio/<app>` et à
 injecter les variables dans son Deployment (voir `kadans-api` pour l'exemple).
+Le secret porte `MINIO_ENDPOINT`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`,
+`MINIO_BUCKET` (le premier) et `MINIO_BUCKETS` (tous, séparés par des virgules).
+
+### Plusieurs buckets pour une même app
+
+C'est prévu, et c'est le cas courant : deux contenus aux **cycles de vie
+différents** méritent deux buckets aux politiques de purge différentes. Kadans y
+viendra avec les deux paliers de l'ADR-018 — l'aperçu 240p, régénérable, et le
+rendu de travail 360p, à garder. Il suffit d'une seconde entrée avec le même
+`app:` ; le compte de service existant gagne l'accès, sans nouvelle clé.
 
 > **Il n'y a volontairement AUCUNE liste de consommateurs.** Une liste de plus
 > serait une liste à tenir synchronisée avec les buckets — donc une liste à