doc(pgbouncer) — la version mesurée n'était pas la déployée, et DISCARD ALL a un prix

Trois corrections au raisonnement, toutes issues d'une contre-vérification qui
a refait les mesures au lieu de les relire.

1. La mesure invoquait pgbouncer 1.25.2 « la version en prod ». Le pod tourne
   1.23.1 (ghcr.io/icoretech/pgbouncer-docker:1.23.1-fixed, chart 2.3.1, up
   133 j). Tout a été rejoué sur 1.23.1 avec la ConfigMap extraite du cluster :
   les conclusions tiennent, mais la preuve invoquée portait sur autre chose.

2. La portée de la fuite était laissée en suspens, donc lue au pire. Les pools
   sont partitionnés par (base, utilisateur) — 210 pools, aucun mélange. Le
   seul héritier possible du SET ROLE de kadans-api est kadans-api. Défaut
   d'hygiène, pas brèche inter-applications. Le dire baisse la gravité, et
   c'est plus utile qu'une alarme vague.

3. ⚠ Le point manquant, et c'est l'inverse de ce qu'on croyait : DISCARD ALL
   rend la protection de db.go STRICTEMENT PLUS FRAGILE. Aujourd'hui
   (DEALLOCATE ALL) elle survivrait à un passage en transaction pooling ;
   après, non — le SET ROLE d'AfterConnect est effacé entre deux transactions,
   et poserRoleProprietaire ne peut pas le voir puisqu'il relit current_role à
   l'ouverture. Sans danger tant que pool_mode reste `session` (le défaut, non
   déclaré) — mais c'est précisément le genre de trappe qui se referme des mois
   plus tard sur quelqu'un qui optimise. Les quatre combinaisons sont mesurées
   et écrites au-dessus de la ligne.

La ceinture Vault couvre ce cas (un défaut de rôle survit à DISCARD ALL), mais
seulement au renouvellement des baux. D'où l'avertissement explicite.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GdUCA5Uz8QyMwa2P4Pg2hK

.gitea/workflows/crowdsec.yaml

@@ -2,12 +2,15 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Crowdsec
 
-on: #[push,pull_request]
+# À LA DEMANDE, et seulement à la demande — comme minio.yaml : auth Vault par
+# flux OIDC (un humain doit ouvrir un lien) et apply `auto_approve` contre la prod.
+#
+# Note : les triggers `push`/`pull_request` retirés ici étaient de toute façon
+# INERTES — ils passaient par une ancre YAML (`&`/`*`), que le parseur
+# d'événements de Gitea ne résout pas (vécu sur arcodange/kadans, issues 113
+# → 117). Ce workflow ne partait déjà qu'à la main ; c'est maintenant écrit.
+on:
   workflow_dispatch: {}
-  push: &crowdsecPaths
-    paths:
-      - 'crowdsec/**/*.tf'
-  pull_request: *crowdsecPaths
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:

.gitea/workflows/helmcharts.yaml

@@ -2,14 +2,32 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Helm Charts
 
-on: [push,pull_request,workflow_dispatch]
-  # push: &helmPaths # turns out gitea don't handle well the paths filter
-  #   paths:
-  #     - '*/\.yaml'
-  #     - '*/\.tpl'
-  #     - '*/NOTES.txt'
-  #     - '*/\.helmignore'
-  # pull_request: *helmPaths
+# Celui-ci travaille SEUL (pas d'auth Vault, pas d'apply) : on le garde
+# automatique. Mais `push` sur TOUTES les branches + `pull_request` faisait
+# partir DEUX runs pour le même commit dès qu'une branche avait une PR.
+#
+# Même forme que la CI de kadans : la branche est couverte par `pull_request`,
+# `main` par le `push` d'après-merge. Un run par événement, aucun angle mort.
+#
+# (Le filtre de chemins d'origine, resté en commentaire des années sous un
+# « gitea don't handle well the paths filter », n'était probablement pas en
+# cause : il passait par une ancre YAML, et le parseur d'événements de Gitea ne
+# les résout pas — issues 113 → 117 de kadans. Le job `filter-chart` fait déjà
+# ce tri au niveau job, donc on n'y retouche pas.)
+#
+# ⚠ Chaque clé porte un CORPS explicite : un `pull_request:` nu (valeur nulle)
+# n'est pas une forme éprouvée sur ce Gitea, et son mode d'échec est le
+# silencieux — aucun run, aucune erreur. On copie la forme qui tourne (kadans
+# ci.yml), listes dupliquées à la main, sans ancre.
+on:
+  workflow_dispatch: {}
+  push:
+    branches: [main]
+    paths-ignore:
+      - '**.md'
+  pull_request:
+    paths-ignore:
+      - '**.md'
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:

