OpenClaw derrière Cloudflare Tunnel et Access

L’une des trois topologies d’accès distant prises en charge dans la documentation, à côté de Tailscale et d’un tunnel SSH, est un tunnel Cloudflare avec Cloudflare Access devant : la passerelle garde sa liaison de boucle locale, aucun port n’est exposé et aucune règle de pare-feu entrante n’est nécessaire parce que le démon du tunnel appelle vers l’extérieur depuis l’hôte, et Access authentifie chaque requête avec votre fournisseur d’identité avant qu’elle n’atteigne OpenClaw. Choisissez-la quand vous voulez une URL HTTPS publique stable et une authentification unique devant l’interface de contrôle. Voici les pièces, la réserve que la documentation énonce clairement, les cinq étapes, la question des nœuds, et les règles de production.

Les pièces et la réserve

• Navigateur, CLI ou nœud atteint Cloudflare Access, qui authentifie et injecte des en-têtes d’identité, puis le tunnel porte la requête jusqu’au port de boucle locale.
• La passerelle ne réauthentifie pas la personne et ne vérifie pas la signature du jeton Access : elle vérifie la source du proxy de confiance et la présence des en-têtes configurés, puis fait confiance à l’en-tête d’utilisateur.
• Parce que l’autorisation de boucle locale laisse aussi d’autres processus locaux présenter ces en-têtes, la documentation dit de garder le port de la passerelle privé à l’hôte et de n’y faire tourner que des charges de confiance ; la frontière de sécurité est le port de boucle locale verrouillé plus Access et le tunnel comme seul chemin externe.
• Il vous faut un compte Cloudflare avec la zone et Zero Trust activé, le démon du tunnel sur l’hôte de la passerelle et sur toute machine qui utilisera la CLI, une passerelle en boucle locale en marche, et le mode d’authentification par proxy de confiance sur lequel repose cette topologie.

Élargir la liaison réexpose la passerelle à côté du tunnel et contourne entièrement Access.

Les cinq étapes

Routez le tunnel vers la boucle locale avec une règle d’entrée qui associe votre nom d’hôte au port de la passerelle et lancez le démon comme service. Protégez le nom d’hôte avec une application Access dont la politique autorise vos utilisateurs, en notant les deux en-têtes qu’Access ajoute, le courriel authentifié et l’assertion signée, dont OpenClaw ne vérifie que la présence. Faites confiance à ces en-têtes dans la passerelle : mode d’authentification proxy de confiance, l’en-tête d’utilisateur et l’en-tête requis nommés, la boucle locale autorisée parce que le démon se connecte depuis l’adresse locale, et les proxys de confiance limités à la boucle locale ; exiger l’en-tête d’assertion est une seconde vérification de présence, pas une vérification cryptographique. Décidez comment les nœuds entrent, ci-dessous. Connectez chaque client : l’interface de contrôle se connecte par Access et la passerelle associe l’identité à une session d’opérateur ; la CLI et la TUI ne portent pas de cookies de navigateur, donc elles présentent un jeton Access à la montée en WebSocket par la configuration d’authentification de bordure après une connexion unique avec le démon ; les nœuds suivent la décision les concernant.

Nœuds, vérification, production

• Recommandé : donnez au nœud un jeton de service Access par une politique d’authentification de service, exportez l’identifiant et le secret client sur l’hôte du nœud, et joignez avec l’option de service ; la commande de connexion les conserve comme références adossées à l’environnement, au prix qu’un lien de jonction n’est plus à coller tel quel.
• Alternative : exemptez la route de jonction et la route des workers de l’identité Access, puisque toutes deux imposent leurs propres identifiants de courte durée, un code de jonction à usage unique avec une durée de vie, des limites de débit par IP et un introuvable opaque en cas d’échec ; cela garde les liens de jonction à coller tels quels au prix de rendre deux routes joignables publiquement. Ne faites ni l’un ni l’autre et la commande de connexion échoue contre le tunnel alors que le navigateur fonctionne, parce que la requête de jonction est redirigée vers la page de connexion.
• Vérifiez avec la TUI, qui devrait atteindre l’URL sécurisée et afficher connecté ; une première connexion peut demander un appairage d’appareil, approuvé dans l’interface de contrôle ou avec la commande des appareils sur l’hôte, et atteindre l’invite d’appairage propre à la passerelle est la preuve qu’Access a été satisfait. En production, gardez la liaison en boucle locale, gardez les proxys de confiance limités à la boucle locale, n’activez l’approbation automatique des appareils que si quiconque passe Access doit obtenir un appareil appairé avec les portées listées, et attendez-vous à ce que les utilisateurs de la CLI se reconnectent quand leur jeton expire.

L’accès distant à OpenClaw est la page à côté de laquelle se trouve cette topologie, avec la configuration d’authentification de bordure côté client vers laquelle elle renvoie, et OpenClaw et Tailscale l’alternative par tailnet.

Dépannage

Un 302 à la montée en WebSocket depuis la CLI ou la TUI veut dire qu’Access l’a interceptée, donc configurez les en-têtes d’authentification de bordure. Un navigateur qui fonctionne avec une commande de connexion qui échoue veut dire que les routes des nœuds sont encore derrière Access. Un fournisseur exec qui sort avec le code un veut dire que l’environnement nettoyé a caché le dossier personnel dont le démon a besoin pour lire son jeton en cache. Une erreur de lien symbolique veut dire que la commande doit pointer vers le binaire résolu. Et une passerelle où chaque requête est anonyme veut dire que l’autorisation de boucle locale est absente, donc les en-têtes du démon local sont ignorés. OpenClaw sur Cloudflare Containers est l’autre page Cloudflare de la documentation, qui fait tourner la passerelle elle-même sur Cloudflare, et Les contrôles de sécurité de la passerelle OpenClaw les modes d’authentification côté serveur auxquels appartient le proxy de confiance.

Sur Diali

Sur Diali, l’identité devant la passerelle est votre session du tableau de bord à notre bordure, et l’instance elle-même n’est jamais joignable autrement, ce qui est la même forme que cette topologie avec le tunnel et la politique tenus pour vous. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière.

• Boucle locale dedans, tunnel dehors, Access devant.
• La présence des en-têtes est ce qui est cru, pas la signature.
• Les nœuds ont besoin d’un jeton de service ou de deux routes exemptées.