OpenClaw sécurité : le guide pour la production

Introduction

Une démarche OpenClaw sécurité ne se résume pas à placer Nginx devant une interface web. Le Gateway possède les canaux, les sessions, les credentials et le pouvoir d’exécuter des outils ; sa compromission peut donc atteindre bien plus qu’un tableau de bord. Ce guide est utile avant toute connexion à un canal ou exposition distante. Il vaut mieux éviter une instance partagée si des utilisateurs mutuellement hostiles doivent y accéder : séparez alors les Gateways et les comptes OS. Vous allez durcir le bind, l’authentification, le pairing, les politiques de messages, les outils, les secrets, Docker et l’audit avec les mécanismes actuels.

Résumé rapide

• Garder gateway.bind sur loopback et préférer SSH ou Tailscale Serve.
• Activer une auth Gateway pour toute écoute non-loopback.
• Restreindre DM, groupes et commandes avec pairing et allowlists.
• Sandboxer les outils et séparer les frontières de confiance.
• Exécuter openclaw security audit --deep après chaque changement sensible.

Le modèle de menace réel d’OpenClaw

OpenClaw est un Gateway Node/TypeScript de longue durée. Il maintient les connexions aux canaux, route les messages, exécute les agents et expose un plan de contrôle WebSocket au Control UI, à la CLI et aux nodes. Sa configuration canonique est ~/.openclaw/openclaw.json; son état inclut des bases SQLite, les approbations, les sessions et les profils d’authentification.

La frontière supportée est celle d’un opérateur seul ou d’un groupe de personnes qui se font confiance. Plusieurs agents peuvent avoir des workspaces et historiques distincts, mais cette isolation fonctionnelle n’est pas conçue pour résister à un opérateur hostile du même Gateway. Un workspace n’est pas non plus un sandbox : sans isolation, un outil shell peut utiliser des chemins absolus avec les droits du compte OS.

Il faut distinguer quatre contrôles. L’auth Gateway protège les connexions au plan de contrôle. Le pairing des DM décide qui peut envoyer un message au bot. Le pairing des appareils décide quels nodes et clients rejoignent le réseau du Gateway. Enfin, les politiques d’outils et le sandbox déterminent ce qu’un agent peut faire après réception d’un contenu. Aucun de ces contrôles ne remplace les autres.

Les valeurs par défaut sont prudentes : bind loopback, pairing fréquent pour les expéditeurs inconnus et allowlists de groupes. Le risque apparaît lorsque l’on passe en lan, ouvre les DM, partage un token ou donne exec à un agent qui traite des instructions externes. La configuration OpenClaw doit donc être revue comme une politique de sécurité, pas comme un simple fichier de préférences.

Sécuriser OpenClaw couche par couche

1. Conserver le Gateway sur loopback

Par défaut, le Gateway écoute sur 127.0.0.1:18789. C’est la meilleure base :

openclaw config set gateway.bind loopback
openclaw gateway restart --safe
openclaw gateway status --deep

Pour un serveur distant, ouvrez un tunnel :

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Le navigateur et la CLI utilisent alors une adresse locale, sans port Gateway public. Tailscale Serve offre une autre voie privée. N’utilisez un bind lan, tailnet ou custom que si la topologie l’exige. Le Gateway bloque une écoute non-loopback dépourvue d’auth, mais un token faible ou exposé reste une mauvaise défense.

2. Configurer l’auth Gateway

Les modes actuels sont token, password, trusted-proxy et, pour un ingress privé maîtrisé, none. Le mode none ne doit pas être placé derrière une entrée publique ou non fiable. Pour générer un token persistant :

openclaw doctor --generate-gateway-token
openclaw gateway restart --safe

Pour afficher le token sur l’hôte dans un terminal interactif :

openclaw gateway auth-token --show

La commande refuse la redirection afin de limiter les fuites silencieuses. Préférez un SecretRef ou OPENCLAW_GATEWAY_TOKEN à un secret écrit dans une commande. Si token et mot de passe sont tous deux configurés, définissez explicitement gateway.auth.mode, sinon l’installation du service peut être bloquée.

Le mode trusted-proxy suppose un proxy d’identité réellement maîtrisé. Un proxy loopback sur le même hôte demande une autorisation explicite. N’accordez jamais votre confiance à des en-têtes envoyés directement par Internet.

3. Contrôler DM et groupes

