arcodangeandClaude Opus 5
91a0f09b49
Helm Charts / Detect changed charts (pull_request) Successful in 15s
Helm Charts / Detect changed charts (push) Successful in 15s
Helm Charts / Library charts tool (push) Has been cancelled
Helm Charts / Application charts pgcat (push) Has been cancelled
Hashicorp Vault / Auth with gitea for vault (push) Failing after 8m35s
Hashicorp Vault / Tofu - Vault IAC (push) Has been skipped
MinIO / Auth with gitea for vault (pull_request) Failing after 8m32s
MinIO / Tofu - minio IAC (pull_request) Has been skipped
Helm Charts / Library charts tool (pull_request) Has been skipped
Hashicorp Vault / Auth with gitea for vault (pull_request) Failing after 8m36s
Hashicorp Vault / Tofu - Vault IAC (pull_request) Has been skipped
Helm Charts / Application charts pgcat (pull_request) Has been skipped
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
139 lines
7.5 KiB
Markdown
139 lines
7.5 KiB
Markdown
# MinIO — stockage objet S3 du homelab
|
||
|
||
Brique **partagée** du namespace `tools`, au même titre que pgbouncer ou
|
||
clickhouse. Le serveur vit ici ; les buckets, quotas et identifiants d'une
|
||
application vivent avec cette application.
|
||
|
||
## Premier consommateur : Kadans
|
||
|
||
- [ADR-012](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/012-video-storage-minio-first.md)
|
||
« MinIO local d'abord » — bascule vers Cloudflare R2 prévue aux seuils :
|
||
100+ utilisateurs actifs, > 10 To/mois, ou dispersion géographique.
|
||
- [ADR-013](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/013-video-storage-opfs-local-first.md)
|
||
le gratuit est **local-first** (la vidéo ne quitte pas l'appareil) ; MinIO sert
|
||
les **paliers payants**.
|
||
- [ADR-018](https://gitea.arcodange.lab/arcodange/kadans/src/branch/main/docs/adr/018-qualite-video-au-transfert.md)
|
||
ce qui transite est **dérivé** (aperçu 240p ~50 Ko, travail 360p ~3,4 Mo/min) —
|
||
le master reste chez l'utilisateur. D'où le dimensionnement ci-dessous.
|
||
|
||
## Ce que ce chart pose
|
||
|
||
| | |
|
||
|---|---|
|
||
| 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` (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) |
|
||
| 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
|
||
chart amont) parce que le module Vault `app_roles` borne l'authentification au
|
||
SA portant le nom de l'app : un seul SA, rien à réconcilier.
|
||
|
||
## Première mise en service
|
||
|
||
L'ordre compte, et il compte **deux fois** :
|
||
|
||
1. **Workflow `Hashicorp Vault`** — MinIO doit d'abord figurer dans
|
||
`hashicorp-vault/iac/terraform.tfvars` (c'est fait) : c'est **là** que naît
|
||
le rôle CI `gitea_cicd_minio`, et non dans `minio/iac`. Sans cette étape,
|
||
le workflow MinIO échoue sur
|
||
`role "gitea_cicd_minio" could not be found` — il essaie de s'authentifier
|
||
avec un rôle que personne n'a encore créé.
|
||
2. **Workflow `MinIO`** — applique `minio/iac` : rôle Kubernetes pour le Vault
|
||
Secrets Operator, et **génération** du mot de passe root dans
|
||
`kvv2/minio/config`.
|
||
3. **ArgoCD** synchronise l'application (déclarée dans `chart/values.yaml`).
|
||
4. Vérifier : `kubectl -n tools get vaultstaticsecret minio` (secret
|
||
matérialisé) puis `kubectl -n tools get pods -l app=minio`.
|
||
|
||
> [!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
|
||
|
||
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** — *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
|
||
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.
|