From d146affbcdac2c436aaf8d323edaf05c4ba8f07d Mon Sep 17 00:00:00 2001 From: Gabriel Radureau Date: Sat, 25 Jul 2026 18:23:02 +0200 Subject: [PATCH] =?UTF-8?q?fix(minio)=20=E2=80=94=20d=C3=A9clarer=20minio?= =?UTF-8?q?=20dans=20la=20liste=20centrale=20des=20applications=20Vault?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CI en échec sur le workflow MinIO : role "gitea_cicd_minio" could not be found. Diagnostic : les rôles CI gitea_cicd_ 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 Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA --- .gitea/workflows/vault.yaml | 17 ++++++++++++++--- hashicorp-vault/iac/terraform.tfvars | 4 ++++ minio/README.md | 24 ++++++++++++++++-------- 3 files changed, 34 insertions(+), 11 deletions(-) diff --git a/.gitea/workflows/vault.yaml b/.gitea/workflows/vault.yaml index 3d0ba45..51fb1e1 100644 --- a/.gitea/workflows/vault.yaml +++ b/.gitea/workflows/vault.yaml @@ -2,12 +2,23 @@ # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml name: Hashicorp Vault -on: #[push,pull_request] +# ⚠ 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_) vit dans terraform.tfvars — l'oublier, c'est ajouter +# une app sans jamais créer son rôle. +on: workflow_dispatch: {} - push: &vaultPaths + push: paths: - 'hashicorp-vault/**/*.tf' - pull_request: *vaultPaths + - '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: diff --git a/hashicorp-vault/iac/terraform.tfvars b/hashicorp-vault/iac/terraform.tfvars index 80ea3f5..b0921e7 100644 --- a/hashicorp-vault/iac/terraform.tfvars +++ b/hashicorp-vault/iac/terraform.tfvars @@ -19,6 +19,10 @@ applications = [ name = "plausible" service_account_namespaces = ["tools"] }, + { + name = "minio" + service_account_namespaces = ["tools"] + }, { name = "prospection" }, { name = "kadans" }, ] diff --git a/minio/README.md b/minio/README.md index 7b80ae0..d237c14 100644 --- a/minio/README.md +++ b/minio/README.md @@ -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. -- 2.54.0