.gitea/workflows/minio.yaml

@@ -1,20 +1,19 @@
 ---
 name: MinIO
 
-# ⚠ Triggers écrits EN TOUTES LETTRES, sans ancre YAML (`&`/`*`).
-# Une ancre dans un trigger Gitea Actions fait taire push ET pull_request —
-# en silence, aucun run, aucune erreur (vécu sur arcodange/kadans, issues 113
-# → 117). Les autres workflows de ce repo utilisent encore des ancres : à
-# vérifier séparément, c'est probablement pour ça qu'ils ne partent qu'à la
-# main (workflow_dispatch).
+# À LA DEMANDE, et seulement à la demande. Deux raisons, chacune suffisante :
+#
+#   1. Ce workflow ne PEUT PAS aboutir sans un humain : l'auth Vault passe par
+#      un flux OIDC dont le lien doit être ouvert dans un navigateur connecté.
+#      Déclenché tout seul, il occupe un runner jusqu'à son timeout — et retarde
+#      les runs que quelqu'un attend vraiment.
+#   2. Il fait `terraform apply` en `auto_approve` CONTRE LA PROD. Se déclencher
+#      sur le push d'une branche, c'est appliquer du code que personne n'a relu.
+#
+# Au passage : `push` (toutes branches) + `pull_request` faisait partir DEUX runs
+# par commit d'une branche en PR — le même SHA, deux fois.
 on:
   workflow_dispatch: {}
-  push:
-    paths:
-      - 'minio/**/*.tf'
-  pull_request:
-    paths:
-      - 'minio/**/*.tf'
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:

.gitea/workflows/plausible.yaml

@@ -2,12 +2,14 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Plausible
 
-on: #[push,pull_request]
+# À LA DEMANDE, et seulement à la demande — comme minio.yaml : auth Vault par
+# flux OIDC (un humain doit ouvrir un lien) et apply `auto_approve` contre la prod.
+#
+# Note : les triggers `push`/`pull_request` retirés ici étaient de toute façon
+# INERTES (ancre YAML non résolue par Gitea, issues 113 → 117 de kadans). Ce
+# workflow ne partait déjà qu'à la main ; c'est maintenant écrit.
+on:
   workflow_dispatch: {}
-  push: &plausiblePaths
-    paths:
-      - 'plausible/**/*.tf'
-  pull_request: *plausiblePaths
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:

.gitea/workflows/vault.yaml

@@ -2,23 +2,18 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Hashicorp Vault
 
-# ⚠ Triggers écrits EN TOUTES LETTRES, sans ancre YAML (`&`/`*`) : une ancre
-# dans un trigger Gitea Actions fait taire push ET pull_request, en silence
-# (vécu sur arcodange/kadans, issues 113 → 117) — c'est probablement pourquoi
-# ce workflow ne partait qu'à la main.
-# Et `*.tfvars` compte AUTANT que `*.tf` : la liste des applications (donc les
-# rôles gitea_cicd_<app>) vit dans terraform.tfvars — l'oublier, c'est ajouter
-# une app sans jamais créer son rôle.
+# À LA DEMANDE, et seulement à la demande — comme minio.yaml, et pour les mêmes
+# deux raisons : l'auth Vault exige qu'un humain ouvre un lien OIDC (sans lui, le
+# run squatte un runner jusqu'au timeout), et l'apply se fait en `auto_approve`
+# contre la prod.
+#
+# ⚠ Ce qui change AUSSI de nature : `hashicorp-vault/**/*.tfvars` compte autant
+# que `*.tf` — la liste des applications (donc les rôles gitea_cicd_<app>) vit
+# dans terraform.tfvars. Ce n'est plus un filtre de chemins mais ça reste vrai
+# du POURQUOI on relance : ajouter une app au tfvars sans relancer ce workflow,
+# c'est une app sans rôle CI.
 on:
   workflow_dispatch: {}
