2026 OpenClaw MeshMac en pratique : modèles d’environnement et injection de secrets reproductibles (dev / staging / prod)

Pourquoi formaliser tout de suite

Sans convention, un nœud « de test » réutilise la clé production, ou deux workers pointent vers des files différentes sans que l’équipe s’en aperçoive. La combinaison template Git + coffre par environnement + overrides limités réduit la surface d’erreur et rend les incidents traçables.

Fixez pour chaque environnement : identifiant stable (dev, staging, prod), magasin de secrets (Vault, 1Password Connect, Secrets Manager, ou répertoire chiffré par équipe), et politique réseau (staging peut-il joindre les mêmes SaaS que prod ?).

Arborescence suggérée sur le coffre (exemple)

openclaw/
  dev/worker/*.env
  staging/worker/*.env
  prod/worker/*.env
  prod/gateway/*.env

Commandes (administrateur coffre / bastion)

# Exemple : lister les chemins disponibles pour un rôle donné (adapter au CLI du coffre)
vault kv list secret/openclaw/prod/worker/

# Vérifier qu'aucun chemin prod n'est monté sur un hôte tagué dev
grep -R "secret/openclaw/prod" /etc/openclaw/bootstrap.d/ || echo "OK: pas de chemin prod dans bootstrap dev"

Vérification

• Tableau signé : chaque combinaison ENV × rôle a un propriétaire et un chemin de secret unique.
• Contrôle automatisé : échec CI si un fichier de bootstrap dev référence un préfixe prod.

Lien : secrets et droits minimaux sur les nœuds MeshMac.

Un seul openclaw.env.tpl dans Git décrit toutes les clés attendues ; les valeurs sensibles restent des placeholders. Le pipeline de déploiement injecte les secrets et écrit openclaw.env sur le nœud, avec TEMPLATE_REVISION (hash Git ou semver du pack de config).

Fragment de template

# openclaw.env.tpl (extrait)
ENV={{ENV}}
MESH_NODE_ID={{MESH_NODE_ID}}
NODE_ROLE={{NODE_ROLE}}
OPENCLAW_QUEUE_URL={{OPENCLAW_QUEUE_URL}}
OPENCLAW_REGISTRY_URL={{OPENCLAW_REGISTRY_URL}}
TEMPLATE_REVISION={{TEMPLATE_REVISION}}
# Secret injecté hors Git :
OPENCLAW_API_TOKEN={{SECRET_OPENCLAW_API_TOKEN}}

Rendu local (exemple avec envsubst)

export ENV=staging NODE_ROLE=worker MESH_NODE_ID=mac-stg-03
export TEMPLATE_REVISION="$(git rev-parse --short HEAD)"
export OPENCLAW_QUEUE_URL="https://queue.staging.internal"
export SECRET_OPENCLAW_API_TOKEN="$(op read op://vault/staging/token)"
envsubst < openclaw.env.tpl > /tmp/openclaw.env.rendered
shasum -a 256 /tmp/openclaw.env.rendered

Vérification

• diff entre le rendu canari et le dernier rendu approuvé : seules les valeurs non secrètes attendues changent.
• Au démarrage du service, le journal affiche TEMPLATE_REVISION identique sur tous les workers d’un même déploiement.

Complément : verrouillage des skills et template d’environnement, et déploiement unifié et file de tâches.

Le compte qui exécute OpenClaw doit être le seul à lire /etc/openclaw/secrets.d ; interdire la lecture groupe/autres. Préférer un mount en lecture seule depuis le coffre plutôt qu’une copie longue durée sur disque lorsque la plateforme le permet.

Permissions (sur chaque nœud)

sudo install -d -m 0700 -o openclaw -g staff /etc/openclaw/secrets.d
sudo install -m 0600 -o openclaw -g staff /path/from/vault/openclaw_api_token /etc/openclaw/secrets.d/openclaw_api_token
sudo chown -R openclaw:staff /etc/openclaw
# Vérifier : aucun 'other' en lecture
find /etc/openclaw -type f ! -perm 600 -print

Fragment launchd (extrait) — chargement explicite

<key>EnvironmentVariables</key>
<dict>
  <key>OPENCLAW_ENV_FILE</key>
  <string>/etc/openclaw/openclaw.env</string>
</dict>

Vérification

• En tant qu’utilisateur non privilégié : test -r /etc/openclaw/secrets.d/openclaw_api_token doit échouer.
• Les logs ne contiennent pas la valeur des jetons (grep Bearer / sk- sur une capture d’échantillon).

Les GPU, chemins de cache ou labels de file peuvent varier. Après le rendu principal, appliquez un petit fichier openclaw.local.env (non versionné) ou des fragments YAML fusionnés — avec une liste blanche de clés autorisées pour éviter le contournement des politiques prod.

Exemple de surcharge

# /etc/openclaw/openclaw.local.env — uniquement clés approuvées par l'équipe plateforme
OPENCLAW_WORKER_CONCURRENCY=2
OPENCLAW_TMPDIR=/Volumes/FastCache/openclaw

Contrôle côté dépôt (schéma ou test)

# Rejeter toute clé hors liste blanche dans les fichiers d'override commités (exemple)
allowed='OPENCLAW_WORKER_CONCURRENCY|OPENCLAW_TMPDIR'
grep -E '^[A-Z0-9_]+=' openclaw.local.env.example | cut -d= -f1 | grep -Ev "^($allowed)$" && exit 1 || true

Vérification

• Deux nœuds du même rôle et ENV ont le même noyau de variables ; seules les clés whitelistées diffèrent.
• Documenter dans le runbook pourquoi le nœud « build-07 » a une surcharge (lien ticket).

Canari, puis 25 % / 50 % / 100 % des nœuds du rôle. Entre chaque vague : santé de la file, latence des tâches, absence de 401 massifs. Référence charge et bascule : répartition de charge et failover.

Séquence type

# 1) Publier le template (Git tag)
git tag -a config-2026.03.28 -m "openclaw env template"
git push origin config-2026.03.28

# 2) Déployer sur un canari puis recharger le service
sudo install -m 0600 /tmp/openclaw.env.rendered /etc/openclaw/openclaw.env
sudo launchctl kickstart -k system/com.openclaw.worker

# 3) Santé — adapter à votre CLI
openclaw doctor --strict
openclaw tasks smoke --trace-id "deploy-$(date +%s)"

Vérification

• Même TEMPLATE_REVISION et même URL de file sur tous les nœuds du lot.
• La tâche fumée se termine avec le même trace_id visible côté agrégateur de logs.

Conservez la paire tag Git du template + empreinte du bundle de secrets pour chaque promotion. Le rollback remet le fichier rendu précédent et recharge les services ; la rotation des secrets suit une fenêtre à double validité déjà décrite dans les guides jetons.

Rollback express

sudo cp /etc/openclaw/backup/openclaw.env.prev /etc/openclaw/openclaw.env
sudo launchctl kickstart -k system/com.openclaw.worker
openclaw doctor --strict

Points d’audit (à journaliser)

• ·actor (humain ou pipeline), env, node_id, template_revision, secret_id (pas la valeur).
• ·Horodatage de montage ou d’injection ; résultat de doctor / smoke.
• ·Rétention alignée RGPD / SOC2 : durée minimale pour enquête, purge documentée.

• ☐Un template unique couvre dev, staging et prod ; aucune clé secrète dans Git.
• ☐Coffres ou chemins strictement séparés par ENV ; contrôle automatisé anti-mélange.
• ☐Répertoires secrets en 0700, fichiers en 0600, propriétaire = compte de service.
• ☐Overrides : liste blanche + revue + lien ticket pour chaque exception durable.
• ☐Déploiement par vagues ; smoke et doctor verts sur chaque lot.
• ☐Rollback testé au moins une fois par trimestre ; journaux d’audit avec identifiants de secret sans valeurs.

Navigation : liste du blog, articles OpenClaw, centre d’aide Meshmac (SSH, VNC, mise en route).