2026 OpenClaw : gestion des secrets, clés API par nœud, droits minimaux et rotation sur MeshMac

Trois frictions typiques des équipes multi-nœuds :

1. Clé unique : un nœud compromis expose tout le périmètre OpenClaw.
2. Montages larges : l'agent lit ~/.secrets entier au lieu d'un fichier — risque copy-paste.
3. Rotation brouillon : révocation sans chevauchement, reload désordonné, 401 sans lien nœud–tâche.

Repères : 3–5 rôles de secrets par produit ; <15 min de double validité en rotation ; runbook de révocation testé au trimestre.

Menaces de base : journaux lisibles, clé collée dans un ticket, nœud accessible en SSH/VNC, ou snapshot de sauvegarde exposé. La gestion des secrets impose droits minimaux sur fichiers, variables visibles par le processus et politiques côté fournisseur d'API, afin qu'une erreur d'exploitation ne dépasse jamais le rôle du nœud.

Principes : refus par défaut sur les montages ; blast radius séparé entre entrée webhook, workers de file et tâches de signature ; règle d’or « un rôle, un jeu de jetons » ; ID nœud dans chaque tâche ; rotation calendrier plutôt que réaction seule. Voir permissions / bascule et répartition de charge.

Chemin stable par machine (/var/lib/openclaw/secrets ou équivalent), chmod 600, propriétaire = compte du service. Config non sensible hors dépôt ou en IaC séparée.

Cinq étapes :

1. secrets.d/*.env par intégration, pas un mega-fichier.
2. Chargement via launchd, pas exports shell interactifs.
3. Hooks / revue anti API_KEY= dans Git.
4. .env.example sans secrets réels.
5. Test à froid : sans fichier → échec explicite, jamais fallback dev silencieux.

Erreurs : 644 « pour débloquer » ; rsync de secrets vers tous les nœuds ; dossier unique Apple + SaaS lisible par tous les comptes.

Un nœud = un rôle = un sous-ensemble de jetons : cœur de la séparation des clés API. Le frontal webhook n'embarque pas les identifiants de notarisation ; le worker qui consomme la file n'hérite pas des privilèges d'administration cloud. Cette discipline réduit aussi le bruit lors des revues d'accès trimestrielles.

Mac loués : comptes ou volumes séparés par équipe ; offres multi-nœuds évitent la machine « passe-partout » surchargée en secrets.

Rotation : nouvelle clé à périmètre équivalent → déploiement sur tous les nœuds concernés avec chevauchement contrôlé → reload ingest → workers → sorties → révoquer l'ancienne quand les taux d'erreur et les métriques métier sont revenus au plancher habituel. Prévenez les équipes produit si la fenêtre touche des intégrations externes sensibles au timing.

Urgence : révoquer tout de suite, activer clé de secours si existante, redéployer fichier par fichier, valider par tâche « sonde » OpenClaw en lecture seule. Wiki : version logique du secret pour l'astreinte ; évitez les captures d'écran contenant des jetons.

Piège : cron ou runner GitHub oublié sur l'ancienne variable — inventoriez les consommateurs par nom logique.

Logs : nom logique du secret (billing_api_v3), suffixe ou empreinte courte, ID nœud — jamais la valeur ni Authorization complet dans les tickets publics. Sur 401/403, croiser maintenance, déploiements et fenêtres de rotation avant de réémettre une clé.

Permission denied malgré root ?

ACL, SIP, sandbox ou chroot : le chemin effectif compte.

Un nœud OK, les autres non ?

Checksum des .env, version OpenClaw, fuseau du scheduler (JWT).

Chiffrement at rest ?

FileVault + backups chiffrés ; ils ne remplacent pas les ACL si la session est ouverte.