Les équipes qui font déjà tourner OpenClaw Gateway négligent souvent moins l’installation que le fait que la surface d’écoute, les listes blanches d’identité et la posture de sortie réseau soient réellement prêtes pour la production en 2026. Cet article est une checklist prête pour ticket de changement : d’abord liaison 127.0.0.1 plus reverse proxy ou tunnel pour retirer un plan de gestion nu, puis rotation des jetons, dmPolicy, networkPolicy et validation des exécutions pour séparer le risque SSRF, les sessions non autorisées et les invites d’une ligne pouvant lancer un shell destructeur ; il précise aussi l’articulation avec nos articles systemd, Docker et observabilité. Vous repartez avec une matrice de comparaison, un ordre de déploiement en six étapes et l’usage standard de config:validate et doctor.
La valeur d’OpenClaw est de router modèles et sessions via une Gateway durable ; le risque s’y concentre car elle détient identifiants, appels d’outils et trafic sortant. Si l’onboarding s’arrête à « la console s’affiche » alors que l’écoute, les jetons et les blocs de politique restent par défaut, vous obtenez une entrée d’exécution distante avec raisonnement, pas un assistant intranet poli. Ce guide complète nos articles Linux systemd plus tunnel, Docker Compose production, installation multi-plateforme et observabilité production : ceux-là expliquent comment démarrer les processus et lire les journaux ; celui-ci réduit exposition et droits à un état auditable.
Considérez la Gateway comme partie du plan de contrôle. Tout ce qui s’authentifie peut orienter l’automatisation, lire la configuration et souvent joindre des API internes via les outils. D’où l’échec des configs « ça marche sur mon laptop » aux audits : on mesure le rayon d’explosion en cas de fuite de jeton, skill malveillant ou prompt piégé. La checklist ci-dessous permet aux ingénieurs plateforme et à la sécurité de noter le même artefact sans débattre du packaging d’abord.
Voici six lacunes fréquentes en revue. Ce n’est pas un rejet d’OpenClaw ; c’est le signal pour passer du mode développeur au mode production. Si deux déclencheurs apparaissent en deux semaines (bruit de scan, mauvaise session, jointures non autorisées, sortie inattendue), geler les features et durcir d’abord.
Surface d’écoute trop large : 0.0.0.0 ou l’équivalent « toutes interfaces » expose l’API d’admin et les ports de debug aux scanneurs.
Jetons statiques longue durée : mélange jeton Gateway et jeton d’entrée chat, stockage en clair dans dépôts ou dossiers synchronisés—chemin très court de la fuite au compromis.
Identité sans borne : sans liste blanche dmPolicy, de nouvelles sessions peuvent être acceptées par défaut ; les journaux ne répondent pas « qui s’est connecté à quel agent quand ».
Sortie trop permissive : sans networkPolicy ni liste blanche de sortie, injection de prompt ou skills malveillants peuvent exfiltrer métadonnées ou canaux secrets.
Exécution non validée : shell et fichiers à haut risque sans revue humaine ni seconde confirmation—un mauvais prompt peut causer des dommages irréversibles.
Changement intraçable : édition JSON à la main sans validation ni doctor—rollback au hasard ; impossible de diff la clé qui empêche le démarrage.
Trois priorités : d’abord resserrer l’écoute, puis faire tourner et coffrer les secrets, enfin empiler identité, sortie et politique d’exécution. Inverser l’ordre laisse de belles policies sur le papier pendant que le plan de gestion reste joignable depuis Internet car personne n’a revu les adresses de bind après le premier curl réussi.
Piège fréquent : confondre « le tunnel chiffre » avec « la Gateway n’a pas besoin de loopback ». Les tunnels protègent le fil et unifient l’entrée ; ils ne réalisent pas automatiquement la minimisation de surface d’écoute processus. La cible : Gateway ne faisant confiance qu’au reverse proxy ou client tunnel côté loopback, couche externe avec mTLS, WAF et limitation de débit. Si le client tunnel dérive, le service interne peut redevenir accessible.
Nuance opérationnelle : serveurs dual-home et conteneurs en réseau hôte peuvent ré-ouvrir des ports alors que le fichier dit localhost. Après patch OS, upgrade runtime ou changement CNI, revérifiez les sockets avec les outils de la plateforme et comparez au schéma. « Écouter 127.0.0.1 » est une propriété à tester, pas une chaîne à croire.
Enfin le durcissement n’est pas ponctuel. Chaque upgrade majeur OpenClaw, changement de fournisseur modèle ou nouveau skill relance validation et doctor, avec deltas dans le même dossier de changement que digests d’image et sauvegardes de config (guide d’observabilité). Cela s’aligne sur les runbooks upgrade/rollback : dérive de config et incidents de disponibilité sont deux faces d’un même système.
Notez séparément la « connectivité démo » et la résistance aux erreurs et au scan. La première, ce sont des pings et des happy paths ; la seconde, le quintuple liaison d’écoute, identité, sortie, exécution, traçabilité. Le tableau donne un vocabulaire commun plateforme/sécurité, découplé de « où c’est installé » et « qui reboot ».
| Dimension | Mode développeur (quick start local) | Mode production (toujours allumé, auditable) |
|---|---|---|
| Liaison d’écoute | Souvent élargie pour déboguer | Par défaut 127.0.0.1 ; reverse proxy ou tunnel au bord |
| Gestion des identifiants | Jetons en clair ou jetons jetables courts | Rotation, coffre-fort secrets, diffusion minimale |
| Identité de session | Fait confiance au LAN ou à un seul utilisateur | Liste blanche dmPolicy ; sources inconnues refusées |
| Sortie | Autorise par défaut modèles publics et outils | networkPolicy + liste blanche de sortie contre SSRF et exfiltration |
| Opérations à haut risque | Shell direct pour aller vite | Validation d’exécution ou équivalent humain ; audit des commandes persisté |
Une Gateway de production ne se juge pas au nombre de fonctionnalités, mais à l’échec sûr lorsque mauvais prompts et skills malveillants coexistent.
Quand les agents pilotent aussi des scripts de build ou release sur Mac distants, la frontière Gateway croise les secrets CI, registres internes et API fournisseurs. Inscrire listes blanches de sortie et validation d’exécution dans le runbook réduit les incidents en chaîne mieux que le seul pare-feu. La capacité Mac distante NodeMini convient à un backend d’exécution signé, mais il faut d’abord resserrer la Gateway pour éviter que les Mac cloud deviennent relais pour scripts publics arbitraires.
Employez la matrice en revues trimestrielles et questionnaires fournisseurs. Chaque ligne : propriétaire, preuve (extrait de config, lien ticket, contrôle auto), date de renouvellement. Les affirmations vagues « nous avons durci OpenClaw » deviennent échantillonables par un SOC ou un audit client sans salle de guerre.
Multi-environnements : dupliquez la matrice par palier et marquez où les raccourcis dev sont permis. Le staging doit refléter la forme des politiques de prod (secrets différents) ; sinon vous répétez des incidents sur de la fiction. L’écart staging/prod cache les surprises de rollback.
Prérequis : Gateway installée et saine en local ; noms de clés selon le schéma de votre version OpenClaw. Sauvegardez openclaw.json avant modification. Ordre : écoute réseau et jetons d’abord, puis identité et sortie, enfin validation d’exécution et vérifications.
Lier la loopback : limiter l’écoute à 127.0.0.1 (ou socket local documenté) ; aucun port de debug parasite joignable depuis l’extérieur.
Rotation des jetons : générer un jeton Gateway assez long via la CLI officielle, le stocker dans un gestionnaire de secrets ; interdire la synchro cloud ou les captures de chat.
Configurer dmPolicy : liste blanche des sources chat/session (IDs utilisateur ou session), refus par défaut des principaux inconnus, ticket de changement avec responsables.
Resserrer networkPolicy : couper la sortie totale par défaut ou passer à une egress_allowlist explicite (API modèles, domaines outils, registres internes) ; flux Mac distant : revue séparée des domaines Apple/Xcode.
Activer la validation d’exécution : revue humaine ou confirmation équivalente pour shell, fichiers destructeurs et outils à fort impact ; journaux d’audit vers les chemins de collecte de l’article d’observabilité.
Valider et exercer : config:validate puis doctor ; mini exercices red team : session non autorisée, fetch volontaire hors liste blanche. Les échecs doivent être des échecs sûrs, pas un succès silencieux.
Entre les étapes 2 et 3, inventoriez toutes les copies de l’ancien jeton : variables CI, sauvegardes, dotfiles. Rotation sans suppression des copies obsolètes, c’est une demi-rotation. Préférez des jetons courts en périphérie et des secrets longue durée seulement derrière le gestionnaire.
Pour l’étape 4, documentez les classes de dépendances : inférence, téléchargement d’artefacts, télémétrie, sorties service mesh. Chaque classe a son rythme de revue car les URL fournisseurs bougent plus vite que les registres internes. Automatisez un diff mensuel des requêtes DNS observées contre la liste blanche en bas d’environnement avant promotion.
// Fragment : intention seule ; respecter schéma et docs officielles avant prod
{
"gateway": {
"bind": "127.0.0.1",
"auth": { "token": "${ENV_OPENCLAW_GATEWAY_TOKEN}" }
},
"dmPolicy": {
"mode": "allowlist",
"allowIds": ["U-INTERNAL-1", "U-INTERNAL-2"]
},
"networkPolicy": {
"allow_egress": false,
"egress_allowlist": ["api.openai.com", "api.anthropic.com"]
}
}
Note : avec systemd ou Docker, documentez injection d’environnement et montages de volumes dans les unités ou commentaires Compose. Évitez « jeton en clair sur bind mount dans le conteneur » avec décalage de droits hôte.
Après déploiement de l’esquisse JSON en staging, testez chemins autorisés et refusés avec la même version Gateway que la prod. Déc calage doctor/runtime donne une fausse confiance ; épinglez les versions dans le ticket avec hash ou identifiant paquet à côté du snapshot de config.
openclaw doctor transforme « la Gateway ne démarre pas » en codes d’erreur et listes de clés manquantes. Pendant les fenêtres de changement, collez la sortie doctor dans le ticket, pas un résumé chat. Pour d’anciennes clés invalides connues, doctor --fix après revue—instantanés de configuration avant et après pour un rollback en secondes.
Schémas typiques : dmPolicy trop stricte (auth OK, sessions refusées), networkPolicy trop large (revue sécurité échoue) ou trop étroite (timeouts intermittents vers modèles/outils). Réponse : disponibilité par rollback snapshot, puis changements plus petits en canary, pas de devinettes en prod. Si la Gateway pilote des exécuteurs Mac distants, vérifiez aussi sortie et secrets côté Mac face à la nouvelle liste blanche.
Côté audit : traces de rotation de jetons, diffs dmPolicy/networkPolicy, extraits de journaux de validation d’exécution, rapports doctor par upgrade majeur. Avec l’observabilité, corrélez refus Gateway dans les logs process et journaux du reverse proxy pour distinguer régression de politique et saturation amont.
Game days périodiques avec compromis partiel supposé : rotation sous charge, retrait d’un principal test de dmPolicy, vérification que les alertes sont actionnables. But : mémoire musculaire avant l’incident réel, pas blâme. Documentez chaque faux positif et ajustez les seuils avec la même rigueur que pour les SLO.
Attention : ne laissez pas la validation d’exécution désactivée ni allow_egress ouvert globalement pour du dépannage prolongé. Si élargissement nécessaire : ticket limité dans le temps avec rollback automatique, sinon le « debug temporaire » devient porte dérobée permanente.
Après rollback, post-mortem sans blâme reliant symptômes aux contrôles : surface d’écoute, cycle de vie des jetons, diffs de politique, automatisation manquante. Réinjecter dans le sprint suivant évite de répéter les mêmes edits d’urgence sans validation.
Les puces résument documentation publique et usages communautaires pour aligner les revues ; sous-commandes CLI et champs de schéma dépendent de votre version OpenClaw installée.
Exposer la Gateway sur Internet sans jetons ni contraintes de sortie peut faire de belles démos tout en amplifiant SSRF, vol d’identifiants et risque supply-chain. Forcer des builds macOS dans une virtualisation non supportée accumule aussi dette de signature et Metal. Les équipes qui veulent un Mac distant stable comme backend d’exécution d’agent avec politiques réseau et secrets dans contrats et runbooks terminent d’abord l’exposition minimale de la Gateway, puis placent la charge sur des nœuds Mac cloud choisis par région et palier disque. La Gateway décide qui appelle modèles et outils ; le Mac distant porte les builds et releases reproductibles dans l’écosystème Apple, reliés par listes blanches et chaînes d’approbation.
Location cloud Mac mini NodeMini s’aligne sur ce modèle une fois les politiques Gateway en place : environnements macOS prévisibles pour CI et automatisation sans fusionner plan de contrôle et charges invitées. Négociez SLA disque, région et fenêtres de maintenance avec les contrôles des sections 1 à 4 pour que l’achat reflète l’architecture.
Avant de clore le programme, une attestation d’une page : propriétaires, liens de preuve, date du dernier doctor. Elle circule plus vite que la fouille de dépôt lors des revues sécurité clients et audits internes.
0.0.0.0 expose le plan d’administration sur toutes les interfaces ; scan et appels non autorisés coûtent peu. Préférez 127.0.0.1 et terminez le TLS avec contrôle d’accès au reverse proxy ou tunnel. Si vous avez besoin d’une couche d’exécution sur Mac distant, consultez les tarifs de location Mac mini pour planifier nœuds et sortie, puis alignez la liste blanche et parcourez le centre d’aide.
Lancez d’abord la validation de configuration (par exemple openclaw config:validate), puis openclaw doctor sur schéma et runtime ; utilisez doctor --fix dans une fenêtre de changement pour nettoyer des clés invalides connues, en gardant des instantanés avant/après.
Commencez par la liste de catégorie OpenClaw et le centre d’aide, puis revenez à cette checklist pour confirmer liaison, jetons, dmPolicy et networkPolicy actifs.