# `minio_app` — déclarer ses buckets depuis SON dépôt Chacun son périmètre : les buckets d'une application appartiennent au dépôt de cette application. Ce module **standardise** la déclaration, il ne la détient pas — sans lui, chaque bucket de chaque app deviendrait une PR sur `tools`. ## Usage Dans l'`iac/` de l'app : ```hcl # Le provisionneur MinIO : des droits d'administration MINIMAUX (créer un # bucket, un compte de service, une politique), jamais le root — qui, lui, ne # sort pas du pipeline `minio`. data "vault_kv_secret_v2" "minio_provisioner" { mount = "kvv2" name = "minio/provisioner" } provider "minio" { minio_server = "s3.arcodange.fr" minio_user = data.vault_kv_secret_v2.minio_provisioner.data["MINIO_ACCESS_KEY"] minio_password = data.vault_kv_secret_v2.minio_provisioner.data["MINIO_SECRET_KEY"] minio_ssl = true } module "stockage" { source = "git::ssh://git@192.168.1.202:2222/arcodange-org/tools.git//minio/iac/modules/minio_app?depth=1&ref=main" app = "mon-app" # = le nom de son rôle Vault buckets = ["mon-app-fichiers"] providers = { minio = minio } } ``` Puis, côté chart : une `VaultStaticSecret` sur `kvv2/minio/` et l'injection des variables dans le Deployment. ## Ce que le module garantit - les buckets sont **privés** — l'accès passe par des URL présignées ; - le compte de service ne peut **rien** toucher d'autre que ces buckets-là ; - ses clés vont dans `kvv2/minio/`, que le module Vault central autorise déjà l'app à lire (règle **inconditionnelle** : le chemin porte le nom de l'app, donc il ne peut exposer que ses propres clés). ## Plusieurs buckets C'est le cas courant : deux contenus aux **cycles de vie différents** méritent deux buckets. Il suffit de les lister — le compte de service existant gagne l'accès, **sans nouvelle clé**. ## Ce que le module ne fait PAS Il ne pose ni quota, ni règle de cycle de vie, ni versioning : ces choix appartiennent à l'app et varient d'un bucket à l'autre. À ajouter le jour où un besoin réel apparaît, pas avant.