# Rotation des secrets — inventaire et plan (établi 18/07/2026, à exécuter au retour) ## FENÊTRE D'EXÉCUTION NAS en arrêt programmé **16:30 → 01:30** (coupures Sfax). Toute session du soir est impossible. **Créneau utile : 01:30–16:30**, matinée de préférence. Prévoir 45–60 min. --- ## A. ROTATIONS OBLIGATOIRES (secrets exposés en clair le 18/07/2026) ### A1. Clé provider OpenCode — PRIORITÉ 1 Exposée dans un traceback de session. **C'est la clé qui porte le budget 10 $/mois.** Portée réelle (vérifiée par empreinte SHA-256, valeurs jamais affichées) — la MÊME valeur sert à : | Emplacement | Variable / champ | |---|---| | Bifrost config.db | provider `opencode`, clé `opencode-1` | | `/volume1/docker/hermes-platform/.env` | `BIFROST_OPENCODE_KEY` | | container `family-help` | `OPENCODE_API_KEY` (appel direct, hors Bifrost) | Procédure : générer la nouvelle clé sur OpenCode → mettre à jour `.env` → mettre à jour la clé provider dans Bifrost (UI ou config.json au boot, cf. piège de persistance) → recréer family-help → **révoquer l'ancienne** → tester un appel par Bifrost et un appel family-help. ### A2. Token Cloudflare Workers AI — PRIORITÉ 1 Dans `/volume1/docker/redaction-pro/nginx.conf`, bloc `location /api/cf/` (en-tête Authorization). Backup existant : `nginx.conf.bak_vk_20260718` — **contient l'ancien token, à supprimer après rotation.** Procédure : nouveau token côté Cloudflare → éditer nginx.conf (via container alpine, cf. piège permissions) → `docker restart redaction-pro` → tester → révoquer l'ancien → purger le .bak. --- ## B. ANOMALIES DÉCOUVERTES — à corriger pendant la même fenêtre ### B1. Secrets partagés entre sphères (violation de la règle d'étanchéité) | Container | Variable | Porte en réalité la valeur de | |---|---|---| | hermes-agent-perso | `TRILIUM_TOKEN_PERSO` | `TRILIUM_TOKEN_TT` (sphère TT !) | | hermes-agent-perso | `PAPERLESS_TOKEN_PERSO` | `PAPERLESS_TOKEN_NYORA` | | gsparc-mezzouna-api | `BASEROW_TOKEN` | `BASEROW_TOKEN_NYORA` | | gsparc-mezzouna-api | `VISION_API_KEY` | `HERMES_TT_OPENCODE_KEY` | | family-help | `TELEGRAM_BOT_TOKEN` | `HERMES_PERSO_TELEGRAM_TOKEN` | Conséquence : la sphère perso détient un accès TT. Générer des tokens distincts par sphère. ### B2. Redondance interne (non bloquant, à assainir) Dans les 3 Hermes, `OPENAI_API_KEY`, `NVIDIA_API_KEY` et `CUSTOM_API_KEY` pointent tous sur la même valeur `HERMES__NVIDIA_KEY`. Trois noms, un secret : une rotation manquée en laisse deux vivants. ### B3. Permissions `/volume1/docker/hermes-platform/.env` est en **777**. Cible 640 root:users — vérifier d'abord quels containers le lisent et sous quel uid (1026/100) avant de restreindre. ### B4. Token Gitea en clair dans un remote git Dépôt `nabil-brain` : URL remote de la forme `https://bolbol:@gitea.bolbol.tn`. Roter le token et réécrire le remote (credential helper ou SSH). ### B5. Mot de passe legacy bolbol (famille `2L2u519w*`) largement embarqué en clair — git remotes, .env, docs (ajout 08/08/2026) Instance **non répertoriée** de la **famille `2L2u519w*`** (rotation en attente, cf. incident sudo Best0f 07/2026). Mot de passe legacy `bolbol`, suffixe service `gitea` (empreinte sha256 : `bbd43b3e`, valeur non affichée conformément à A1). **Liveness NON re-vérifiée le 08/08/2026** (adresse interne `172.17.0.1` injoignable hors NAS ; test via Tailscale non concluant) → traiter comme **potentiellement vivant** tant que non confirmé mort, d'autant qu'il est embarqué dans de nombreux remotes actifs. **Portée réelle** — sweep unique `grep -rlI` sur `/volume1/docker` (08/08/2026, ~30 fichiers) : - **~10 remotes git** (mot de passe dans l'URL de `.git/config`) : `nyora-notes` (workspace hermes-nyora), `hermes-perso`, `hermes-platform/.git.bak`, `family-help`, `bifrost-proxy`, `panda-dashboard`, `nyora-doc-api`, `context-hub`, `_archive/rayhan-erp`, `nas-runbooks.STALE-*`. - **7 fichiers `.env`** (désactivés / backups) : `hermes-tt/.env.disabled`, `hermes-nyora/.env.disabled`, `hermes-perso/.env.disabled`, 2× `hermes-nyora/.env.bak-*`, 2× `_rotation-backup-20260709/*/.env`. - **En clair DANS le repo `nas-runbooks` lui-même (déjà commité)** : `common/HEBERGEMENT-SITES-STATIQUES.md`, `common/n8n-skills-officiels.md`, `common/tap-gitea-hermes-skills.md`, `common/telegram-flood-control-overflow-split-et-gitea-deploy-token.md`. Aussi : context-hub (`CLAUDE.md`, `AGENTS.md`, walkthroughs), `hermes-nyora/.../MEMORY.md`, un `tirith/log.jsonl`. - Hors `/volume1/docker` (non couvert par le sweep) : `/tmp/nas-runbooks-work/.git/config` sur l'hôte NAS. Le push nas-runbooks du 08/08 a été fait via le token `GITEA_TOKEN_TT` (bolbol) de `/volume1/docker/hermes-platform/.env`, sans jamais ré-embarquer ce mot de passe. **Action (session de rotation dédiée requise — hors périmètre du chantier message_id 08/08)** : roter le mot de passe famille `2L2u519w*` ; réécrire tous les remotes sans credential embarqué (token via helper) ; purger les `.env.bak`/`.env.disabled` et le clone STALE ; **scrubber l'historique** des runbooks/docs contenant la valeur en clair (git-filter-repo / BFG). --- ## C. À NE PAS TOUCHER Les 13 clés virtuelles Bifrost `vk-*` créées le 18/07 ne sont pas compromises (jamais affichées, vérification par empreinte uniquement). Aucune rotation nécessaire. --- ## D. ORDRE D'EXÉCUTION RECOMMANDÉ 1. A1 OpenCode (budget en jeu) — 2. A2 Cloudflare — 3. Vérifier logs Bifrost : plus aucun 401 nouveau lié à la rotation — 4. B1 séparation des sphères — 5. B3 permissions — 6. B4 remote git. Après chaque rotation : tester AVANT de révoquer l'ancienne clé, et ne jamais afficher une valeur (vérification par longueur ou empreinte).