arcodangeandClaude Opus 5
ec71571b98
Helm Charts / Detect changed charts (push) Successful in 16s
Helm Charts / Detect changed charts (pull_request) Successful in 16s
MinIO / Auth with gitea for vault (pull_request) Failing after 8m32s
MinIO / Tofu - minio IAC (pull_request) Has been skipped
MinIO / Auth with gitea for vault (push) Failing after 8m31s
MinIO / Tofu - minio IAC (push) Has been skipped
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) Has been cancelled
Hashicorp Vault / Tofu - Vault IAC (push) Has been cancelled
Helm Charts / Library charts tool (pull_request) Has been skipped
Hashicorp Vault / Auth with gitea for vault (pull_request) Failing after 8m32s
Hashicorp Vault / Tofu - Vault IAC (pull_request) Has been skipped
Helm Charts / Application charts pgcat (pull_request) Has been skipped
« Les buckets sont à déclarer dans le repo de kadans-api. On ne va pas modifier le repo tools à chaque changement d'application. Chacun son périmètre. Tools peut proposer un module pour standardiser la déclaration de buckets à la limite, mais c'est tout. » (fondateur, 26/07) C'est une erreur de fond de ma part : j'avais fait de `tools` le PROPRIÉTAIRE de déclarations qui appartiennent aux applications. À ce rythme, chaque nouveau bucket de n'importe quelle app devenait une PR sur l'infra partagée. CE QUI CHANGE. `consumers.tf` disparaît, et la liste de buckets du chart se vide. À la place, un module réutilisable `iac/modules/minio_app` : une app lui donne son nom et ses buckets, et reçoit des buckets privés, un compte de service qui ne peut rien toucher d'autre, et ses clés dans `kvv2/minio/<app>`. L'OBSTACLE, ET SA RÉPONSE. Déclarer ses buckets depuis son propre dépôt suppose des droits d'ADMINISTRATION sur MinIO. Confier le root serait absurde : il lit et écrit tous les objets de toutes les apps. `tools` fournit donc un compte PROVISIONNEUR aux droits minimaux — créer un bucket, une politique, un compte de service — et AUCUN droit sur les objets. Une app compromise pourrait créer des buckets (une nuisance), pas lire les vidéos d'une autre. Le root, lui, ne sort toujours pas de ce pipeline. Le rôle CI de chaque app gagne la lecture de `kvv2/data/minio/provisioner` dans `app_policy` — générique, et c'est exactement le genre de standardisation qui appartient au dépôt commun. ⚠ CE QUE JE N'AI PAS PU PROUVER : les noms d'actions d'administration MinIO de la politique du provisionneur viennent de la documentation, pas d'un essai — je n'ai pas d'identifiants admin en main. Le premier `apply` les confirmera ou les corrigera. C'est le seul point non vérifié de cette PR, et il est signalé dans le code à l'endroit exact. tofu fmt propre · tofu validate réussi sur minio/iac ET hashicorp-vault/iac. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
57 lines
2.1 KiB
Markdown
57 lines
2.1 KiB
Markdown
# `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.
|