runbook: rotation secrets Baserow casse containers standalone (dashboard-terrain)

2026-07-25 18:18:55 +00:00
parent a1be913863
commit 8be10c9d12
1 changed files with 47 additions and 0 deletions
@@ -0,0 +1,47 @@
+# Rotation secrets Baserow casse les containers standalone non supervises (25/07/2026)
+
+## Symptome
+dashboard-terrain (container standalone : docker build + run manuel, pas de compose, pas de volume, code
+cuit dans l'image) retournait 500 sur /api/depenses. `docker logs` montrait uniquement la sequence de
+codes 500 successifs, aucun traceback applicatif exploitable directement dans les logs.
+
+## Cause racine
+Le mot de passe admin Baserow (BASEROW_ADMIN_PASS) a ete change lors d'une rotation de secrets. Ce
+changement a bien ete propage a hermes-platform/.env et gsparc-mezzouna/.env (BASEROW_PASSWORD a jour),
+mais dashboard-terrain avait l'ancien mot de passe **code en dur en fallback ENV du Dockerfile**
+(`ENV BASEROW_ADMIN_PASS=...`). Comme ce container ne fait partie d'aucun inventaire supervise (pas de
+.env central, pas de docker-compose, pas de mount de code), il n'a jamais ete touche par la rotation.
+
+## Diagnostic rapide (reproductible en ~2 min)
+1. `docker logs <container>` pour reperer le endpoint et le code d'erreur (ici 500 sur /api/depenses).
+2. `docker exec <container> python3 -c "..."` pour rejouer l'appel Baserow directement depuis le reseau
+   interne du container (Host header + Authorization) -> reponse brute Baserow, ici
+   `401 ERROR_INVALID_CREDENTIALS: No active account found with the given credentials.` Confirme la cause
+   en un seul appel, plus fiable/rapide que d'ajouter du logging applicatif.
+3. Comparer avec les identifiants a jour dans hermes-platform/.env et gsparc-mezzouna/.env pour confirmer
+   l'ecart.
+
+## Fix retenu
+Basculer le container du login JWT admin (identifiants qui tournent, session a rafraichir) vers un
+**Database API Token Baserow statique** (header `Authorization: Token <token>`, scope adapte au
+consommateur : BASEROW_TOKEN_PERSO / BASEROW_TOKEN_NYORA / BASEROW_TOKEN_TT_RLA / BASEROW_TOKEN_TT_HORS_RLA
+deja presents dans hermes-platform/.env). Ce token ne casse jamais lors d'une rotation du mot de passe
+admin Baserow — seul un audit/rotation explicite des tokens API le ferait.
+
+Simplification de code associee : suppression du thread de rafraichissement JWT (`_jwt_refresher`,
+`JWT_REFRESH_INTERVAL`), de `_refresh_jwt()` et de la logique de retry-sur-401 — plus necessaire avec un
+token statique.
+
+## Regle generale a appliquer
+- Tout **nouvel** outil en lecture seule sur Baserow : utiliser d'emblee un Database API Token par scope,
+  jamais un login admin JWT.
+- Avant toute prochaine fenetre de rotation de secrets (voir common/rotation-secrets-inventaire.md) :
+  lister les containers standalone (docker build/run manuel, sans compose, sans .env central) qui
+  referencent des identifiants Baserow, Gitea ou autres services rotationnes, et les auditer un par un —
+  ils sont invisibles depuis hermes-platform/.env et donc systematiquement oublies.
+- Container standalone identifie a ce jour : dashboard-terrain (corrige le 25/07/2026). Ajouter tout
+  nouveau container de ce type ici au fil de l'eau.
+
+## Repo source
+bolbol/dashboard-terrain (Gitea, branche master) — server.py + Dockerfile mis a jour, image rebuild
+dashboard-terrain:latest, container redeploye sur le reseau n8n, port 8085->8080.