fix(minio) — déclarer minio dans la liste centrale des applications Vault
Helm Charts / Application charts pgcat (pull_request) Has been skipped
Helm Charts / Detect changed charts (push) Successful in 1m6s
Helm Charts / Detect changed charts (pull_request) Successful in 24s
Hashicorp Vault / Auth with gitea for vault (push) Failing after 8m38s
Hashicorp Vault / Tofu - Vault IAC (push) Has been skipped
Helm Charts / Library charts tool (pull_request) Has been skipped
Helm Charts / Library charts tool (push) Has been skipped
Hashicorp Vault / Tofu - Vault IAC (pull_request) Has been skipped
Hashicorp Vault / Auth with gitea for vault (pull_request) Failing after 8m40s
Helm Charts / Application charts pgcat (push) Has been skipped

CI en échec sur le workflow MinIO : role "gitea_cicd_minio" could not be found.

Diagnostic : les rôles CI gitea_cicd_<app> ne naissent PAS dans l'IaC de
l'application — ils viennent du module app_policy, appliqué centralement par
hashicorp-vault/iac pour chaque entrée de terraform.tfvars. J'avais posé
minio/iac (qui s'authentifie AVEC ce rôle) sans alimenter la liste : le run
tentait donc de s'authentifier avec un rôle que personne n'avait créé. Amorçage
circulaire, entièrement de mon fait.

- hashicorp-vault/iac/terraform.tfvars : minio ajouté aux applications, avec
  service_account_namespaces = ["tools"] comme crowdsec et plausible ;
- .gitea/workflows/vault.yaml : les triggers couvrent désormais *.tfvars en
  plus de *.tf. C'est là que vit la liste des applications : sans ça, ajouter
  une app ne déclenchait jamais la création de son rôle — le piège qui vient
  de mordre. Les ancres YAML des triggers sont retirées au passage (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) ;
- minio/README.md : l'ordre de mise en service dit maintenant les DEUX étapes
  et nomme l'erreur exacte à laquelle on s'expose en les inversant.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
This commit is contained in:
2026-07-25 18:23:02 +02:00
co-authored by Claude Opus 5
parent 2202e7bbfe
commit d146affbcd
3 changed files with 34 additions and 11 deletions
+16 -8
View File
@@ -34,13 +34,21 @@ SA portant le nom de l'app : un seul SA, rien à réconcilier.
## Première mise en service
1. **Appliquer l'IaC** — crée le rôle Vault et génère le mot de passe root :
workflow `MinIO` (déclenchable à la main), ou `tofu apply` dans `minio/iac`.
2. **ArgoCD** synchronise l'application (déclarée dans `chart/values.yaml`).
3. Vérifier : `kubectl -n tools get vaultstaticsecret minio` (secret matérialisé)
puis `kubectl -n tools get pods -l app=minio`.
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]
> L'ordre compte : 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.
> 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.