Le canal F44 du dépôt prospection (alertes email des job boards → offres Indeed, APEC,
Welcome to the Jungle) est mort en silence depuis sa mise en service : 2 offres arrivées,
et ce sont des fixtures de test.
Deux causes distinctes. La première — aucune alerte souscrite — est un geste opérateur. La
seconde est ici : la policy d'exécution prospection n'accorde que
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 un 403 — donc même en souscrivant une alerte
Indeed demain, rien ne serait lu.
Comment je l'ai trouvé
Le runbook prospection/ALERTES.md affirme : « La policy prospection (iac/) accorde déjà la
lecture de ce chemin. » En allant vérifier avant de m'appuyer dessus : c'était une intention,
jamais appliquée. Rien dans modules/app_policy ne l'accorde, et prospection/iac/main.tf
ne crée qu'un rôle k8s-auth. Le document sera corrigé côté prospection.
Pourquoi cette forme
kv_read_paths existe exactement pour ce cas, et erp en donne le précédent dans ce même
fichier (kvv2/data/longhorn/gcs-backup, creds GCS partagés avec un autre propriétaire).
lecture seule, ["read", "list"] par construction du module ;
chemin exact, pas de glob : la règle ne peut ouvrir que ce document-là, pas kvv1/zoho/* ;
l'alternative aurait été de recopier le secret sous kvv2/prospection/zoho — une
deuxième copie du même identifiant, à faire tourner à la main, pour deux applications.
Vérification
tofu fmt -check -diff : conforme, aucun écart ;
le diff est de 6 lignes, sur le seul objet prospection de var.applications.
Appliqué par le workflow vault.yaml au merge. Il faudra ensuite, côté prospection, que kvv1/zoho/self_client contienne bien REFRESH_TOKEN et DC — cms n'utilise que CLIENT_ID et CLIENT_SECRET, donc les deux autres champs sont peut-être absents.
## Ce que ça débloque
Le canal **F44** du dépôt `prospection` (alertes email des job boards → offres Indeed, APEC,
Welcome to the Jungle) est **mort en silence depuis sa mise en service** : 2 offres arrivées,
et ce sont des fixtures de test.
Deux causes distinctes. La première — aucune alerte souscrite — est un geste opérateur. **La
seconde est ici** : la policy d'exécution `prospection` n'accorde que
```
kvv2/data/prospection/*
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 un **403** — donc même en souscrivant une alerte
Indeed demain, rien ne serait lu.
## Comment je l'ai trouvé
Le runbook `prospection/ALERTES.md` affirme : « La policy `prospection` (iac/) accorde déjà la
lecture de ce chemin. » En allant vérifier avant de m'appuyer dessus : **c'était une intention,
jamais appliquée**. Rien dans `modules/app_policy` ne l'accorde, et `prospection/iac/main.tf`
ne crée qu'un rôle k8s-auth. Le document sera corrigé côté `prospection`.
## Pourquoi cette forme
`kv_read_paths` existe exactement pour ce cas, et **`erp` en donne le précédent** dans ce même
fichier (`kvv2/data/longhorn/gcs-backup`, creds GCS partagés avec un autre propriétaire).
- **lecture seule**, `["read", "list"]` par construction du module ;
- **chemin exact, pas de glob** : la règle ne peut ouvrir que ce document-là, pas `kvv1/zoho/*` ;
- l'alternative aurait été de **recopier le secret** sous `kvv2/prospection/zoho` — une
deuxième copie du même identifiant, à faire tourner à la main, pour deux applications.
## Vérification
- `tofu fmt -check -diff` : conforme, aucun écart ;
- le diff est de 6 lignes, sur le seul objet `prospection` de `var.applications`.
Appliqué par le workflow `vault.yaml` au merge. Il faudra ensuite, côté `prospection`, que
`kvv1/zoho/self_client` contienne bien `REFRESH_TOKEN` et `DC` — `cms` n'utilise que
`CLIENT_ID` et `CLIENT_SECRET`, donc les deux autres champs sont peut-être absents.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01KV3wEnmAukPaHrxHFWhk7Q
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
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
Arbitrage du fondateur : « l'idée est de fournir des credentials propres à prospection et de
les lui fournir là où il a accès dans le Vault. On ne peut pas sans arrêt modifier le socle
commun tools. »
C'est le bon appel, et cette PR est exactement ce qu'il faut éviter. Élargir la policy du
socle partagé à chaque besoin d'une app :
fait grossir tools d'exceptions qui n'appartiennent qu'à ses consommateurs — un socle
qu'on modifie à chaque cas particulier cesse d'être un socle ;
couple deux applications par un secret. Faire tourner l'identifiant Zoho de cms
casserait prospection sans que rien ne le relie visiblement, et révoquer l'accès de l'une
obligerait à raisonner sur l'autre ;
crée un précédent : la prochaine app aura le même besoin, et la liste s'allongera.
kv_read_paths garde son sens pour ce qu'il vise — un secret réellement possédé par une
autre app et non duplicable, comme les creds GCS de sauvegarde de erp. Ce n'est pas le cas
ici : rien n'empêche prospection d'avoir son propre self-client Zoho.
La voie retenue
Un identifiant dédié dans kvv2/prospection/zoho, c'est-à-dire là où la policy actuelle
donne déjà accès — donc zéro changement dans ce dépôt. Bénéfice au passage : rotation et
révocation indépendantes de cms, et moindre privilège réel plutôt que par convention.
## Abandonnée — mauvaise réponse au bon problème
Arbitrage du fondateur : *« l'idée est de fournir des credentials propres à prospection et de
les lui fournir là où il a accès dans le Vault. On ne peut pas sans arrêt modifier le socle
commun tools. »*
C'est le bon appel, et cette PR est exactement ce qu'il faut éviter. Élargir la policy du
socle partagé à chaque besoin d'une app :
- fait grossir `tools` d'exceptions qui n'appartiennent qu'à ses consommateurs — un socle
qu'on modifie à chaque cas particulier cesse d'être un socle ;
- **couple deux applications par un secret**. Faire tourner l'identifiant Zoho de `cms`
casserait `prospection` sans que rien ne le relie visiblement, et révoquer l'accès de l'une
obligerait à raisonner sur l'autre ;
- crée un précédent : la prochaine app aura le même besoin, et la liste s'allongera.
`kv_read_paths` garde son sens pour ce qu'il vise — un secret réellement **possédé par une
autre app** et non duplicable, comme les creds GCS de sauvegarde de `erp`. Ce n'est pas le cas
ici : rien n'empêche `prospection` d'avoir **son propre self-client Zoho**.
## La voie retenue
Un identifiant dédié dans `kvv2/prospection/zoho`, c'est-à-dire **là où la policy actuelle
donne déjà accès** — donc zéro changement dans ce dépôt. Bénéfice au passage : rotation et
révocation indépendantes de `cms`, et moindre privilège réel plutôt que par convention.
Suite dans **prospection #23**.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ce que ça débloque
Le canal F44 du dépôt
prospection(alertes email des job boards → offres Indeed, APEC,Welcome to the Jungle) est mort en silence depuis sa mise en service : 2 offres arrivées,
et ce sont des fixtures de test.
Deux causes distinctes. La première — aucune alerte souscrite — est un geste opérateur. La
seconde est ici : la policy d'exécution
prospectionn'accorde queOr les identifiants Zoho sont partagés avec
cmset vivent àkvv1/zoho/self_client,hors du préfixe de l'app. Le VSO y prendrait un 403 — donc même en souscrivant une alerte
Indeed demain, rien ne serait lu.
Comment je l'ai trouvé
Le runbook
prospection/ALERTES.mdaffirme : « La policyprospection(iac/) accorde déjà lalecture de ce chemin. » En allant vérifier avant de m'appuyer dessus : c'était une intention,
jamais appliquée. Rien dans
modules/app_policyne l'accorde, etprospection/iac/main.tfne crée qu'un rôle k8s-auth. Le document sera corrigé côté
prospection.Pourquoi cette forme
kv_read_pathsexiste exactement pour ce cas, eterpen donne le précédent dans ce mêmefichier (
kvv2/data/longhorn/gcs-backup, creds GCS partagés avec un autre propriétaire).["read", "list"]par construction du module ;kvv1/zoho/*;kvv2/prospection/zoho— unedeuxième copie du même identifiant, à faire tourner à la main, pour deux applications.
Vérification
tofu fmt -check -diff: conforme, aucun écart ;prospectiondevar.applications.Appliqué par le workflow
vault.yamlau merge. Il faudra ensuite, côtéprospection, quekvv1/zoho/self_clientcontienne bienREFRESH_TOKENetDC—cmsn'utilise queCLIENT_IDetCLIENT_SECRET, donc les deux autres champs sont peut-être absents.🤖 Generated with Claude Code
https://claude.ai/code/session_01KV3wEnmAukPaHrxHFWhk7Q
Abandonnée — mauvaise réponse au bon problème
Arbitrage du fondateur : « l'idée est de fournir des credentials propres à prospection et de
les lui fournir là où il a accès dans le Vault. On ne peut pas sans arrêt modifier le socle
commun tools. »
C'est le bon appel, et cette PR est exactement ce qu'il faut éviter. Élargir la policy du
socle partagé à chaque besoin d'une app :
toolsd'exceptions qui n'appartiennent qu'à ses consommateurs — un soclequ'on modifie à chaque cas particulier cesse d'être un socle ;
cmscasserait
prospectionsans que rien ne le relie visiblement, et révoquer l'accès de l'uneobligerait à raisonner sur l'autre ;
kv_read_pathsgarde son sens pour ce qu'il vise — un secret réellement possédé par uneautre app et non duplicable, comme les creds GCS de sauvegarde de
erp. Ce n'est pas le casici : rien n'empêche
prospectiond'avoir son propre self-client Zoho.La voie retenue
Un identifiant dédié dans
kvv2/prospection/zoho, c'est-à-dire là où la policy actuelledonne déjà accès — donc zéro changement dans ce dépôt. Bénéfice au passage : rotation et
révocation indépendantes de
cms, et moindre privilège réel plutôt que par convention.Suite dans prospection #23.
Pull request closed