feat(minio) — un compte de service par app consommatrice, borné à son bucket

« On peut adopter ce pattern à toutes les apps qui pourraient avoir besoin de MinIO, et ainsi modifier les app roles / app policy générique. » (fondateur, 26/07) Bonne nouvelle : les modules centraux n'ont PAS eu à changer. `kv_read_paths` existe déjà dans `app_policy` et fait exactement ça — l'ERP s'en sert pour lire les creds GCS de Longhorn. Le motif générique était donc à moitié construit ; il manquait la moitié MinIO. CE QUI EST AJOUTÉ : `minio/iac/consumers.tf` provisionne, pour chaque app déclarée dans `var.consumers`, une politique MinIO bornée à SON bucket (GetObject/PutObject/DeleteObject sur les objets, ListBucket sur le bucket seul — ni les autres buckets, ni l'administration), un compte de service, et écrit ses clés dans `kvv2/minio/<app>`. POURQUOI LES CLÉS VIVENT CHEZ MINIO ET PAS CHEZ L'APP : seul ce pipeline possède les identifiants ROOT. Si chaque app créait son propre compte de service, il faudrait donner ce root à chaque rôle CI — c'est-à-dire à tout le monde. Ici il ne sort jamais d'ici, et l'app ne reçoit qu'une clé qui ne peut rien lire d'autre que son bucket. Un compte de service qui fuite ne donne accès qu'aux objets qu'il gérait déjà. Ajouter une app = trois lignes déclaratives, documentées au README : son bucket dans values.yaml, son entrée dans `var.consumers`, son `kv_read_paths` au tfvars central. Aucun module à toucher. Le provider parle à `s3.arcodange.fr` — l'endpoint PUBLIC, parce que le runner CI n'est pas dans le LAN et que `.lab` ne s'y résout pas. C'est l'exposition HTTPS mergée ce matin qui rend ce plan applicable. ⚠ Erreur attrapée par le validateur, et corrigée : je relisais `kvv2/minio/config` alors que `local.config` de main.tf porte déjà les identifiants root — une lecture qui aurait créé une dépendance circulaire avec l'écriture faite par ce même plan. Vérifié : `tofu fmt` propre, `tofu validate` réussi (avec TERRAFORM_VAULT_AUTH_JWT posé — sans lui, le provider Vault échoue déjà sur main, ce n'est pas mon fait). Je n'ai lancé AUCUN apply : c'est le workflow qui le fera, et la revue t'appartient. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
2026-07-26 09:12:09 +02:00
parent f49a79e393
commit 4ca4a05370
5 changed files with 162 additions and 1 deletions
@@ -92,3 +92,41 @@ du fondateur (707 vidéos, ~2 ans), **la durée moyenne est de 53 secondes** et
 passe très largement. Si la limite se confirme, le plafond de 200 Mio annoncé
 côté API mérite d'être ramené sous celle du tunnel — mieux vaut refuser tôt, avec
 une phrase claire, qu'échouer au milieu d'un téléversement.
+
+
+## Donner à une app l'accès au stockage
+
+Le motif tient en **trois pièces**, et il est générique — ajouter une app ne
+demande aucune modification des modules Vault centraux.
+
+1. **Le bucket** — dans `values.yaml` de ce chart (bloc `buckets`), privé.
+2. **Le compte de service** — une entrée dans `var.consumers` de `iac/consumers.tf` :
+   ```hcl
+   { app = "mon-app", bucket = "mon-app-fichiers" }
+   ```
+   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`.
+
+Puis, côté app : une `VaultStaticSecret` sur `kvv2/minio/<app>` et l'injection
+des variables dans le Deployment.
+
+### 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
+son propre compte de service, il faudrait donner ce root à chaque rôle CI —
+c'est-à-dire à tout le monde. Ici il ne sort jamais, et l'app ne reçoit qu'une
+clé qui **ne peut rien lire d'autre que son bucket** : ni les autres buckets, ni
+l'administration. Un compte de service qui fuite ne donne accès qu'aux objets
+qu'il gérait déjà.
+
+### Rotation
+
+Détruire `random_password.app["<app>"]` et relancer le plan suffit : la clé
+change, `force_destroy = false` garde le compte et les objets déjà déposés
+conservent leur propriétaire.