-  push:
-    paths:
-      - 'hashicorp-vault/**/*.tf'
-      - 'hashicorp-vault/**/*.tfvars'
-  pull_request:
-    paths:
-      - 'hashicorp-vault/**/*.tf'
-      - 'hashicorp-vault/**/*.tfvars'
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:

hashicorp-vault/iac/modules/app_policy/main.tf

@@ -36,6 +36,13 @@ data "vault_policy_document" "ops" {
     path         = "kvv1/google/credentials"
     capabilities = ["read"]
   }
+  # Provisionneur MinIO — l'app crée ses buckets depuis son dépôt sans le root.
+  # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
+  rule {
+    path         = "kvv2/data/minio/provisioner"
+    capabilities = ["read"]
+  }
+
   # read cloudflare related secrets
   rule {
     path         = "kvv1/cloudflare/${local.name}*"
@@ -178,6 +185,19 @@ data "vault_policy_document" "app" {
     path         = "postgres/creds/${local.name}*"
     capabilities = ["read"]
   }
+  # Ses identifiants MinIO. INCONDITIONNEL : le chemin porte le nom de l'app,
+  # donc la règle ne peut exposer que ses propres clés ; une app sans stockage
+  # lit un chemin qui n'existe pas.
+  # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
+  rule {
+    path         = "kvv2/data/minio/${local.name}/*"
+    capabilities = ["read", "list"]
+  }
+  rule {
+    # Le document lui-même (la règle ci-dessus ne couvre que ses descendants).
+    path         = "kvv2/data/minio/${local.name}"
+    capabilities = ["read", "list"]
+  }
   # Extra shared paths this app's prod runtime may read (e.g. backup creds).
   dynamic "rule" {
     for_each = var.kv_read_paths
@@ -204,6 +224,15 @@ data "vault_policy_document" "app_non_prod" {
     path         = "postgres/creds/${each.key}*"
     capabilities = ["read"]
   }
+  # Idem prod : chaque instance lit les identifiants MinIO portant SON nom.
+  rule {
+    path         = "kvv2/data/minio/${each.key}/*"
+    capabilities = ["read", "list"]
+  }
+  rule {
+    path         = "kvv2/data/minio/${each.key}"
+    capabilities = ["read", "list"]
+  }
 }
 resource "vault_policy" "app_non_prod" {
   for_each = toset(local.non_prod_instances)

hashicorp-vault/iac/modules/app_roles/main.tf

@@ -30,9 +30,36 @@ resource "vault_database_secret_backend_role" "role" {
   backend = local.vault_mount_postgres.path
   name    = local.instance
   db_name = "postgres"
+  # ── Le rôle ÉPHÉMÈRE endosse le rôle STABLE, dès le login ───────────────────
+  #
+  # En PostgreSQL, un objet appartient au rôle qui l'a CRÉÉ. Comme chaque
+  # démarrage de pod obtient un rôle `v-kubernet-…` neuf, toute migration crée
+  # des objets que le pod SUIVANT ne peut plus lire. C'est ce qui a mis l'API
+  # kadans à terre une demi-journée le 2026-07-28 (« permission denied for table
+  # qualification_video »), et c'est ce que le CronJob `pg-fix-table-ownership`
+  # rattrape tous les jours à 03:00 — a posteriori, et pour les seules TABLES.
+  #
+  # `ALTER ROLE … SET ROLE` fait de l'endossement un DÉFAUT DE CONNEXION : plus
+  # rien à poser côté application, et ça vaut aussi pour les clients qui ne sont
+  # pas l'application (le `psql` d'un job, une console d'exploitation).
+  #
+  # AUCUN privilège nouveau : le `GRANT` de la ligne précédente rend déjà le
+  # rôle éphémère MEMBRE du rôle stable. Endosser une casquette qu'on porte
+  # déjà, ce n'est pas une élévation — et c'est pourquoi cette instruction ne
+  # peut pas échouer là où le `GRANT` réussit.
+  #
+  # MESURÉ (PostgreSQL 16, compte CREATEROLE non-superutilisateur, comme celui
+  # de Vault) : l'instruction passe, le login donne `session_user=v-test-1` /
+  # `current_role=proprio_v`, et un `ALTER ROLE … RESET role` la retire.
+  # Vérifié aussi qu'elle SURVIT à `RESET ALL` / `DISCARD ALL` — donc elle
+  # compose avec le `server_reset_query` de pgbouncer au lieu de s'y opposer.
+  #
+  # ⚠ Ne vaut que pour les identifiants créés APRÈS l'apply : les baux en cours
+  # gardent leur ancien comportement jusqu'à leur renouvellement.
   creation_statements = [
     "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
     "GRANT ${local.owner_role} TO \"{{name}}\";",
+    "ALTER ROLE \"{{name}}\" SET ROLE ${local.owner_role};",
   ]
   revocation_statements = [
     "REASSIGN OWNED BY \"{{name}}\" TO ${local.owner_role};",       # reassign must be executed in the database where the reassgined objects are - TODO (one connection per database/app)

minio/README.md

@@ -23,9 +23,9 @@ application vivent avec cette application.
 | Mode | **standalone** (1 réplique) — la donnée est dérivée et Longhorn réplique déjà le volume ; l'erasure coding distribué coûterait de la RAM que des Pi 5 n'ont pas à dépenser pour ça |
 | Volume | **50 Gi** sur `longhorn` ≈ **250 h de cours** au palier « travail ». ⚠ Longhorn réplique : compter **×3** sur la capacité du cluster avant d'augmenter |
 | Ressources | requests 512 Mi / 100 m · limit 2 Gi — la limite protège les voisins de `tools`, pas MinIO |
-| API S3 | `s3.arcodange.lab` (Traefik) |
+| 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) |
-| Bucket | `kadans-videos`, **privé** — l'accès passe par des URL signées (ADR-0002 du dossier produit) |
+| Buckets | **aucun ici** — chaque app déclare les siens depuis son dépôt (module `minio_app`). Tous privés : l'accès passe par des URL signées (ADR-0002 du dossier produit) |
 | 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
@@ -52,3 +52,94 @@ L'ordre compte, et il compte **deux fois** :
 > [!NOTE]
 > Sans le secret `minio-config`, le pod ne démarre pas. C'est voulu — mieux
 > vaut un pod en attente qu'un MinIO ouvert avec des identifiants par défaut.
+
+
+## Pourquoi une exposition publique (`s3.arcodange.fr`)
+
+La PWA Kadans est servie en `https://kadans.arcodange.fr` et téléverse ses vidéos
+**directement** vers MinIO, avec des URL présignées émises par kadans-api
+(kadans-api#23) : les octets ne passent jamais par l'API.
+
+Deux raisons rendent le `.lab` inutilisable pour ça, et ce sont des faits du
+navigateur, pas des préférences :
+
+1. **Contenu mixte** — une page servie en `https` ne peut pas émettre une requête
+   vers `http://`. L'ingress `.lab` est en entrypoint `web` sans TLS.
+2. **`.lab` n'est pas résolvable hors du LAN** — la synchronisation ne marcherait
+   qu'à la maison, ce qui vide de son sens « retrouver mes vidéos sur mon autre
+   appareil ».
+
+**Pas de basic-auth** sur cet ingress, contrairement à `kadans-public` : une
+requête S3 porte sa propre signature (SigV4). Un défi HTTP Basic casserait le PUT
+présigné, auquel le navigateur ne peut pas répondre. L'autorisation vient de
+l'URL signée et de sa durée de vie courte (15 min pour déposer, 1 h pour lire).
+
+**CORS** (`MINIO_API_CORS_ALLOW_ORIGIN`) liste les origines EXACTES de la PWA —
+jamais `*` : une URL présignée qui fuiterait serait sinon rejouable depuis
+n'importe quel site.
+
+### ⚠ À vérifier avant de s'y fier : la taille maximale d'une requête
+
+Le trafic public passe par un **tunnel Cloudflare**. Les offres gratuites de
+Cloudflare plafonnent la taille du corps d'une requête proxifiée (de l'ordre de
+**100 Mo**) — ce plafond n'a **pas** été mesuré ici, il doit l'être avec un vrai
+téléversement avant d'annoncer une limite aux utilisateurs.
+
+Ce qu'on sait, en revanche, et qui rend le sujet peu urgent : sur le corpus réel
+du fondateur (707 vidéos, ~2 ans), **la durée moyenne est de 53 secondes** et
+**deux vidéos seulement dépassent 5 minutes**. Au palier « travail » de l'ADR-018
+(360p ≈ 3,4 Mo/min), 100 Mo représentent ~29 minutes de cours : le corpus entier
+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
+
+**Rien à faire ici.** Chaque application déclare **ses** buckets **depuis son
+propre dépôt**, avec le module que ce dépôt-ci fournit :
+
+```hcl
+# iac/main.tf de l'application
+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::…/tools.git//minio/iac/modules/minio_app?depth=1&ref=main"
+  app       = "mon-app"
+  buckets   = ["mon-app-fichiers"]
+  providers = { minio = minio }
+}
+```
+
+Voir `iac/modules/minio_app/README.md`. **Chacun son périmètre** : `tools`
+fournit le serveur, le provisionneur et le module — pas la liste des buckets.
+Sans ça, chaque bucket de chaque app deviendrait une PR sur l'infra partagée.
+
+### Ce que `tools` fournit, et pourquoi
+
+| Pièce | Rôle |
+|---|---|
+| Le serveur | le chart, son volume, ses ingress (interne + public) |
+| Le **root** | généré ici, écrit dans `kvv2/minio/config`, **ne sort jamais** de ce pipeline |
+| Le **provisionneur** | un compte aux droits d'administration MINIMAUX (créer bucket, politique, compte de service) et **aucun droit sur les objets** — lisible par le rôle CI de chaque app |
+| Le **module** | `minio_app` : standardise la déclaration, sans la détenir |
+
+Donner le root aux apps aurait été absurde : il lit et écrit **tous** les objets
+de **toutes** les apps. Le provisionneur, lui, peut créer des buckets — une
+nuisance si une app est compromise — mais **pas lire les vidéos d'une autre**.
+
+### Rotation
+
+Depuis l'`iac/` de l'app : détruire `module.stockage.random_password.app` et
+relancer son plan. La clé change, `force_destroy = false` garde le compte, et
+les objets déjà déposés conservent leur propriétaire.

minio/iac/modules/minio_app/README.md

@@ -0,0 +1,56 @@
+# `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://[email protected]: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/<app>` 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/<app>`, 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.

minio/iac/modules/minio_app/main.tf

@@ -0,0 +1,57 @@
+# Module `minio_app` — une app déclare SES buckets depuis SON dépôt.
+# Décisions : factory/doc/adr/20260726-stockage-objet-minio.md
+
+resource "minio_s3_bucket" "app" {
+  for_each      = toset(var.buckets)
+  bucket        = each.key
+  acl           = "private" # l'accès passe par des URL présignées
+  force_destroy = false     # détruire un bucket doit être un geste explicite
+}
+
+resource "minio_iam_policy" "app" {
+  name = "${var.app}-app"
+  policy = jsonencode({
+    Version = "2012-10-17"
+    Statement = [
+      {
+        Effect   = "Allow"
+        Action   = ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"]
+        Resource = [for b in var.buckets : "arn:aws:s3:::${b}/*"]
+      },
+      {
+        Effect   = "Allow"
+        Action   = ["s3:ListBucket", "s3:GetBucketLocation"]
+        Resource = [for b in var.buckets : "arn:aws:s3:::${b}"]
+      },
+    ]
+  })
+}
+
+resource "random_password" "app" {
+  length  = 40
+  special = false # les outils S3 transportent mal certains caractères en URL
+}
+
+resource "minio_iam_user" "app" {
+  name          = "${var.app}-app"
+  secret        = random_password.app.result
+  force_destroy = false # une rotation ne recrée pas l'utilisateur : les objets gardent leur propriétaire
+}
+
+resource "minio_iam_user_policy_attachment" "app" {
+  user_name   = minio_iam_user.app.id
+  policy_name = minio_iam_policy.app.id
+}
+
+# Lu par le pod de l'app — `app_policy` lui accorde déjà ce chemin.
+resource "vault_kv_secret_v2" "app" {
+  mount = "kvv2"
+  name  = "minio/${var.app}"
+  data_json = jsonencode({
+    MINIO_ENDPOINT   = var.endpoint
+    MINIO_BUCKET     = var.buckets[0]
+    MINIO_BUCKETS    = join(",", var.buckets)
+    MINIO_ACCESS_KEY = minio_iam_user.app.id
+    MINIO_SECRET_KEY = random_password.app.result
+  })
+}

minio/iac/modules/minio_app/outputs.tf

@@ -0,0 +1,9 @@
+output "vault_path" {
+  value       = "kvv2/minio/${var.app}"
+  description = "Où le pod lira ses identifiants (VaultStaticSecret)."
+}
+
+output "buckets" {
+  value       = var.buckets
+  description = "Écho des buckets créés."
+}

minio/iac/modules/minio_app/providers.tf

@@ -0,0 +1,14 @@
+terraform {
+  required_providers {
+    minio = {
+      source                = "aminueza/minio"
+      configuration_aliases = [minio]
+    }
+    vault = {
+      source = "hashicorp/vault"
+    }
+    random = {
+      source = "hashicorp/random"
+    }
+  }
+}

minio/iac/modules/minio_app/variables.tf

@@ -0,0 +1,15 @@
+variable "app" {
+  type        = string
+  description = "Nom de l'app (= son rôle Vault). Décide du chemin du secret et du nom du compte de service."
+}
+
+variable "buckets" {
+  type        = list(string)
+  description = "Ses buckets, créés ici (privés). Le compte de service n'a de droits que sur eux."
+}
+
+variable "endpoint" {
+  type        = string
+  default     = "s3.arcodange.fr"
+  description = "Hôte de l'API S3, sans schéma. Public : le runner CI n'est pas dans le LAN."
+}

minio/iac/providers.tf

@@ -4,6 +4,14 @@ terraform {
       source  = "vault"
       version = "4.4.0"
     }
+    minio = {
+      source  = "aminueza/minio"
+      version = "3.3.0"
+    }
+    random = {
+      source  = "hashicorp/random"
+      version = "3.6.3"
+    }
   }
 }
 
@@ -14,3 +22,11 @@ provider "vault" {
     role  = "gitea_cicd_minio"
   }
 }
