Merge pull request 'feat(minio) — un téléversement abandonné laisse des parts que RIEN ne montre, et le plafond du tunnel est enfin mesuré' (#30) from arcodange/minio-multipart into main

Reviewed-on: #30

README.md

@@ -8,6 +8,13 @@ pour chaque dossier de premier niveau contenant un fichier Chart.yaml (sauf les
 le pousser dans le registre helm de gitea
 ```
 
+## Réseau
+
+- [Ce que Traefik voit du client](doc/ce-que-traefik-voit.md) — pourquoi
+  `ClientIP()` ne voit que le tunnel sur les hôtes `.fr`, pourquoi `localIp@file`
+  n'a rien à y faire, et comment obtenir « pas de mot de passe depuis la maison »
+  sans créer un contournement d'authentification.
+
 ## pgbouncer
 
 ## prometheus

doc/ce-que-traefik-voit.md

@@ -0,0 +1,224 @@
+# Ce que Traefik voit du client — et pourquoi « pas de mot de passe à la maison » ne se règle pas dans Traefik
+
+Mesuré le 2026-07-28 sur le homelab (`kubectl --context=default`, k3s pi1/pi2/pi3).
+Ce document existe parce que la question « peut-on sauter le basic auth quand on est
+sur le Wi-Fi de la maison ? » a une réponse contre-intuitive, et que la réponse
+intuitive est un **trou de sécurité**.
+
+## 1. Le chemin réel d'une requête `.fr`
+
+```
+navigateur (maison)
+  └─ DNS : kadans.arcodange.fr → 172.67.130.8 / 104.21.3.16   (Cloudflare, PAS le LAN)
+      └─ edge Cloudflare (proxy orange)
+          └─ tunnel cloudflared (sortant, pod du cluster, CIDR 10.42.0.0/16)
+              └─ traefik.kube-system.svc:80   (entrypoint `web`, pas de TLS ici)
+                  └─ crowdsec → basic auth → service
+```
+
+Le tunnel est **sortant** : il n'y a aucune redirection de port, aucun chemin
+depuis Internet vers Traefik autre que Cloudflare. Le nom `.fr` est un CNAME
+proxifié vers `<tunnel-id>.cfargotunnel.com` (`cms/cloudflare`, module
+`cloudflared_tunnel`, mapping unique `*.arcodange.fr`).
+
+**Conséquence n°1 : même depuis le salon, la requête sort de la maison, fait un
+aller-retour par Cloudflare, et revient par le tunnel.** L'adresse de la socket
+que Traefik accepte est toujours celle d'un pod `cloudflared` en `10.42.x.x`.
+
+Le `.lab`, lui, va droit au but : `kadans.arcodange.lab → 192.168.1.201`.
+
+## 2. Deux notions d'« IP client », et elles ne coïncident pas
+
+L'entrypoint `web` fait confiance aux en-têtes transmis depuis le CIDR des pods
+(`ports.web.forwardedHeaders.trustedIPs: ["10.42.0.0/16"]`, playbook
+`factory/.../playbooks/system/k3s_config.yml`). Traefik **sait donc** qui est le
+vrai client — le journal d'accès le prouve, sur une requête émise depuis la maison :
+
+```
+2a01:cb04:dff:cf00:f9d7:4026:9ffc:b042 - kadans [28/Jul/2026:14:22:49 +0200]
+  "GET /?sonde=… HTTP/1.1" 200 … "kadans-kadans-public-kadans-arcodange-fr@kubernetes"
+```
+
+Deux choses à retenir de cette ligne :
+
+- Traefik **résout** le vrai client depuis `X-Forwarded-For` ;
+- la maison sort en **IPv6** (`2a01:cb04:dff:cf00::/64`), pas en IPv4. Le
+  `86.238.234.54/32` que le playbook injecte dans `localIp` via `ipify` n'est
+  qu'**une** des deux adresses publiques du foyer, et pas celle qu'un navigateur
+  moderne utilise en priorité.
+
+Mais **le matcher de routeur `ClientIP()` n'utilise PAS cette résolution.** Il
+juge l'adresse de la socket. Mesuré, pas supposé — trois routeurs temporaires
+posés sur `kadans.arcodange.fr`, pointant vers un Service sans endpoint (donc
+`503` si la règle matche, et repli sur le routeur normal — `401` — sinon) :
+
+| sonde | règle ajoutée à `Host(kadans.arcodange.fr)`   | attendu si…                    | mesuré |
+| ----- | -------------------------------------------- | ------------------------------ | ------ |
+| T     | *(témoin, aucune contrainte d'IP)*           | le dispositif fonctionne → 503 | **503** |
+| A     | `ClientIP("2a01:cb04:dff:cf00::/64")`        | `ClientIP` lit X-Forwarded-For | **401** |
+| B     | `ClientIP("10.42.0.0/16")`                   | `ClientIP` lit la socket       | **503** |
+
+Le témoin valide le montage ; A échoue, B réussit. **`ClientIP()` voit le pod
+`cloudflared`, jamais le vrai client.** (Sondes supprimées après mesure.)
+
+## 3. Les deux pièges qui en découlent
+
+### Piège A — `localIp@file` ne doit JAMAIS toucher un routeur `.fr`
+
+`localIp` est un `ipAllowList` dont le `sourceRange` contient `10.42.0.0/16`
+(le CIDR des pods). Comme `ipAllowList` juge lui aussi l'adresse de la socket
+par défaut, **l'attacher à un hôte `.fr` laisserait passer Internet entier** :
+toute requête arrivant par le tunnel se présente en `10.42.x.x`, donc « locale ».
+
+État vérifié le 2026-07-28 : aucun routeur `.fr` ne porte `localIp@file`. Le
+piège est **latent**, pas ouvert. Il le reste tant que personne ne recopie
+`localIp@file` depuis un values `.lab` (grafana, vault, plausible) vers un
+`ingress-public.yaml`. Les deux gabarits `.fr` de ce dépôt portent un
+avertissement à cet endroit précis.
+
+### Piège B — se fier à un en-tête est un contournement d'authentification
+
+« Sauter le basic auth si `CF-Connecting-IP` est celle de la maison » (ou si un
+en-tête maison est présent) fait reposer une **exemption d'authentification** sur
+une valeur que le client écrit lui-même. Cloudflare ne retire pas les en-têtes
+inconnus : n'importe qui sur Internet peut les envoyer. Et Traefik reste joignable
+en direct sur le LAN (`192.168.1.201:80`). **On ne prend pas cette voie.**
+
+## 4. Pourquoi ce n'est pas réparable dans Traefik
+
+Traefik enchaîne ses middlewares **inconditionnellement** : il n'existe pas de
+« basic auth sauf si … ». Le seul moyen de sauter un middleware est de faire
+matcher un **autre routeur** — et le seul discriminant d'IP au niveau routeur est
+`ClientIP()`, qui, on vient de le mesurer, ne voit que le tunnel. Un
+`ipAllowList` avec `ipStrategy.depth` verrait bien la vraie IP, mais un
+`ipAllowList` **bloque** ; il ne sait pas « laisser entrer sans mot de passe ».
+
+Faire pointer le LAN vers Traefik (DNS à double horizon, ou enregistrement
+Cloudflare « DNS only ») rendrait `ClientIP(192.168.1.0/24)` honnête — mais
+coûterait, en plus du DNS : un **certificat publiquement valide** pour
+`kadans.arcodange.fr` sur Traefik (aujourd'hui il sert la CA interne,
+`CN=arcodange.lab` ; un `curl --resolve … 192.168.1.201` échoue au TLS, code
+`000`), donc un nouveau `certResolver` DNS-01 Cloudflare et le jeton qui va avec,
+plus un routeur `websecure` pour un hôte qui vit aujourd'hui en `web` clair.
+Beaucoup, pour du confort. Et « DNS only » retirerait en prime le bouclier
+Cloudflare de cet hôte.
+
+**La décision doit donc être prise là où la vraie IP est native et non
+falsifiable : au bord, chez Cloudflare (`ip.src`).**
+
+## 5. La voie retenue — Cloudflare tape le mot de passe à ta place
+
+Le basic auth de `kadans.arcodange.fr` est un **garde-fou assumé**, pas un
+secret : `kadans:kkadans`, et son hash bcrypt est en clair dans
+`chart/values.yaml` du dépôt `kadans`. C'est ce fait qui rend la solution
+simple **et** sans coût de sécurité :
+
+> Une règle Cloudflare pré-remplit l'en-tête `Authorization` pour les requêtes
+> venant du réseau de la maison. Traefik ne change pas, le mot de passe reste
+> exigé partout ailleurs. Cloudflare ne fait que le **taper à ta place**.
+
+Surface d'attaque ajoutée : **aucune**. Un attaquant qui forge cet en-tête
+obtient exactement ce que `curl -u kadans:kkadans` lui donne déjà aujourd'hui.
+C'est la différence de fond avec le piège B : ici on ne crée pas d'exemption, on
+automatise une saisie.
+
+Et quand l'IP du foyer change (elle est dynamique), la règle cesse simplement de
+matcher : **le navigateur redemande le mot de passe**. Dégradation douce, jamais
+de panne.
+
+### Action manuelle du fondateur (à faire une fois)
+
+Cloudflare → zone `arcodange.fr` → **Rules** → **Transform Rules** → **Modify
+Request Header** → *Create rule* :
+
+- **Nom** : `kadans — confort LAN : Authorization pré-remplie depuis la maison`
+- **When incoming requests match** (éditeur d'expression) :
+
+  ```
+  (http.host eq "kadans.arcodange.fr" and ip.src in {86.238.234.54 2a01:cb04:dff:cf00::/64})
+  ```
+
+- **Then** → *Set static* :
+  - Header name : `Authorization`
+  - Value : `Basic a2FkYW5zOmtrYWRhbnM=`   *(base64 de `kadans:kkadans`)*
+
+Équivalent Terraform, si on préfère le déclarer dans `cms/cloudflare` :
+
+```hcl
+resource "cloudflare_ruleset" "confort_lan_kadans" {
+  zone_id = cloudflare_zone.arcodange_fr.id
+  name    = "confort LAN"
+  kind    = "zone"
+  phase   = "http_request_late_transform"
+
+  rules = [{
+    expression  = "(http.host eq \"kadans.arcodange.fr\" and ip.src in {86.238.234.54 2a01:cb04:dff:cf00::/64})"
+    description = "Depuis la maison, Cloudflare tape le garde-fou basic auth a notre place"
+    action      = "rewrite"
+    action_parameters = {
+      headers = {
+        "Authorization" = { operation = "set", value = "Basic a2FkYW5zOmtrYWRhbnM=" }
+      }
+    }
+  }]
+}
+```
+
+### Vérifier que ça marche
+
+```bash
+# depuis la maison — attendu : 200, SANS -u
+curl -s -o /dev/null -w '%{http_code}\n' https://kadans.arcodange.fr/
+
+# depuis l'extérieur (partage de connexion du téléphone) — attendu : 401
+curl -s -o /dev/null -w '%{http_code}\n' https://kadans.arcodange.fr/
+```
+
+### Ce qu'il faudra surveiller
+
+- **Les deux adresses du foyer sont dynamiques.** Le préfixe IPv6 relevé le
+  2026-07-28 est `2a01:cb04:dff:cf00::/64` et l'IPv4 `86.238.234.54` — la même
+  que celle qu'`ipify` injecte dans `localIp` à chaque passage du playbook
+  `k3s_config.yml`. S'il dérive, élargir en `/56` avant de soupçonner Cloudflare.
+- ⚠ **Non vérifié en vrai** : que Cloudflare accepte `Authorization` comme
+  en-tête de requête modifiable (certains en-têtes sont réservés). Si l'éditeur
+  refuse la règle, le repli est **Cloudflare Access** avec une politique
+  *Bypass* sur les mêmes IP et une politique *Allow* par e-mail ailleurs — et le
+  basic auth de Traefik est alors retiré. Le repli n'est **pas** un en-tête
+  secret (piège B).
+
+### La version encore plus simple, si le confort ne vaut pas la règle
+
+Le mot de passe est public. Ce qu'il achète réellement, c'est « le produit en
+chantier n'est pas indexé ni tombé dessus par hasard ». Un `robots.txt` +
+`X-Robots-Tag: noindex` fait ce travail-là sans mot de passe du tout. Retirer le
+garde-fou est une décision produit, pas une décision d'infra : elle n'est pas
+prise ici, seulement nommée.
+
+## 6. Ce qui a été vérifié et qui va bien
+
+Le bouncer CrowdSec, lui, **juge la vraie IP** — contrairement à `ClientIP()`.
+Journal Traefik sur une requête de la maison et sur des robots :
+
+```
+CrowdsecBouncerTraefikPlugin: ServeHTTP ip:2a01:cb04:dff:cf00:f9d7:4026:9ffc:b042 isTrusted:false
+CrowdsecBouncerTraefikPlugin: ServeHTTP ip:144.24.58.222 isTrusted:false
+```
+
+Son `clientTrustedIPs` contient pourtant `10.42.0.0/16` : ce n'est **pas** un
+trou, parce que le plugin ne compare pas cette liste à l'adresse de la socket
+mais à l'IP résolue. La convention `.fr` (« crowdsec devant tout ») tient donc
+ce qu'elle promet. Écrit ici pour que personne ne « corrige » cette ligne en
+croyant reproduire le piège A.
+
+---
+
+**Où vit quoi** (aucun de ces réglages n'est dans ce dépôt — vérifié) :
+
+| réglage                                     | dépôt / fichier                                                          |
+| ------------------------------------------- | ------------------------------------------------------------------------ |
+| valeurs Helm Traefik, `dynamic.yaml`, `localIp` | `factory` — `ansible/arcodange/factory/playbooks/system/k3s_config.yml`   |
+| Middleware `crowdsec@kube-system`           | `factory` — `.../playbooks/tools/roles/crowdsec/tasks/main.yml`           |
+| tunnel + DNS `*.arcodange.fr`               | `cms` — `cloudflare/iac.tf`, `cloudflare/modules/cloudflared_tunnel/`     |
+| basic auth `.fr` de kadans                  | `kadans` — `chart/values.yaml` (`public.basicAuth`)                       |
+| gabarits d'exposition `.fr` de ce dépôt     | `grafana/templates/ingress-public.yaml`, `minio/templates/ingress-public.yaml` |

grafana/templates/ingress-public.yaml

@@ -10,6 +10,12 @@
 # NB : ce chart grafana est en mode `tool.kind: SubChart`, donc les templates
 # helm-chart*.yaml ne rendent rien ; ce fichier, lui, est rendu tel quel et
 # appliqué par ArgoCD (app `grafana`, destination namespace `tools`).
+#
+# ⚠ NE JAMAIS ajouter `localIp@file` ici (ni sur aucun routeur `.fr`). Le trafic
+# `.fr` arrive par le tunnel cloudflared, donc avec l'adresse d'un pod en
+# 10.42.x.x — or `10.42.0.0/16` est dans le `sourceRange` de `localIp`, et
+# `ipAllowList` juge l'adresse de la SOCKET. Le middleware « IP locale
+# seulement » laisserait donc entrer Internet entier. Mesuré : doc/ce-que-traefik-voit.md §3.
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:

grafana/values.yaml

@@ -285,6 +285,8 @@ grafana: &grafana_config
       traefik.ingress.kubernetes.io/router.tls.certresolver: letsencrypt
       traefik.ingress.kubernetes.io/router.tls.domains.0.main: arcodange.lab
       traefik.ingress.kubernetes.io/router.tls.domains.0.sans: grafana.arcodange.lab
+      # ⚠ Valable parce que cet hôte est en `.lab` (le client arrive en direct sur
+      # 192.168.1.201). À NE PAS recopier sur un hôte `.fr` : cf. doc/ce-que-traefik-voit.md §3.
       traefik.ingress.kubernetes.io/router.middlewares: localIp@file
     hosts:
       - grafana.arcodange.lab

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)

hashicorp-vault/templates/vault-server-pdb.yaml

@@ -0,0 +1,26 @@
+# Le sous-chart vendored `vault` ne rend son PodDisruptionBudget qu'en mode HA
+# (server.ha.disruptionBudget.enabled, gardé par `eq .mode "ha"` dans
+# server-disruptionbudget.yaml). Ce Vault tourne en standalone (storage "file",
+# un seul réplica, scellement Shamir sans auto-unseal) : le garde-fou du chart
+# ne s'applique jamais ici, d'où ce PDB écrit à la main dans le chart parapluie.
+#
+# Il ne protège que des évictions VOLONTAIRES (kubectl drain, descheduler) — pas
+# d'une panne de nœud ni d'une suppression manuelle. Avec un seul réplica et
+# aucun auto-unseal, toute interruption exige un unseal humain ensuite ; ce PDB
+# réduit seulement les interruptions évitables.
+apiVersion: policy/v1
+kind: PodDisruptionBudget
+metadata:
+  name: {{ .Release.Name }}-server
+  namespace: {{ .Release.Namespace }}
+  labels:
+    app.kubernetes.io/name: vault
+    app.kubernetes.io/instance: {{ .Release.Name }}
+    app.kubernetes.io/managed-by: {{ .Release.Service }}
+spec:
+  maxUnavailable: 0
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: vault
+      app.kubernetes.io/instance: {{ .Release.Name }}
+      component: server

hashicorp-vault/values.yaml

@@ -9,6 +9,20 @@ vault: &vault_config
     auditStorage:
       enabled: true
   
+    statefulSet:
+      securityContext:
+        pod:
+          # Le défaut du chart (runAsNonRoot/runAsGroup/runAsUser/fsGroup) est repris tel
+          # quel ici — seul fsGroupChangePolicy s'ajoute. Sans lui, chaque remount du
+          # volume (même sur le MÊME nœud) déclenche un chown -R complet ; mesuré à ~9 min
+          # sur ce PVC (kubelet event "VolumePermissionChangeInProgress"). OnRootMismatch
+          # saute le chown si le propriétaire racine est déjà bon.
+          runAsNonRoot: true
+          runAsGroup: 1000
+          runAsUser: 100
+          fsGroup: 1000
+          fsGroupChangePolicy: OnRootMismatch
+
     ingress:
       enabled: true
       annotations:
@@ -17,6 +31,8 @@ vault: &vault_config
         traefik.ingress.kubernetes.io/router.tls.certresolver: letsencrypt
         traefik.ingress.kubernetes.io/router.tls.domains.0.main: arcodange.lab
         traefik.ingress.kubernetes.io/router.tls.domains.0.sans: vault.arcodange.lab
+        # ⚠ Valable parce que cet hôte est en `.lab` (le client arrive en direct sur
+        # 192.168.1.201). À NE PAS recopier sur un hôte `.fr` : cf. doc/ce-que-traefik-voit.md §3.
         traefik.ingress.kubernetes.io/router.middlewares: localIp@file
       hosts:
         - host: vault.arcodange.lab

minio/README.md

@@ -78,20 +78,43 @@ l'URL signée et de sa durée de vie courte (15 min pour déposer, 1 h pour lire
 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
+### La taille maximale d'une requête — **mesurée le 2026-08-20**
 
-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.
+Le trafic public passe par un **tunnel Cloudflare**, qui plafonne la taille du
+corps d'une requête proxifiée. Ce plafond était marqué ici « à vérifier avant de
+s'y fier ». Il l'est.
 
-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.
+Sonde : un PUT **non signé** vers le bucket. Rien ne s'écrit, et les deux
+réponses se distinguent proprement — un 403 vient de MinIO (donc le corps a
+traversé le tunnel), un 413 vient du tunnel lui-même.
+
+| Corps | Réponse | Lecture |
+|---:|---|---|
+| 50 Mio | `403` | corps passé, refus de signature |
+| **100 Mio** | `403` | **corps passé** |
+| **101 Mio** | `413` | **refusé par le tunnel** |
+| 200 Mio | `413` | refusé par le tunnel |
+
+⚠ **Le plafond est exactement 100 Mio.** Or `kadans-api` annonçait un gabarit de
+200 Mio — le **double**. Une vidéo entre les deux était acceptée, signée,
+téléversée pendant ~100 Mo… puis coupée.
+
+⚠ **La parade retenue n'est PAS celle que cette section recommandait.** Ramener
+le gabarit sous le plafond du tunnel aurait aussi fermé les cours longs (au
+palier « travail » de l'ADR-018, 360p ≈ 3,4 Mo/min, 100 Mio ≈ 29 min). C'est le
+**téléversement en plusieurs parts** qui a été livré (kadans-api PR #188) : des
+parts de 8 Mio passent chacune très en dessous du plafond, sans rétrécir la
+promesse.
+
+Le corpus, lui, reste largement sous la limite : sur les 707 vidéos du fondateur
+(~2 ans), **la durée moyenne est de 53 secondes** et **deux seulement dépassent
+5 minutes**. C'est ce qui explique que le défaut n'ait jamais été rencontré — et
+pourquoi il attendait le premier cours entier.
+
+⚠ **Conséquence pour le bucket, et elle est ici :** un téléversement en parts
+jamais refermé laisse des parts que *rien ne montre*. Le module `minio_app` pose
+donc sur chaque bucket une règle de cycle de vie
+`AbortIncompleteMultipartUpload` à **1 jour** — voir son `main.tf`.
 
 
 ## Donner à une app l'accès au stockage

minio/iac/modules/minio_app/README.md

@@ -38,6 +38,8 @@ 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 ;
+- les **téléversements abandonnés** sont ramassés au bout d'un jour (voir plus
+  bas : c'est de l'hygiène de protocole, pas un choix de l'app) ;
 - 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
@@ -51,6 +53,48 @@ 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.
+Il ne pose ni quota, ni **expiration de contenu**, ni versioning : ces choix
+appartiennent à l'app et varient d'un bucket à l'autre. « Ces vidéos se purgent
+à 90 jours » est une décision de produit, elle se prend dans le dépôt du
+produit.
+
+### ⚠ L'exception, et la ligne qu'elle trace
+
+Ce module pose **une seule** règle de cycle de vie :
+`AbortIncompleteMultipartUpload` à 1 jour, sur chaque bucket qu'il crée.
+
+Elle a l'air de contredire le paragraphe ci-dessus. Elle ne le contredit pas —
+elle en précise la frontière, et c'est la question « à QUOI cette connaissance
+appartient-elle ? » qui tranche :
+
+- une **expiration de contenu** porte sur des objets que l'app a voulus, qu'elle
+  montre, et dont elle seule sait combien de temps ils valent. Elle varie d'une
+  app à l'autre : elle est chez l'app ;
+- un **téléversement en plusieurs parts jamais refermé** n'est le contenu de
+  personne. Ce sont des morceaux qu'aucune API ne montre — ni `mc ls`, ni la
+  console — laissés par un navigateur qui a fermé l'onglet. **Aucune app ne veut
+  les garder**, et aucune ne peut les voir depuis son propre code. C'est un
+  déchet de PROTOCOLE, produit par le mécanisme même du bucket : il est chez
+  celui qui crée les buckets.
+
+Le test pratique : si la réponse à « combien de temps ? » demande de connaître le
+produit, c'est chez l'app. Ici, la réponse ne demande que de connaître S3 — passé
+l'expiration des URL signées, un téléversement en cours ne peut plus rien
+recevoir, il occupe seulement.
+
+⚠ Le délai n'est **pas** paramétrable, et c'est voulu (YAGNI) : un seul cas
+existe. Le jour où une app signe des parts pour plus de 24 h, ce sera le
+déclencheur pour en faire une variable — pas avant.
+
+### Plancher de version
+
+⚠ Ce module exige **`aminueza/minio >= 3.10.0`** : `abort_incomplete_multipart_upload`
+y est apparu (mesuré en interrogeant le schéma du provider version par version —
+3.9.0 ne l'a pas). Un appelant resté plus bas se verra dire, dès `tofu init` :
+
+```
+no available releases match the given constraints 3.3.0, >= 3.10.0
+```
+
+… ce qui NOMME la version à atteindre, au lieu d'un « unsupported block type »
+au plan, qui ne l'aurait pas dite.

minio/iac/modules/minio_app/main.tf

@@ -8,6 +8,48 @@ resource "minio_s3_bucket" "app" {
   force_destroy = false     # détruire un bucket doit être un geste explicite
 }
 
+# ── Les téléversements ABANDONNÉS ne s'accumulent pas ────────────────────────
+#
+# Un téléversement S3 en plusieurs parts qui n'est jamais refermé laisse ses
+# parts dans le bucket : elles occupent de l'espace et AUCUN objet ne les
+# montre. `mc ls` n'en dit rien, la console non plus. C'est donc une fuite qui
+# ne se voit qu'à la facture — ou à la saturation du volume, qui est ici de
+# 50 Gi et déjà dimensionné à 250 h de cours.
+#
+# L'application abandonne ce qu'elle ouvre quand elle échoue en route. Ce
+# qu'elle ne peut PAS rattraper : un navigateur qui ferme l'onglet, perd le
+# réseau, ou expire. Ce cas-là appartient au BUCKET, pas au code applicatif —
+# c'est la seule place d'où l'on voit un téléversement que plus personne ne
+# suit.
+#
+# ⚠ POURQUOI UN JOUR, ET PAS SEPT. Les URL de parts sont signées pour quelques
+# heures (2 h côté kadans-api). Passé ce délai, un téléversement en cours ne
+# peut PLUS rien recevoir : il est mort, il occupe seulement. Un jour laisse
+# douze fois la marge nécessaire au plus long téléversement possible, sans
+# garder des déchets une semaine.
+#
+# ⚠ CE N'EST PAS PARAMÉTRABLE, ET C'EST VOULU (YAGNI) : un seul cas existe. Le
+# jour où une app signe des parts pour plus de 24 h, ce sera le déclencheur pour
+# en faire une variable — pas avant.
+#
+# ⚠ CE RÉGLAGE-CI FONCTIONNE VRAIMENT, contrairement au CORS par bucket. MinIO
+# édition communautaire stubbe `PutBucketCors` (501, cf. `cmd/dummy-handlers.go`
+# du serveur), ce qui a déjà coûté une tentative d'IaC ; les handlers de CYCLE DE
+# VIE, eux, n'y figurent PAS — vérifié à la source le 2026-08-20.
+resource "minio_ilm_policy" "app" {
+  for_each = minio_s3_bucket.app
+  bucket   = each.value.bucket
+
+  rule {
+    id     = "abandon-televersements-incomplets"
+    status = "Enabled"
+
+    abort_incomplete_multipart_upload {
+      days_after_initiation = "1d"
+    }
+  }
+}
+
 resource "minio_iam_policy" "app" {
   name = "${var.app}-app"
   policy = jsonencode({

minio/iac/modules/minio_app/providers.tf

@@ -2,6 +2,13 @@ terraform {
   required_providers {
     minio = {
       source = "aminueza/minio"
+      # ⚠ PLANCHER, ET IL N'EST PAS DÉCORATIF : `abort_incomplete_multipart_upload`
+      # est apparu en 3.10.0 (mesuré en interrogeant le schéma du provider,
+      # version par version : 3.9.0 ne l'a pas, 3.10.0 l'a). Sans cette
+      # contrainte, un appelant resté sur 3.3.0 échouerait au plan avec un
+      # « unsupported block type » qui ne dit pas qu'il faut monter de version.
+      # Le plancher fait dire à tofu la vraie phrase, au bon moment.
+      version               = ">= 3.10.0"
       configuration_aliases = [minio]
     }
     vault = {

minio/templates/ingress-public.yaml

@@ -5,6 +5,10 @@
 # sa propre signature (SigV4), et un défi HTTP Basic casserait le PUT présigné
 # auquel le navigateur ne peut pas répondre.
 #
+# ⚠ Et PAS de `localIp@file` non plus : sur un routeur `.fr`, ce middleware
+# laisserait entrer Internet entier (le tunnel se présente en 10.42.x.x, qui est
+# dans son `sourceRange`). Mesuré : doc/ce-que-traefik-voit.md §3.
+#
 # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
 apiVersion: networking.k8s.io/v1
 kind: Ingress

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

plausible/plausibleValues.yaml

@@ -61,6 +61,8 @@ ingressRoute:
   rule: Host(`analytics.arcodange.lab`)
   # -- List of [middleware objects](https://doc.traefik.io/traefik/routing/providers/kubernetes-crd/#kind-middleware) for the ingress route.
   middlewares:
+    # ⚠ Valable parce que la règle ci-dessus est en `.lab` (le client arrive en direct
+    # sur 192.168.1.201). À NE PAS recopier sur un hôte `.fr` : cf. doc/ce-que-traefik-voit.md §3.
     - name: localIp@file
   # -- Use an existing secret containing the TLS certificate.
   tlsSecretName: ''