Les politiques DM sont pairing, allowlist, open et disabled. En mode pairing, un inconnu reçoit un code, mais son message n’est pas traité. Listez et approuvez :

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Un code expire et une demande doit être examinée avec l’identité du canal. Le mode open exige une allowlist contenant explicitement "*" ; cette friction évite une ouverture accidentelle. Pour les groupes, conservez une allowlist et un déclenchement par mention lorsque c’est possible.

Si plusieurs personnes peuvent envoyer des DM, isolez le contexte :

{
  session: { dmScope: "per-channel-peer" }
}

Sans cela, le défaut main regroupe les DM dans la session principale afin de conserver la continuité multi-appareils. Cette continuité personnelle devient une fuite de contexte dans un bot partagé.

4. Distinguer pairing d’appareil et autorisation

Un node iOS, Android, macOS, Windows ou headless se connecte avec role: node et annonce ses capacités. Approuvez une demande après examen :

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Les commandes sensibles de caméra, d’écran et d’exécution nécessitent toujours une politique adaptée. Un setup code est un secret temporaire : transmettez-le sur un canal sûr et invalidez les codes inutilisés. Révoquez un appareil perdu au lieu de supposer qu’un token expirera assez vite.

5. Limiter outils et skills

Une allowlist de skills limite ce que l’agent voit dans son contexte ; elle n’est pas une frontière d’autorisation shell. Si l’agent dispose de exec, contrôlez séparément le sandbox, les binaires, le compte OS, les mounts et les credentials. Pour un agent qui traite des tickets ou pages externes, partez d’une politique minimale : lecture des ressources nécessaires, écriture dans un espace borné, pas d’accès aux secrets généraux.

Le contenu reçu d’un canal, d’un webhook ou du web est non fiable. Une injection de prompt peut tenter de pousser l’agent à lire un fichier, envoyer un secret ou modifier sa configuration. Une consigne système ne suffit pas à empêcher l’action : l’autorisation technique doit rendre l’opération impossible ou soumise à approbation.

6. Protéger les secrets et l’état

Le state dir contient des informations sensibles. Restreignez ses permissions et laissez Doctor les contrôler :

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
openclaw doctor --lint --all

Ne commitez pas les clés de fournisseur, tokens de canal ou token Gateway. Utilisez les fournisseurs de secrets et les SecretRefs lorsque l’exploitation le justifie. Pour un canal automatisé avec --use-env, la variable doit rester dans l’environnement du service ; ne la laissez pas uniquement dans votre shell d’installation.

Sauvegardez l’état complet avec une procédure cohérente pour SQLite et testez la restauration. Une copie incomplète peut perdre les approbations ou désynchroniser un canal. Un secret restauré depuis une ancienne sauvegarde peut aussi être déjà révoqué.

7. Durcir Docker et le VPS

Dans Docker, le setup lie souvent le Gateway à lan à l’intérieur du conteneur pour que la publication du port fonctionne. Limitez le port côté hôte à loopback, gardez l’auth active et inspectez les règles de la chaîne DOCKER-USER, car Docker peut contourner des hypothèses UFW naïves. Utilisez uniquement ghcr.io/openclaw/openclaw ou le miroir officiel.

Sur VPS, autorisez SSH par clé avant d’activer le pare-feu. Nginx n’est pas obligatoire si vous utilisez un tunnel. Si vous publiez une URL wss://, le proxy doit prendre en charge l’upgrade WebSocket, TLS, les origines du Control UI et la transmission d’identité prévue. Le déploiement VPS OpenClaw fournit le parcours privé recommandé.

8. Auditer et surveiller

Après chaque changement de canal, bind, auth, plugin ou tool policy :

openclaw security audit
openclaw security audit --deep
openclaw status --all
openclaw channels status --probe
openclaw doctor --lint --json

security audit --fix applique des remédiations sûres, mais lisez le rapport avant et après. Ne considérez pas un audit propre comme une preuve absolue : vérifiez aussi les ports avec les outils système, les règles cloud, la portée des credentials et les journaux d’accès.

Mini-checklist avant exposition

• Une seule frontière de confiance utilise ce Gateway.
• Le port 18789 est privé ou protégé par TLS et auth.
• Les DM et groupes ont une politique explicite.
• Les DM de plusieurs personnes utilisent un scope isolé.
• Les tools et le sandbox correspondent au risque des entrées.
• Les secrets ne sont ni dans Git ni dans les logs.
• Sauvegarde, révocation et audit ont été testés.

Exemple concret : Telegram sur un VPS privé

