maximus/vps-health-api
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Retirer les secrets buildtime de l app Coolify et revoquer la cle PayPerQ sans consommateur #29

New issue
Closed
opened 2026-09-27 12:37:32 +00:00 by maximus · 6 comments
maximus commented 2026-09-27 12:37:32 +00:00
Owner
Copy link

Contexte

L'app Coolify vps-health-api (uuid u8000gsg044wsk0oo0w884ok) porte trois secrets en is_buildtime=true. Coolify les passe en build args : leur valeur finit en clair dans application_deployment_queues.logs a chaque deploiement (la-compagnie-maximus/docs/coolify-ops.md, section « Secrets en buildtime »). Drapeaux verifies le 2026-09-27 via l'API Coolify (aucune valeur lue) :

Variable Row runtime buildtime Nature
PAYPERQ_API_KEY production true true Cle PPQ vps-health-20260419, aucun consommateur
CHAT_DATABASE_URL production true true Nom de variable de la-suite-booking (role chat_reader)
CHAT_MODEL production true true Non secret, orphelin
HEALTH_TOKEN preview true true Row production correcte

(PORT et REPORTS_DIR sont en buildtime mais ne sont pas des secrets : hors scope.)

Diagnostic

  • PAYPERQ_API_KEY : payperq-ops.md enregistre vps-health-api comme proprietaire d'une cle dediee pour une « feature chat de l'API sante ». L'entree du journal secret-rotation-ops.md du 2026-04-19 (#109, Vague 2) decrit sa creation comme « reparation collaterale ». Or le code n'a jamais eu de chat : git log --all -S PAYPERQ et -S CHAT_DATABASE_URL sont vides, aucune reference dans *.js, *.sh, Dockerfile. La cle est vivante, facturable, sans consommateur : revoquer, ne pas tourner.
  • CHAT_DATABASE_URL / CHAT_MODEL : noms utilises par la-suite-booking (lib/chat-sql.ts, role chat_reader). Aucune autre app Coolify ne porte ces cles. Le role chat_reader a ete DROP le 2026-08-12 lors du demantelement de booking : si l'URL le vise, l'identifiant est mort. A confirmer (voir etape 1).
  • HEALTH_TOKEN preview : aucun deploiement preview n'a jamais eu lieu (0 pull_request_id sur les deploiements listes). La row n'a donc jamais fuite : correction du drapeau seulement, sans rotation.
  • Logs : l'API ne liste plus que 2 deploiements pour cette app (2026-09-25, 2026-09-27) ; tous deux ont pu ecrire PAYPERQ_API_KEY et CHAT_DATABASE_URL en clair.
  • L'API Coolify masque les valeurs pour ce token : une valeur vide dans GET /envs ne prouve rien. Les verifications de contenu passent par le conteneur.

