refactor(vault) — lire ses identifiants MinIO devient une propriété de la plateforme

Retour fondateur : « je pensais que tools#21 contribuerait à app_policy pour une
policy kvv2/minio/<app name> ». Il a raison, et mon choix initial était le plus
faible des deux.

Mon objection — ne donner le droit qu'aux apps qui en ont besoin — ne tient pas
à l'examen : la règle porte le NOM de l'app, donc elle ne peut jamais exposer
que ses propres clés. Il n'y a aucun privilège à préserver. Une app qui ne
stocke rien lit un chemin qui n'existe pas : une règle inerte, pas un droit.

Son argument, lui, porte : savoir lire ses propres identifiants de stockage est
une propriété de la PLATEFORME, pas une exception par application. Et
`kv_read_paths` est documenté comme la trappe pour un secret appartenant à une
AUTRE app (les creds GCS de Longhorn pour l'ERP) — y ranger un motif standard
l'aurait rendu invisible et aurait obligé à le redéclarer à chaque app.

La règle passe donc dans `app_policy`, en prod ET pour chaque instance non-prod
(symétrie stricte), sur deux chemins : le document `kvv2/data/minio/<app>` et
ses descendants.

Un cran plus loin que la demande : la règle est INCONDITIONNELLE, sans drapeau.
Conséquence — déclarer un consommateur MinIO se fait désormais à UN SEUL
endroit, `var.consumers` du pipeline minio. Aucune synchronisation à tenir entre
deux fichiers, donc rien à oublier. Le `kv_read_paths` que j'avais ajouté à
kadans est retiré : il faisait double emploi.

tofu fmt propre · tofu validate réussi sur hashicorp-vault/iac.

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

minio/README.md

@@ -106,16 +106,22 @@ demande aucune modification des modules Vault centraux.
    ```
    Le plan crée une politique MinIO **bornée à ce bucket**, un compte de service,
    et écrit ses clés dans `kvv2/minio/mon-app`.
-3. **La lecture** — dans `hashicorp-vault/iac/terraform.tfvars`, l'app déclare :
-   ```hcl
-   { name = "mon-app", kv_read_paths = ["kvv2/data/minio/mon-app"] }
-   ```
-   `kv_read_paths` **existait déjà** (l'ERP s'en sert pour les creds GCS de
-   Longhorn) : rien à changer dans `app_policy` ni `app_roles`.
+3. **La lecture** — *rien à faire.* Le module central `app_policy` accorde à
+   **toute** app la lecture de `kvv2/data/minio/<son nom>`. La règle est
+   inconditionnelle et c'est voulu : le chemin porte le nom de l'app, donc elle
+   ne peut jamais exposer que ses propres clés ; une app qui ne stocke rien lit
+   un chemin qui n'existe pas.
 
 Puis, côté app : une `VaultStaticSecret` sur `kvv2/minio/<app>` et l'injection
 des variables dans le Deployment.
 
+> **Un seul endroit déclare un consommateur** : `var.consumers`, ici. Rien à
+> synchroniser dans le tfvars central, donc rien à oublier. C'est la raison pour
+> laquelle la règle vit dans le module plutôt que dans `kv_read_paths` — cette
+> dernière est la trappe pour lire un secret appartenant à une AUTRE app (les
+> creds GCS de Longhorn pour l'ERP) ; y ranger un motif standard le rendrait
+> invisible et obligerait à le redéclarer à chaque fois.
+
 ### Pourquoi les clés vivent ICI et pas chez l'app
 
 Seul ce pipeline possède les identifiants **root** de MinIO. Si chaque app créait