+
+# Provider MinIO — crée le compte de provisionnement (provisioner.tf).
+provider "minio" {
+  minio_server   = var.minio_endpoint
+  minio_user     = local.config.rootUser
+  minio_password = local.config.rootPassword
+  minio_ssl      = true
+}

minio/iac/provisioner.tf

@@ -0,0 +1,69 @@
+# Compte de PROVISIONNEMENT : crée buckets, politiques et comptes de service —
+# aucun droit sur les objets. C'est lui que lisent les rôles CI des apps, pour
+# qu'elles déclarent leurs buckets sans qu'on leur confie le root.
+# Décisions : factory/doc/adr/20260726-stockage-objet-minio.md
+#
+# Noms d'actions confirmés par le premier apply réel (kadans, 2026-07-26) : le
+# bloc admin passe tel quel ; côté s3 il manquait `s3:ListBucket`, que le
+# provider appelle AVANT de créer un bucket pour savoir s'il existe déjà.
+resource "minio_iam_policy" "provisioner" {
+  name = "provisioner"
+  policy = jsonencode({
+    Version = "2012-10-17"
+    Statement = [
+      {
+        Effect = "Allow"
+        Action = [
+          "admin:CreateUser",
+          "admin:DeleteUser",
+          "admin:ListUsers",
+          "admin:GetUser",
+          "admin:CreatePolicy",
+          "admin:DeletePolicy",
+          "admin:GetPolicy",
+          "admin:ListUserPolicies",
+          "admin:AttachUserOrGroupPolicy",
+        ]
+        Resource = ["arn:aws:s3:::*"]
+      },
+      {
+        # s3:GetObject / s3:PutObject volontairement ABSENTS : le provisionneur
+        # ne LIT ni n'ÉCRIT aucun objet, c'est ce qui rend son partage entre
+        # rôles CI acceptable.
+        #
+        # `s3:ListBucket` est la seule concession : MinIO le demande pour un
+        # HeadBucket, et le provider teste l'existence du bucket avant de le
+        # créer. Il donne la vue des CLÉS d'un bucket, jamais leur contenu.
+        Effect   = "Allow"
+        Action   = ["s3:CreateBucket", "s3:DeleteBucket", "s3:ListBucket", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketPolicy", "s3:PutBucketPolicy"]
+        Resource = ["arn:aws:s3:::*"]
+      },
+    ]
+  })
+}
+
+resource "random_password" "provisioner" {
+  length  = 40
+  special = false
+}
+
+resource "minio_iam_user" "provisioner" {
+  name          = "provisioner"
+  secret        = random_password.provisioner.result
+  force_destroy = false
+}
+
+resource "minio_iam_user_policy_attachment" "provisioner" {
+  user_name   = minio_iam_user.provisioner.id
+  policy_name = minio_iam_policy.provisioner.id
+}
+
+resource "vault_kv_secret_v2" "provisioner" {
+  mount = "kvv2"
+  name  = "minio/provisioner"
+  data_json = jsonencode({
+    MINIO_ENDPOINT   = var.minio_endpoint
+    MINIO_ACCESS_KEY = minio_iam_user.provisioner.id
+    MINIO_SECRET_KEY = random_password.provisioner.result
+  })
+}

minio/iac/variables.tf

@@ -0,0 +1,5 @@
+variable "minio_endpoint" {
+  type        = string
+  default     = "s3.arcodange.fr"
+  description = "Hôte de l'API S3, sans schéma. Public : le runner CI n'est pas dans le LAN."
+}

minio/templates/ingress-public.yaml

@@ -0,0 +1,29 @@
+# Exposition PUBLIQUE s3.arcodange.fr — TLS terminé par le tunnel Cloudflare,
+# middleware crowdsec. Le `.lab` interne reste inchangé.
+#
+# ⚠ PAS de basic-auth ici, contrairement à kadans-public : une requête S3 porte
+# sa propre signature (SigV4), et un défi HTTP Basic casserait le PUT présigné
+# auquel le navigateur ne peut pas répondre.
+#
+# ADR : factory/doc/adr/20260726-stockage-objet-minio.md
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: minio-public
+  namespace: tools
+  annotations:
+    traefik.ingress.kubernetes.io/router.entrypoints: web
+    traefik.ingress.kubernetes.io/router.middlewares: kube-system-crowdsec@kubernetescrd
+spec:
+  ingressClassName: traefik
+  rules:
+    - host: s3.arcodange.fr
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: minio
+                port:
+                  number: 9000

minio/values.yaml

@@ -61,11 +61,10 @@ minio: &minio_config
   # Buckets créés au déploiement. `versioning: false` assumé : ces objets sont
   # DÉRIVÉS et re-générables depuis le master local — versionner doublerait le
   # stockage pour un filet dont on n'a pas besoin.
-  buckets:
-    - name: kadans-videos
-      policy: none # privé : l'accès passe par des URL signées (ADR-0002 du dossier)
-      purge: false
-      versioning: false
+  # AUCUN bucket ici : chaque app déclare les siens depuis son dépôt, via le
+  # module `iac/modules/minio_app`.
+  # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
+  buckets: []
 
   # Métriques : Prometheus (namespace `tools`) scrape déjà la façade et le
   # laptop (ADR-0014 du dossier) — MinIO rejoint la même vue.
@@ -74,6 +73,9 @@ minio: &minio_config
       enabled: false # pas d'opérateur Prometheus ici : scrape par annotation
   environment:
     MINIO_PROMETHEUS_AUTH_TYPE: "public"
+    # CORS : le navigateur téléverse directement (URL présignées) — origines
+    # EXACTES, jamais « * » : une URL qui fuite serait sinon rejouable partout.
+    MINIO_API_CORS_ALLOW_ORIGIN: "https://kadans.arcodange.fr,https://kadans.arcodange.lab"
 
 tool:
   # kind: 'SubChart' or 'HelmChart', if subchart then uncomment Chart.yaml dependency, else comment and use tool library with helm chart template

pgbouncer/values.yaml

@@ -14,7 +14,63 @@ pgbouncer: &pgbouncer_config
       auth_type: scram-sha-256
       auth_query: SELECT uname, phash FROM user_lookup($1)
       ignore_startup_parameters: extra_float_digits # unsupported jdbc extra_float_digits=2 argument
-      server_reset_query: DEALLOCATE ALL # fix prepared statement already exist (crowdsec)
+      # Ce pgbouncer est PARTAGÉ (crowdsec, plausible, kadans, + le compte que
+      # Vault utilise sur la base `postgres`). Ce qu'un client laisse derrière
+      # lui sur une connexion serveur, le client SUIVANT en hérite : le reset
+      # est la SEULE barrière entre deux clients d'un même pool.
+      #
+      # `DEALLOCATE ALL` ne nettoie QUE les requêtes préparées — d'où sa mise en
+      # place (07e2c6d, « prepared statement already exists » de crowdsec).
+      # Tout le reste de l'état de session passait au suivant. MESURÉ contre un
+      # pgbouncer **1.23.1** — la version RÉELLEMENT déployée (image
+      # ghcr.io/icoretech/pgbouncer-docker:1.23.1-fixed, chart pgbouncer-2.3.1),
+      # montée avec CETTE configuration extraite du cluster (session,
+      # pool_size=1) : le client 2, qui n'avait rien demandé, héritait de
+      # `work_mem=17MB`, du `LISTEN canal_test` du client 1, de sa table TEMP —
+      # et de son `SET ROLE`, au point de créer des tables appartenant à un
+      # autre rôle que le sien.
+      #
+      # Portée de la fuite, mesurée et non supposée : les pools sont partitionnés
+      # par (base, utilisateur) — 210 pools, aucun ne mélange deux bases ni deux
+      # comptes. Le seul héritier possible d'un `SET ROLE` posé par kadans-api
+      # est un client de la base `kadans` avec le MÊME identifiant éphémère,
+      # c'est-à-dire kadans-api elle-même. Défaut d'hygiène, pas brèche
+      # inter-applications.
+      #
+      # `DISCARD ALL` est le défaut de pgbouncer, et c'est un SUR-ENSEMBLE strict
+      # des deux valeurs qui l'ont précédé ici : il contient `DEALLOCATE ALL`
+      # (donc le correctif crowdsec est conservé — vérifié : deux clients
+      # successifs préparent le même nom sans erreur) ET
+      # `SELECT pg_advisory_unlock_all()` (la valeur que pose le sous-chart).
+      #
+      # Il ne peut RIEN casser pour un client vivant : en `pool_mode = session`
+      # la connexion serveur n'est rendue qu'à la déconnexion du client, donc le
+      # reset ne court jamais entre deux requêtes d'une même session. Vérifié :
+      # table TEMP, `SET work_mem` et `LISTEN` d'un client VIVANT survivent.
+      #
+      # ⚠⚠ CE QUE CETTE LIGNE REND FRAGILE — et c'est l'inverse de ce qu'on croit.
+      #
+      # `pool_mode` n'est PAS déclaré ici, donc il vaut `session`, le défaut.
+      # C'est ce qui rend `DISCARD ALL` sans danger. **Le jour où quelqu'un
+      # écrira `pool_mode: transaction`, il cassera kadans-api en silence** :
+      # son `SET ROLE` est posé UNE FOIS à l'ouverture (`AfterConnect`, db.go),
+      # et en transaction pooling `DISCARD ALL` court ENTRE deux transactions —
+      # donc le rôle est effacé avant les migrations suivantes. MESURÉ, les
+      # quatre combinaisons, propriétaire de la table créée :
+      #
+      #   session     + DEALLOCATE ALL → rôle stable ✅ (mais la fuite reste)
+      #   session     + DISCARD ALL    → rôle stable ✅  ← ce qu'on déploie
+      #   transaction + DEALLOCATE ALL → rôle stable ✅ (par ACCIDENT : la fuite
+      #                                   qu'on referme est ce qui le sauvait)
+      #   transaction + DISCARD ALL    → rôle ÉPHÉMÈRE ❌ le défaut du 28/07,
+      #                                   qui a mis l'API à terre une demi-journée
+      #
+      # Et `poserRoleProprietaire` ne peut pas le voir : sa relecture de
+      # `current_role` a lieu à l'ouverture, où le rôle est encore correct.
+      # Ce qui couvre ce cas, c'est la ceinture Vault (`ALTER ROLE … SET ROLE`,
+      # module app_roles) : un défaut de rôle survit à `DISCARD ALL`. **Avant de
+      # passer en transaction pooling, vérifier que les baux Vault ont tourné.**
+      server_reset_query: DISCARD ALL # défaut pgbouncer — ⚠ ne pas réduire : voir ci-dessus
       server_idle_timeout: 7200
   pgbouncerExporter:
     enabled: false