Travail a faire

  1. Verifs VPS (lecture seule, sorties reduites aux metadonnees, jamais de valeur) :
    • dans le conteneur : PAYPERQ_API_KEY renseignee ou non (longueur), CHAT_DATABASE_URL -> utilisateur + hote + base seulement ;
    • sur le PostgreSQL partage (zgkgc8soo8k4k44woo00ckg8) : chat_reader (ou l'utilisateur trouve) present dans pg_roles ?
    • coolify-db : lignes de application_deployment_queues de cette app dont logs contient PAYPERQ_API_KEY / CHAT_DATABASE_URL.
    • Si l'utilisateur de CHAT_DATABASE_URL est un role vivant : repasser en rotation (ALTER USER ... PASSWORD) et identifier son consommateur legitime avant toute suppression.
  2. Supprimer PAYPERQ_API_KEY, CHAT_DATABASE_URL, CHAT_MODEL de l'app (les 2 rows de chacune).
  3. Passer la row preview de HEALTH_TOKEN en is_buildtime=false ; verifier par (key, is_preview), pas par key.
  4. Revoquer la cle PPQ vps-health-20260419 sans la remplacer (DELETE /keys/{id} avec le credit-id depuis le gestionnaire de mots de passe, ou dashboard ppq.ai). Voir payperq-ops.md.
  5. Dette la-suite-booking, meme session (le credit-id est en main) :
    • revoquer la cle PayPerQ de booking ;
    • revoquer le token Forgejo vps-deploy-booking-2026-04-14 (id 12) via l'UI Forgejo (l'API refuse sans write:user) ;
    • revoquer la cle Geoapify (dashboard myprojects.geoapify.com, pas d'API) ;
    • vercel env rm PAYPERQ_KEY_BOOKING production ;
    • une fois les trois revocations faites : shred -u /root/booking-env-preserved-20260812 sur le VPS.
  6. Purger les logs de deploiement de cette app dans application_deployment_queues (coolify-db), apres les revocations.
  7. Redeployer (trigger manuel, pas d'auto-deploy) et verifier : GET /envs ne montre plus aucun secret en buildtime=true ; les 5 routes de lecture repondent 200.
  8. Docs la-compagnie-maximus :
    • docs/payperq-ops.md : retirer la ligne vps-health-api du registre ; noter la revocation de la cle booking (retirer l'avertissement « n'est pas revoquee ») ;
    • docs/secret-rotation-ops.md : entree de journal datee pour les revocations, et rectification datee de la « reparation collaterale » du 2026-04-19 (le chat n'a jamais existe) sans reecrire l'entree historique ; corriger la note « Important (collateral) » (ligne ~324) ;
    • docs/coolify-ops.md : tableau « Secrets en buildtime » a jour pour vps-health-api.

Hors scope

Criteres d'acceptation

  • Verifs VPS de l'etape 1 consignees en commentaire (metadonnees seulement)
  • PAYPERQ_API_KEY, CHAT_DATABASE_URL, CHAT_MODEL absentes de l'app (2 rows chacune)
  • HEALTH_TOKEN preview en is_buildtime=false
  • Cle PPQ vps-health-20260419 revoquee (absente de GET /keys)
  • Cle PPQ booking, token Forgejo id 12 et cle Geoapify revoques ; /root/booking-env-preserved-20260812 detruit ; PAYPERQ_KEY_BOOKING retiree de Vercel
  • Logs de deploiement de cette app purges apres les revocations
  • Redeploy : /envs propre, 5 routes de lecture en 200
  • Docs payperq-ops / secret-rotation-ops / coolify-ops a jour

Complexite

Medium, entierement manuelle (credit-id PayPerQ, sudo VPS, dashboards Geoapify / Forgejo / ppq.ai). Hors autopilot. Aucun code dans ce depot.

## Contexte L'app Coolify `vps-health-api` (uuid `u8000gsg044wsk0oo0w884ok`) porte trois secrets en `is_buildtime=true`. Coolify les passe en build args : leur valeur finit **en clair** dans `application_deployment_queues.logs` a chaque deploiement (`la-compagnie-maximus/docs/coolify-ops.md`, section « Secrets en buildtime »). Drapeaux verifies le 2026-09-27 via l'API Coolify (aucune valeur lue) : | Variable | Row | runtime | buildtime | Nature | |---|---|---|---|---| | `PAYPERQ_API_KEY` | production | true | **true** | Cle PPQ `vps-health-20260419`, **aucun consommateur** | | `CHAT_DATABASE_URL` | production | true | **true** | Nom de variable de la-suite-booking (role `chat_reader`) | | `CHAT_MODEL` | production | true | true | Non secret, orphelin | | `HEALTH_TOKEN` | preview | true | **true** | Row production correcte | (`PORT` et `REPORTS_DIR` sont en buildtime mais ne sont pas des secrets : hors scope.) ### Diagnostic - **`PAYPERQ_API_KEY`** : `payperq-ops.md` enregistre vps-health-api comme proprietaire d'une cle dediee pour une « feature chat de l'API sante ». L'entree du journal `secret-rotation-ops.md` du 2026-04-19 (#109, Vague 2) decrit sa creation comme « reparation collaterale ». Or le code n'a jamais eu de chat : `git log --all -S PAYPERQ` et `-S CHAT_DATABASE_URL` sont vides, aucune reference dans `*.js`, `*.sh`, `Dockerfile`. La cle est vivante, facturable, sans consommateur : **revoquer, ne pas tourner**. - **`CHAT_DATABASE_URL` / `CHAT_MODEL`** : noms utilises par la-suite-booking (`lib/chat-sql.ts`, role `chat_reader`). Aucune autre app Coolify ne porte ces cles. Le role `chat_reader` a ete `DROP` le 2026-08-12 lors du demantelement de booking : si l'URL le vise, l'identifiant est mort. **A confirmer** (voir etape 1). - **`HEALTH_TOKEN` preview** : aucun deploiement preview n'a jamais eu lieu (0 `pull_request_id` sur les deploiements listes). La row n'a donc jamais fuite : correction du drapeau seulement, sans rotation. - **Logs** : l'API ne liste plus que 2 deploiements pour cette app (2026-09-25, 2026-09-27) ; tous deux ont pu ecrire `PAYPERQ_API_KEY` et `CHAT_DATABASE_URL` en clair. - L'API Coolify masque les valeurs pour ce token : une valeur vide dans `GET /envs` ne prouve rien. Les verifications de contenu passent par le conteneur. ## Travail a faire 1. [ ] **Verifs VPS** (lecture seule, sorties reduites aux metadonnees, jamais de valeur) : - dans le conteneur : `PAYPERQ_API_KEY` renseignee ou non (longueur), `CHAT_DATABASE_URL` -> utilisateur + hote + base seulement ; - sur le PostgreSQL partage (`zgkgc8soo8k4k44woo00ckg8`) : `chat_reader` (ou l'utilisateur trouve) present dans `pg_roles` ? - `coolify-db` : lignes de `application_deployment_queues` de cette app dont `logs` contient `PAYPERQ_API_KEY` / `CHAT_DATABASE_URL`. - **Si l'utilisateur de `CHAT_DATABASE_URL` est un role vivant** : repasser en rotation (`ALTER USER ... PASSWORD`) et identifier son consommateur legitime avant toute suppression. 2. [ ] Supprimer `PAYPERQ_API_KEY`, `CHAT_DATABASE_URL`, `CHAT_MODEL` de l'app (les 2 rows de chacune). 3. [ ] Passer la row preview de `HEALTH_TOKEN` en `is_buildtime=false` ; verifier par `(key, is_preview)`, pas par `key`. 4. [ ] **Revoquer** la cle PPQ `vps-health-20260419` sans la remplacer (`DELETE /keys/{id}` avec le `credit-id` depuis le gestionnaire de mots de passe, ou dashboard ppq.ai). Voir `payperq-ops.md`. 5. [ ] **Dette la-suite-booking, meme session** (le credit-id est en main) : - revoquer la cle PayPerQ de booking ; - revoquer le token Forgejo `vps-deploy-booking-2026-04-14` (id 12) via l'UI Forgejo (l'API refuse sans `write:user`) ; - revoquer la cle Geoapify (dashboard `myprojects.geoapify.com`, pas d'API) ; - `vercel env rm PAYPERQ_KEY_BOOKING production` ; - une fois les trois revocations faites : `shred -u /root/booking-env-preserved-20260812` sur le VPS. 6. [ ] Purger les logs de deploiement de cette app dans `application_deployment_queues` (`coolify-db`), **apres** les revocations. 7. [ ] Redeployer (trigger manuel, pas d'auto-deploy) et verifier : `GET /envs` ne montre plus aucun secret en `buildtime=true` ; les 5 routes de lecture repondent 200. 8. [ ] Docs `la-compagnie-maximus` : - `docs/payperq-ops.md` : retirer la ligne vps-health-api du registre ; noter la revocation de la cle booking (retirer l'avertissement « n'est pas revoquee ») ; - `docs/secret-rotation-ops.md` : entree de journal datee pour les revocations, et **rectification datee** de la « reparation collaterale » du 2026-04-19 (le chat n'a jamais existe) sans reecrire l'entree historique ; corriger la note « Important (collateral) » (ligne ~324) ; - `docs/coolify-ops.md` : tableau « Secrets en buildtime » a jour pour vps-health-api. ## Hors scope - Balayage des autres apps Coolify : maximus/la-compagnie-maximus#170. - `PORT` / `REPORTS_DIR` en buildtime : non secrets. ## Criteres d'acceptation - [ ] Verifs VPS de l'etape 1 consignees en commentaire (metadonnees seulement) - [ ] `PAYPERQ_API_KEY`, `CHAT_DATABASE_URL`, `CHAT_MODEL` absentes de l'app (2 rows chacune) - [ ] `HEALTH_TOKEN` preview en `is_buildtime=false` - [ ] Cle PPQ `vps-health-20260419` revoquee (absente de `GET /keys`) - [ ] Cle PPQ booking, token Forgejo id 12 et cle Geoapify revoques ; `/root/booking-env-preserved-20260812` detruit ; `PAYPERQ_KEY_BOOKING` retiree de Vercel - [ ] Logs de deploiement de cette app purges apres les revocations - [ ] Redeploy : `/envs` propre, 5 routes de lecture en 200 - [ ] Docs payperq-ops / secret-rotation-ops / coolify-ops a jour ## Complexite Medium, entierement manuelle (credit-id PayPerQ, sudo VPS, dashboards Geoapify / Forgejo / ppq.ai). Hors autopilot. Aucun code dans ce depot.
maximus added the
status:ready
type:security
source:human
 labels 2026-09-27 12:37:32 +00:00
maximus commented 2026-09-27 13:51:37 +00:00
Author
Owner
Copy link

Archive avant reecriture (/analyze du 2026-09-27).

La premisse « PAYPERQ_API_KEY et CHAT_* sont orphelines, venues d'une autre app » est a moitie fausse. CHAT_DATABASE_URL / CHAT_MODEL portent bien les noms de la-suite-booking. En revanche, PAYPERQ_API_KEY est enregistree dans la-compagnie-maximus/docs/payperq-ops.md comme cle dediee a vps-health-api (vps-health-20260419, creee lors de la « reparation collaterale » de la rotation #109) pour une « feature chat » que le code n'a jamais eue (git log -S PAYPERQ vide). Consequence : il faut une revocation seche, pas une rotation. Le corps est reecrit en consequence.

Corps d'origine

Trois variables de l app Coolify vps-health-api (uuid u8000gsg044wsk0oo0w884ok) sont en is_buildtime=true alors qu elles portent (ou peuvent porter) un secret. Coolify les passe alors en build args, et leur valeur finit en clair dans application_deployment_queues.logs a chaque deploiement. Voir la-compagnie-maximus/docs/coolify-ops.md, section « Secrets en buildtime ».

Releve le 2026-09-27 via l API Coolify (drapeaux seulement, aucune valeur lue) :

Variable Row runtime buildtime
PAYPERQ_API_KEY production true true
CHAT_DATABASE_URL production true true
HEALTH_TOKEN preview true true

La row production de HEALTH_TOKEN est correcte (buildtime=false). CHAT_MODEL, PORT et REPORTS_DIR sont aussi en buildtime mais ne sont pas des secrets.

Constat aggravant : PAYPERQ_API_KEY et CHAT_* sont orphelines

Aucune reference dans le code (grep sur *.js, *.sh, Dockerfile, *.md) : l API est a 0 dependance runtime et n a ni chat ni base de donnees. Ces variables viennent vraisemblablement d une autre app (copie de configuration ?). Elles n ont rien a faire ici, et y etre en buildtime les expose a chaque deploiement de cette app pour aucun benefice.

Premiere observation : 2026-08-18 (commentaire de #16). Depuis, au moins deux deploiements (2026-09-25 et co4k0k8888gow4o84gk8kgkc le 2026-09-26) ont ecrit ces valeurs dans les logs.

Criteres d acceptation

  • Identifier l app proprietaire de PAYPERQ_API_KEY et CHAT_DATABASE_URL (et confirmer qu elle porte ses propres copies) avant toute suppression
  • Supprimer PAYPERQ_API_KEY, CHAT_DATABASE_URL, CHAT_MODEL de l app vps-health-api (les 2 rows de chacune)
  • Passer la row preview de HEALTH_TOKEN en is_buildtime=false (verifier par (key, is_preview), pas par key)
  • Tourner la cle PayPerQ et le mot de passe contenu dans CHAT_DATABASE_URL : elles ont fuite dans les logs, les retirer de l app ne suffit pas. Suivre docs/secret-rotation-ops.md et mettre a jour l app proprietaire
  • Purger les logs de deploiement concernes dans application_deployment_queues (ou documenter pourquoi on ne le fait pas)
  • Redeployer et verifier : GET /envs ne montre plus aucun secret en buildtime=true ; les 5 routes de lecture repondent 200
  • Balayer les autres apps Coolify pour le meme defaut (un secret en buildtime=true, rows preview comprises) et ouvrir une issue par app touchee

Notes

  • Operation manuelle (API Coolify + rotation cote fournisseur) : hors autopilot.
  • Le HEALTH_TOKEN preview n est utilise que si les preview deploys sont actives ; s il porte la meme valeur que la row production, la fuite concerne le token de production. A verifier, et tourner si c est le cas (rotation conjointe avec HOSTS_INGEST_TOKEN, cf. #16).
Archive avant reecriture (/analyze du 2026-09-27). La premisse « `PAYPERQ_API_KEY` et `CHAT_*` sont orphelines, venues d'une autre app » est a moitie fausse. `CHAT_DATABASE_URL` / `CHAT_MODEL` portent bien les noms de la-suite-booking. En revanche, `PAYPERQ_API_KEY` est enregistree dans `la-compagnie-maximus/docs/payperq-ops.md` comme cle **dediee** a vps-health-api (`vps-health-20260419`, creee lors de la « reparation collaterale » de la rotation #109) pour une « feature chat » que le code n'a jamais eue (`git log -S PAYPERQ` vide). Consequence : il faut une revocation seche, pas une rotation. Le corps est reecrit en consequence. <details> <summary>Corps d'origine</summary> Trois variables de l app Coolify `vps-health-api` (uuid `u8000gsg044wsk0oo0w884ok`) sont en `is_buildtime=true` alors qu elles portent (ou peuvent porter) un secret. Coolify les passe alors en build args, et leur valeur finit **en clair** dans `application_deployment_queues.logs` a chaque deploiement. Voir `la-compagnie-maximus/docs/coolify-ops.md`, section « Secrets en buildtime ». Releve le 2026-09-27 via l API Coolify (drapeaux seulement, aucune valeur lue) : | Variable | Row | runtime | buildtime | |---|---|---|---| | `PAYPERQ_API_KEY` | production | true | **true** | | `CHAT_DATABASE_URL` | production | true | **true** | | `HEALTH_TOKEN` | preview | true | **true** | La row production de `HEALTH_TOKEN` est correcte (`buildtime=false`). `CHAT_MODEL`, `PORT` et `REPORTS_DIR` sont aussi en buildtime mais ne sont pas des secrets. ## Constat aggravant : `PAYPERQ_API_KEY` et `CHAT_*` sont orphelines Aucune reference dans le code (`grep` sur `*.js`, `*.sh`, `Dockerfile`, `*.md`) : l API est a 0 dependance runtime et n a ni chat ni base de donnees. Ces variables viennent vraisemblablement d une autre app (copie de configuration ?). Elles n ont rien a faire ici, et y etre en buildtime les expose a chaque deploiement de cette app pour aucun benefice. Premiere observation : 2026-08-18 (commentaire de #16). Depuis, au moins deux deploiements (2026-09-25 et `co4k0k8888gow4o84gk8kgkc` le 2026-09-26) ont ecrit ces valeurs dans les logs. ## Criteres d acceptation - [ ] Identifier l app proprietaire de `PAYPERQ_API_KEY` et `CHAT_DATABASE_URL` (et confirmer qu elle porte ses propres copies) avant toute suppression - [ ] Supprimer `PAYPERQ_API_KEY`, `CHAT_DATABASE_URL`, `CHAT_MODEL` de l app `vps-health-api` (les 2 rows de chacune) - [ ] Passer la row preview de `HEALTH_TOKEN` en `is_buildtime=false` (verifier par `(key, is_preview)`, pas par `key`) - [ ] **Tourner** la cle PayPerQ et le mot de passe contenu dans `CHAT_DATABASE_URL` : elles ont fuite dans les logs, les retirer de l app ne suffit pas. Suivre `docs/secret-rotation-ops.md` et mettre a jour l app proprietaire - [ ] Purger les logs de deploiement concernes dans `application_deployment_queues` (ou documenter pourquoi on ne le fait pas) - [ ] Redeployer et verifier : `GET /envs` ne montre plus aucun secret en `buildtime=true` ; les 5 routes de lecture repondent 200 - [ ] Balayer les autres apps Coolify pour le meme defaut (un secret en `buildtime=true`, rows preview comprises) et ouvrir une issue par app touchee ## Notes - Operation manuelle (API Coolify + rotation cote fournisseur) : hors autopilot. - Le `HEALTH_TOKEN` preview n est utilise que si les preview deploys sont actives ; s il porte la meme valeur que la row production, la fuite concerne le token de production. A verifier, et tourner si c est le cas (rotation conjointe avec `HOSTS_INGEST_TOKEN`, cf. #16). </details>
maximus changed title from Retirer les secrets exposes en buildtime dans l app Coolify (PAYPERQ, CHAT_DATABASE_URL, HEALTH_TOKEN preview) to Retirer les secrets buildtime de l app Coolify et revoquer la cle PayPerQ sans consommateur 2026-09-27 13:52:04 +00:00
maximus commented 2026-09-27 13:54:46 +00:00
Author
Owner
Copy link

Avancement 2026-09-27 (/fix-issue).

Fait

  • Etape 2 : rows PAYPERQ_API_KEY, CHAT_DATABASE_URL, CHAT_MODEL supprimees de l'app (production + preview, 6 DELETE en 200).
  • Etape 3 : la row preview de HEALTH_TOKEN est supprimee plutot que patchee. Les valeurs Coolify sont write-only (GET /envs ne les renvoie pas) : un PATCH du drapeau aurait exige de renvoyer la valeur du token de production. La row etait inerte (aucun preview deploy). Seule la row production reste, en runtime=true, buildtime=false.
  • GET /envs apres coup : plus aucun secret en buildtime=true (restent PORT et REPORTS_DIR, non secrets).

Pas encore redeploye, volontairement : le conteneur garde son ancien environnement, necessaire a la verif de l'etape 1 (contenu de CHAT_DATABASE_URL). Le redeploy vient apres.

Reste, manuel

  • Etape 1 (verifs VPS en lecture, metadonnees seulement)
  • Etapes 4-5 : revocations PPQ (vps-health + booking, credit-id), token Forgejo id 12 (UI), Geoapify (dashboard), vercel env rm PAYPERQ_KEY_BOOKING production, puis shred du .env preserve
  • Etape 6 : purge des logs de deploiement, apres les revocations
  • Etapes 7-8 : redeploy + verif, docs
Avancement 2026-09-27 (/fix-issue). **Fait** - Etape 2 : rows `PAYPERQ_API_KEY`, `CHAT_DATABASE_URL`, `CHAT_MODEL` supprimees de l'app (production + preview, 6 DELETE en 200). - Etape 3 : la row preview de `HEALTH_TOKEN` est **supprimee** plutot que patchee. Les valeurs Coolify sont write-only (`GET /envs` ne les renvoie pas) : un PATCH du drapeau aurait exige de renvoyer la valeur du token de production. La row etait inerte (aucun preview deploy). Seule la row production reste, en `runtime=true, buildtime=false`. - `GET /envs` apres coup : plus aucun secret en `buildtime=true` (restent `PORT` et `REPORTS_DIR`, non secrets). **Pas encore redeploye, volontairement** : le conteneur garde son ancien environnement, necessaire a la verif de l'etape 1 (contenu de `CHAT_DATABASE_URL`). Le redeploy vient apres. **Reste, manuel** - Etape 1 (verifs VPS en lecture, metadonnees seulement) - Etapes 4-5 : revocations PPQ (vps-health + booking, credit-id), token Forgejo id 12 (UI), Geoapify (dashboard), `vercel env rm PAYPERQ_KEY_BOOKING production`, puis `shred` du `.env` preserve - Etape 6 : purge des logs de deploiement, apres les revocations - Etapes 7-8 : redeploy + verif, docs
maximus added
status:in-progress
 and removed
status:ready
 labels 2026-09-27 13:54:46 +00:00
maximus commented 2026-09-27 14:01:26 +00:00
Author
Owner
Copy link

Etape 1 (verifs VPS, 2026-09-27, metadonnees seulement) :

  • Conteneur u8000gsg044wsk0oo0w884ok-000827029031 : PAYPERQ_API_KEY renseignee (25 caracteres) ; CHAT_DATABASE_URL -> user=chat_reader host=10.0.1.8:5432 db=/booking.
  • PostgreSQL partage zgkgc8soo8k4k44woo00ckg8, roles de login : logto, logto_tenant_logto_admin, logto_tenant_logto_default, maximus_api, postgres, roadtrip, simpl_sante, simpl_sante_ro, simpliste. chat_reader absent (DROP du 2026-08-12 confirme) ; la base booking n'existe plus non plus. CHAT_DATABASE_URL est donc un identifiant mort : pas de rotation.
  • application_deployment_queues de cette app : 2 lignes, toutes deux contiennent PAYPERQ_API_KEY et CHAT_DATABASE_URL :
    • d84okkgc80wkkcskskgsgogo (2026-09-25 01:41:58)
    • co4k0k8888gow4o84gk8kgkc (2026-09-27 00:08:27)

Consequence : seule la cle PPQ vps-health-20260419 est un secret vivant expose. La purge des 2 lignes suit sa revocation.

Etape 1 (verifs VPS, 2026-09-27, metadonnees seulement) : - Conteneur `u8000gsg044wsk0oo0w884ok-000827029031` : `PAYPERQ_API_KEY` renseignee (25 caracteres) ; `CHAT_DATABASE_URL` -> `user=chat_reader host=10.0.1.8:5432 db=/booking`. - PostgreSQL partage `zgkgc8soo8k4k44woo00ckg8`, roles de login : `logto`, `logto_tenant_logto_admin`, `logto_tenant_logto_default`, `maximus_api`, `postgres`, `roadtrip`, `simpl_sante`, `simpl_sante_ro`, `simpliste`. **`chat_reader` absent** (DROP du 2026-08-12 confirme) ; la base `booking` n'existe plus non plus. `CHAT_DATABASE_URL` est donc un identifiant mort : pas de rotation. - `application_deployment_queues` de cette app : 2 lignes, toutes deux contiennent `PAYPERQ_API_KEY` et `CHAT_DATABASE_URL` : - `d84okkgc80wkkcskskgsgogo` (2026-09-25 01:41:58) - `co4k0k8888gow4o84gk8kgkc` (2026-09-27 00:08:27) Consequence : seule la cle PPQ `vps-health-20260419` est un secret vivant expose. La purge des 2 lignes suit sa revocation.
maximus commented 2026-09-27 14:02:33 +00:00
Author
Owner
Copy link

Etape 7 : redeploy u8wswsgwckw4g804400kos0o (2026-09-27) finished. Les variables PAYPERQ_API_KEY / CHAT_* ne sont plus injectees dans le conteneur, et ce deploiement n'a plus aucune valeur secrete a ecrire dans les logs.

Routes de lecture, avec token : /health 200, /defenseurs 200, /defenseurs/state 200, /reports/scans?date=2026-09-27 200, /hosts 200, /defenseurs/findings?project=roadtrip 200 (project=vps-health-api -> 404 attendu, projet absent de agents-map.json).

Reste : revocations (etapes 4-5), puis purge des 2 lignes d84okkgc80wkkcskskgsgogo et co4k0k8888gow4o84gk8kgkc (etape 6) et docs (etape 8).

Etape 7 : redeploy `u8wswsgwckw4g804400kos0o` (2026-09-27) `finished`. Les variables `PAYPERQ_API_KEY` / `CHAT_*` ne sont plus injectees dans le conteneur, et ce deploiement n'a plus aucune valeur secrete a ecrire dans les logs. Routes de lecture, avec token : `/health` 200, `/defenseurs` 200, `/defenseurs/state` 200, `/reports/scans?date=2026-09-27` 200, `/hosts` 200, `/defenseurs/findings?project=roadtrip` 200 (`project=vps-health-api` -> 404 attendu, projet absent de `agents-map.json`). Reste : revocations (etapes 4-5), puis purge des 2 lignes `d84okkgc80wkkcskskgsgogo` et `co4k0k8888gow4o84gk8kgkc` (etape 6) et docs (etape 8).
maximus commented 2026-09-27 19:08:50 +00:00
Author
Owner
Copy link

Etape 5, 2026-09-27 :

  • PAYPERQ_KEY_BOOKING retiree de Vercel production (vercel env rm, aucun consommateur dans src/). Restent PAYPERQ_API_KEY + 3 PAYPERQ_KEY_* d'agents, inchangees.
  • Revocations PayPerQ bloquees : le PAYPERQ_CREDIT_ID de la-compagnie-maximus/.env.local est refuse par GET https://api.ppq.ai/keys (Invalid credit ID). La copie locale est perimee ; la valeur valide vit dans le gestionnaire de mots de passe. A faire avec elle, ou via le dashboard ppq.ai.
  • Token Forgejo id 12 bloque : GET /users/maximus/tokens repond auth required a une auth par token (comportement deja documente le 2026-08-12). A revoquer dans l'UI Forgejo : Parametres -> Applications -> Jetons d'acces.
Etape 5, 2026-09-27 : - `PAYPERQ_KEY_BOOKING` **retiree** de Vercel production (`vercel env rm`, aucun consommateur dans `src/`). Restent `PAYPERQ_API_KEY` + 3 `PAYPERQ_KEY_*` d'agents, inchangees. - Revocations PayPerQ **bloquees** : le `PAYPERQ_CREDIT_ID` de `la-compagnie-maximus/.env.local` est refuse par `GET https://api.ppq.ai/keys` (`Invalid credit ID`). La copie locale est perimee ; la valeur valide vit dans le gestionnaire de mots de passe. A faire avec elle, ou via le dashboard ppq.ai. - Token Forgejo id 12 **bloque** : `GET /users/maximus/tokens` repond `auth required` a une auth par token (comportement deja documente le 2026-08-12). A revoquer dans l'UI Forgejo : Parametres -> Applications -> Jetons d'acces.
maximus commented 2026-09-27 19:35:55 +00:00
Author
Owner
Copy link

Cloture 2026-09-27. Tous les criteres sont remplis.

  • Revocations : cle PPQ vps-health-20260419 et cle PPQ booking (faites par Max), token Forgejo id 12 (UI, Max), cle Geoapify ...c94281 (dashboard, Max ; l'ancienne cle repond 401, verifie). PAYPERQ_KEY_BOOKING retiree de Vercel.
  • /root/booking-env-preserved-20260812 detruit (shred -u, absent ensuite).
  • Purge : DELETE 2 sur application_deployment_queues (d84okkgc..., co4k0k88...). Reste le seul deploiement u8wswsgwckw4g804400kos0o, sans aucune des deux cles.
  • Etat des logs avant purge : PAYPERQ_API_KEY etait masquee par Coolify (<REDACTED>) dans les deux lignes, donc jamais en clair ; CHAT_DATABASE_URL etait en clair mais pointait vers chat_reader, role deja droppe. Aucun secret vivant n'a donc fuite en clair ; la revocation de la cle PPQ reste justifiee (cle facturable sans consommateur).
  • Docs : la-compagnie-maximus@7d9a1f2 (payperq-ops, geoapify-ops, secret-rotation-ops avec rectification datee du 2026-04-19, coolify-ops).
  • Hors scope, suivi : balayage des autres apps dans la-compagnie-maximus#170.
Cloture 2026-09-27. Tous les criteres sont remplis. - Revocations : cle PPQ `vps-health-20260419` et cle PPQ booking (faites par Max), token Forgejo id 12 (UI, Max), cle Geoapify `...c94281` (dashboard, Max ; l'ancienne cle repond `401`, verifie). `PAYPERQ_KEY_BOOKING` retiree de Vercel. - `/root/booking-env-preserved-20260812` detruit (`shred -u`, absent ensuite). - Purge : `DELETE 2` sur `application_deployment_queues` (`d84okkgc...`, `co4k0k88...`). Reste le seul deploiement `u8wswsgwckw4g804400kos0o`, sans aucune des deux cles. - Etat des logs avant purge : `PAYPERQ_API_KEY` etait **masquee** par Coolify (`<REDACTED>`) dans les deux lignes, donc jamais en clair ; `CHAT_DATABASE_URL` etait en clair mais pointait vers `chat_reader`, role deja droppe. Aucun secret vivant n'a donc fuite en clair ; la revocation de la cle PPQ reste justifiee (cle facturable sans consommateur). - Docs : `la-compagnie-maximus@7d9a1f2` (payperq-ops, geoapify-ops, secret-rotation-ops avec rectification datee du 2026-04-19, coolify-ops). - Hors scope, suivi : balayage des autres apps dans `la-compagnie-maximus#170`.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
issue-4-runtime-only-coolify-secrets
No results found.
Labels
Clear labels   
autopilot:pending-human

PR produite par /autopilot, attend review humaine (jamais mergee par le run)

  
source:analyste

Créée par le Super-Analyste

  
source:defenseur

Créée par l Escouade Défenseur

  
source:human

Créée par un humain

  
source:medic

Créée par le Medic (auto-détection)

  
status:approved

PR approuvée, prête à merger

  
status:blocked

Bloquée (question, dépendance, clarification)

  
status:in-progress

Un agent (Medic/Dev) travaille dessus

  
status:needs-clarification

Issue bloquee par une ambiguite LOW pendant un run autonome, Max doit trancher

  
status:needs-fix

Reviewer demande des corrections

  
status:ready

Analysée et documentée, prête à prendre

  
status:review

PR créée, en attente du Reviewer

  
status:triage

Nouvelle issue, pas encore analysée

  
type:bug

Correction de bug → Medic

  
type:feature

Nouvelle fonctionnalité → Dev

  
type:infra

Config, CI/CD, déploiement → Dev

  
type:refactor

Refactoring / amélioration technique → Dev

  
type:schema

Modèle de données / migrations → Dev

  
type:security

Issue de sécurité → Medic ou Dev

No labels
autopilot:pending-human
source:analyste
source:defenseur
source:human
source:medic
status:approved
status:blocked
status:in-progress
status:needs-clarification
status:needs-fix
status:ready
status:review
status:triage
type:bug
type:feature
type:infra
type:refactor
type:schema
type:security
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: maximus/vps-health-api#29
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?