feat(vault) : autoriser prospection à lire les identifiants Zoho partagés #34
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  arcodangeandClaude Opus 5
|
d60e943301 |
fix: réécrire le fichier en clair — l'API l'avait rempli du base64 littéral
Helm Charts / Detect changed charts (pull_request) Successful in 16s
Helm Charts / Library charts tool (pull_request) Skipped
Helm Charts / Application charts chart (pull_request) Skipped
Helm Charts / Application charts crowdsec (pull_request) Skipped
Helm Charts / Application charts grafana (pull_request) Skipped
Helm Charts / Application charts minio (pull_request) Skipped
Helm Charts / Application charts pgbouncer (pull_request) Skipped
Helm Charts / Application charts pgcat (pull_request) Skipped
Helm Charts / Application charts prometheus (pull_request) Skipped
Helm Charts / Application charts redis (pull_request) Skipped
Helm Charts / Application charts hashicorp-vault (pull_request) Failing after 6s
Le premier commit a envoyé le contenu encodé en base64 : l'API Gitea ne le décode pas, elle écrit ce qu'on lui donne. Le fichier contenait donc une ligne de base64 à la place du HCL. Trouvé en relisant le diff de la PR, dont le compte (1 ajout, 28 suppressions) ne correspondait pas au changement de six lignes annoncé. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01KV3wEnmAukPaHrxHFWhk7Q |
||
|
arcodangeandClaude Opus 5
|
a296b96d0b |
feat(vault) : autoriser prospection à lire les identifiants Zoho partagés
Helm Charts / Library charts tool (pull_request) Canceled after 0s
Helm Charts / Application charts chart (pull_request) Canceled after 0s
Helm Charts / Application charts crowdsec (pull_request) Canceled after 0s
Helm Charts / Application charts grafana (pull_request) Canceled after 0s
Helm Charts / Application charts hashicorp-vault (pull_request) Canceled after 0s
Helm Charts / Application charts minio (pull_request) Canceled after 0s
Helm Charts / Application charts pgbouncer (pull_request) Canceled after 0s
Helm Charts / Application charts pgcat (pull_request) Canceled after 0s
Helm Charts / Application charts prometheus (pull_request) Canceled after 0s
Helm Charts / Application charts redis (pull_request) Canceled after 0s
Helm Charts / Detect changed charts (pull_request) Canceled after 57s
Le canal F44 (alertes email des job boards) est mort en silence depuis sa mise en service. Deux causes distinctes, et celle-ci est la seconde : la policy d'exécution `prospection` n'accorde que `kvv2/data/prospection/*` et `kvv2/data/minio/prospection/*`. Or les identifiants Zoho sont PARTAGÉS avec cms et vivent à `kvv1/zoho/self_client` — hors du préfixe de l'app. Le VSO y prendrait donc un 403. Le runbook du dépôt prospection (ALERTES.md) affirmait que « la policy prospection accorde déjà la lecture de ce chemin ». C'était une intention, jamais appliquée : rien dans ce module ne l'accordait. Le document sera corrigé côté prospection. `kv_read_paths` existe précisément pour ce cas, et `erp` en donne le précédent (`kvv2/data/longhorn/gcs-backup`, creds GCS partagés). Lecture seule, chemin exact, pas de glob : la règle ne peut ouvrir que ce document-là. L'alternative aurait été de recopier le secret sous `kvv2/prospection/zoho` — c'est-à-dire d'en créer une deuxième copie à faire tourner à la main, pour deux applications. Vérifié : `tofu fmt -check` conforme. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01KV3wEnmAukPaHrxHFWhk7Q |