Une équipe de trois personnes utilise un Gateway sur Ubuntu. Elle garde gateway.bind en loopback, autorise seulement SSH dans le pare-feu et administre le Control UI par tunnel. Telegram est configuré avec dmPolicy: "allowlist"; les trois identifiants sont référencés dans un groupe d’accès réutilisable. La session utilise dmScope: "per-channel-peer" pour éviter les croisements de contexte.

L’agent reçoit des liens externes et peut créer des notes, mais il n’a pas accès à exec, aux nodes ni au cron. Son workspace est séparé et ses credentials sont limités au canal et au modèle nécessaires. L’équipe crée un second Gateway sous un autre compte OS pour un prestataire qui n’appartient pas à sa frontière de confiance.

Après configuration, l’opérateur exécute :

openclaw channels status --probe
openclaw security audit --deep
openclaw doctor --lint --all

Il teste ensuite quatre refus : un DM inconnu, un message de groupe sans mention, une connexion WebSocket sans token et une tentative d’appel d’outil interdit. Les refus doivent être observés dans les logs sans y révéler le contenu des secrets. Enfin, l’équipe restaure la sauvegarde sur un environnement isolé et confirme que le Gateway peut être diagnostiqué. Ce test négatif apporte plus de confiance qu’une simple page de dashboard verte.

Bonnes pratiques

Appliquez le moindre privilège à trois niveaux : expéditeur, agent et outil. Autoriser quelqu’un à parler au bot ne lui donne pas automatiquement le droit de lancer des commandes administratives. Autoriser un skill ne doit pas ouvrir un shell général. Autoriser un node ne doit pas activer toutes ses capacités sensibles.

Révisez les allowlists quand un membre quitte l’équipe, révoquez les appareils perdus et faites tourner les tokens après incident. Utilisez des credentials distincts par environnement et par agent lorsque l’isolation le demande. Surveillez les changements de configuration et les opérations de restart dans les journaux.

Évitez les recettes de sécurité purement réseau. HTTPS protège le transport, pas une injection de prompt exécutée par un outil trop puissant. À l’inverse, un sandbox ne protège pas un Control UI publiquement accessible avec un token partagé. La défense efficace combine topologie, identité, autorisation, isolation, journalisation et reprise.

Questions fréquentes

OpenClaw est-il sécurisé par défaut ?

Les valeurs par défaut sont conservatrices : Gateway lié à loopback, pairing fréquent pour les DM inconnus et groupes généralement allowlistés. La sécurité se dégrade dès que vous ouvrez le bind, les DM ou les outils. Exécutez l’audit après chaque changement et conservez une authentification forte sur toute surface non-loopback.

Quelle authentification utiliser pour OpenClaw ?

Un token Gateway convient à la plupart des installations personnelles et VPS privés. Un mot de passe ou un proxy de confiance peut répondre à d’autres topologies. Le mode none ne convient qu’à un ingress privé réellement maîtrisé. Ne confondez pas gateway.remote.token, credential d’un client distant, avec la configuration d’auth du serveur.

Nginx est-il obligatoire pour un reverse proxy OpenClaw ?

Non. Pour un accès d’administration, un tunnel SSH ou Tailscale Serve est souvent plus simple et réduit la surface publique. Nginx, Caddy ou un proxy d’identité deviennent pertinents pour une URL wss:// stable. Ils doivent gérer WebSocket, TLS, auth et origines, sans ouvrir directement le port interne.

Plusieurs agents OpenClaw sont-ils isolés ?

Ils possèdent des workspaces, répertoires d’état et historiques distincts, ce qui évite les collisions fonctionnelles. Cette séparation n’est toutefois pas une frontière hostile à l’intérieur d’un Gateway administré par la même personne. Pour des utilisateurs adverses, séparez Gateway, credentials et idéalement compte OS ou hôte.

Comment vérifier la sécurité OpenClaw ?

Lancez openclaw security audit --deep, openclaw doctor --lint --all, openclaw status --all et les probes de canaux. Complétez par des tests négatifs : port public fermé, DM inconnu bloqué, appareil non appairé refusé et outil interdit impossible. Vérifiez enfin que les logs ne contiennent pas de secrets.

Articles liés

Sécuriser OpenClaw exige de protéger le Gateway et de limiter ce que l’agent peut faire après réception d’un message. Gardez une topologie privée par défaut, puis n’ouvrez que les surfaces dont vous avez une raison opérationnelle précise.

• Configurer OpenClaw correctement
• Déployer OpenClaw sur un VPS privé
• Conteneuriser OpenClaw avec Docker
• Mettre OpenClaw en production
• Surveiller les logs OpenClaw
• Comprendre l’architecture OpenClaw