Des chercheurs en sécurité ont trouvé plus de 135 000 instances OpenClaw totalement exposées sur Internet. Nombre d’entre elles étaient vulnérables à l’exécution de code à distance. La crise de sécurité OpenClaw est bien réelle : CVE critiques, skills malveillants et un problème fondamental dans la gestion de l’authentification par la plupart des déploiements. Lancer OpenClaw sur un VPS avec docker run est simple. Le faire tourner en toute sécurité est un tout autre défi.

Kubernetes résout ce problème. Vous obtenez l’isolation réseau, les limites de ressources, les redémarrages automatiques et des paramètres de sécurité dont la configuration manuelle prendrait des heures. Et avec l’opérateur Kubernetes OpenClaw, vous obtenez tout cela à partir d’un seul fichier YAML.

Ce guide vous emmène de zéro à un agent OpenClaw prêt pour la production sur Kubernetes. Chaque bloc YAML est prêt à être copié-collé.

Pourquoi un opérateur

Faire tourner OpenClaw sur Kubernetes va bien au-delà d’un Deployment et d’un Service. Vous avez besoin d’isolation réseau, de gestion des Secrets, de stockage persistant, de surveillance de la santé, de déploiements de configuration et, optionnellement, d’automatisation du navigateur. Configurer tout cela correctement à la main est fastidieux et source d’erreurs.

Un opérateur Kubernetes encode ces préoccupations dans une seule Custom Resource. Vous déclarez ce que vous voulez, et l’opérateur le réconcilie en continu avec les bons objets Kubernetes. Cela vous apporte :

  • La sécurité par défaut. Chaque agent tourne en UID 1000, toutes les capabilities Linux sont supprimées, Seccomp est activé, le système de fichiers root est en lecture seule, et une NetworkPolicy deny-by-default n’autorise que le DNS et le HTTPS en sortie. Aucun durcissement manuel nécessaire.
  • Les mises à jour automatiques avec rollback. L’opérateur interroge le registre OCI pour les nouvelles versions, sauvegarde l’espace de travail, déploie la mise à jour et effectue automatiquement un rollback si le nouveau pod échoue aux health checks.
  • Les déploiements de configuration. Modifiez votre spec.config.raw et l’opérateur détecte le changement de hash du contenu, déclenchant une mise à jour progressive. Idem pour la rotation des secrets.
  • Sauvegarde et restauration. Sauvegarde automatique de l’espace de travail vers un stockage compatible S3 lors de la suppression d’une instance. Restauration dans une nouvelle instance depuis n’importe quel snapshot.
  • Authentification du gateway. Génère automatiquement un token gateway par instance. Pas d’appairage manuel, pas de mDNS (qui ne fonctionne pas dans Kubernetes de toute façon).
  • Détection de dérive. Toutes les 5 minutes, l’opérateur vérifie que chaque ressource gérée correspond à l’état souhaité. Si quelqu’un modifie manuellement une NetworkPolicy ou supprime un PDB, il est rétabli.

Prérequis

Vous avez besoin de :

  • Un cluster Kubernetes (1.28+). Toute distribution conforme fonctionne : EKS, GKE, AKS, k3s, ou un cluster Kind local pour les tests.
  • kubectl configuré pour votre cluster.
  • helm v3 installé.
  • Une clé API pour votre fournisseur AI (Anthropic, OpenAI, ou tout endpoint compatible OpenAI).

Étape 1 : Installer l’opérateur

L’opérateur est distribué sous forme de chart Helm OCI. Une seule commande l’installe :

helm install openclaw-operator \
  oci://ghcr.io/openclaw-rocks/charts/openclaw-operator \
  --namespace openclaw-operator-system \
  --create-namespace

Vérifiez qu’il tourne :

kubectl get pods -n openclaw-operator-system

Vous devriez voir le pod de l’opérateur à l’état Running. L’opérateur installe également un webhook de validation qui empêche les configurations non sécurisées (comme l’exécution en root).

Étape 2 : Créer votre Secret de clé API

Stockez la clé API de votre fournisseur AI dans un Secret Kubernetes. L’opérateur l’injectera dans le conteneur de l’agent :

kubectl create namespace openclaw

kubectl create secret generic openclaw-api-keys \
  --namespace openclaw \
  --from-literal=ANTHROPIC_API_KEY=sk-ant-your-key-here

Pour OpenAI ou d’autres fournisseurs, utilisez le nom de variable d’environnement approprié (OPENAI_API_KEY, OPENROUTER_API_KEY, etc.). Vous pouvez inclure plusieurs fournisseurs dans le même Secret.

Conseil : Pour la production, envisagez d’utiliser l’External Secrets Operator pour synchroniser les clés depuis AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager ou Azure Key Vault. La documentation de l’opérateur contient des exemples détaillés.

Étape 3 : Déployer votre premier agent

Créez un fichier nommé my-agent.yaml :

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent
  namespace: openclaw
spec:
  envFrom:
    - secretRef:
        name: openclaw-api-keys
  config:
    raw:
      agents:
        defaults:
          model:
            primary: "anthropic/claude-sonnet-4-20250514"
  storage:
    persistence:
      enabled: true
      size: 10Gi

Appliquez-le :

kubectl apply -f my-agent.yaml

Cette unique ressource crée un StatefulSet, un Service, un ServiceAccount, un Role, un RoleBinding, une ConfigMap, un PVC, un PDB, une NetworkPolicy et un Secret de token gateway. L’opérateur réconcilie le tout.

Étape 4 : Vérifier qu’il tourne

Observez le démarrage de l’instance :

kubectl get openclawinstances -n openclaw -w

NAME       PHASE        READY   AGE
my-agent   Provisioning False   10s
my-agent   Running      True    45s

Dès que la phase affiche Running et Ready est True, votre agent est en ligne. Consultez les logs :

kubectl logs -n openclaw statefulset/my-agent -f

Pour interagir avec votre agent, faites un port-forward du gateway :

kubectl port-forward -n openclaw svc/my-agent 18789:18789

Puis ouvrez http://localhost:18789 dans votre navigateur.

Étape 5 : Connecter un canal

OpenClaw prend en charge Telegram, Discord, WhatsApp, Signal et d’autres canaux de messagerie. Chaque canal est configuré via des variables d’environnement. Ajoutez le token correspondant à votre Secret :

kubectl create secret generic openclaw-channel-keys \
  --namespace openclaw \
  --from-literal=TELEGRAM_BOT_TOKEN=your-bot-token-here

Puis référencez-le dans votre instance :

spec:
  envFrom:
    - secretRef:
        name: openclaw-api-keys
    - secretRef:
        name: openclaw-channel-keys

OpenClaw détecte automatiquement le token et active le canal. Aucune configuration supplémentaire nécessaire.

Cela couvre les bases. Votre agent tourne, est sécurisé et accessible. Le reste de ce guide couvre les fonctionnalités optionnelles que vous pouvez activer quand vous le souhaitez.

Automatisation du navigateur

OpenClaw peut naviguer sur le web, prendre des captures d’écran et interagir avec les pages. L’opérateur rend cela possible en une seule ligne. Il exécute un sidecar Chromium durci dans le même pod, connecté via localhost :

spec:
  chromium:
    enabled: true
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: 1000m
        memory: 2Gi

L’opérateur injecte automatiquement une variable d’environnement CHROMIUM_URL dans le conteneur principal. Le sidecar tourne en UID 1001 avec un système de fichiers root en lecture seule et son propre contexte de sécurité.

Skills et dépendances d’exécution

Les skills OpenClaw depuis ClawHub peuvent être installés de manière déclarative. L’opérateur lance un conteneur d’initialisation qui récupère chaque skill avant le démarrage de l’agent :

spec:
  skills:
    - "@anthropic/mcp-server-fetch"
    - "@anthropic/mcp-server-filesystem"

Si vos skills ou serveurs MCP nécessitent pnpm ou Python, activez les conteneurs d’initialisation intégrés pour les dépendances d’exécution :

spec:
  runtimeDeps:
    pnpm: true    # Installs pnpm via corepack
    python: true  # Installs Python 3.12 + uv

Les conteneurs d’initialisation installent ces outils sur le PVC de données, de sorte qu’ils persistent entre les redémarrages sans alourdir l’image du conteneur.

Mises à jour automatiques

OpenClaw publie fréquemment de nouvelles versions. L’opérateur peut les suivre automatiquement, sauvegarder avant la mise à jour et revenir en arrière en cas de problème :

spec:
  autoUpdate:
    enabled: true
    checkInterval: "12h"
    backupBeforeUpdate: true
    rollbackOnFailure: true
    healthCheckTimeout: "10m"

Lorsqu’une nouvelle version apparaît dans le registre, l’opérateur :

  1. Crée une sauvegarde du PVC de l’espace de travail vers un stockage compatible S3
  2. Met à jour le tag de l’image sur le StatefulSet
  3. Attend jusqu’à healthCheckTimeout que le pod passe les vérifications de disponibilité
  4. Si le pod ne devient pas ready, restaure le tag d’image précédent et la sauvegarde

Après 3 rollbacks consécutifs échoués, l’opérateur met en pause les mises à jour automatiques et définit une condition pour que vous puissiez enquêter.

Remarque : La mise à jour automatique est un no-op pour les images épinglées par digest (spec.image.digest). Si vous épinglez par digest, vous contrôlez les mises à jour manuellement.

Durcissement pour la production

L’opérateur est sécurisé par défaut. Voici les paramètres supplémentaires pour les déploiements en production.

Surveillance avec Prometheus

Activez le ServiceMonitor pour collecter les métriques de l’opérateur et des instances :

spec:
  observability:
    metrics:
      enabled: true
      serviceMonitor:
        enabled: true
        interval: "30s"

L’opérateur expose openclaw_reconcile_total, openclaw_reconcile_duration_seconds, openclaw_instance_phase et des compteurs de mises à jour automatiques.

Planifier sur des nœuds dédiés

Si vous exploitez un cluster mixte, utilisez nodeSelector et tolerations pour épingler les agents sur des nœuds dédiés :

spec:
  availability:
    nodeSelector:
      openclaw.rocks/nodepool: openclaw
    tolerations:
      - key: openclaw.rocks/dedicated
        value: openclaw
        effect: NoSchedule

Ajouter des règles d’egress personnalisées

La NetworkPolicy par défaut n’autorise que le DNS (port 53) et le HTTPS (port 443). Si votre agent doit atteindre d’autres services (une base de données, une file de messages, une API interne), ajoutez des règles d’egress :

spec:
  security:
    networkPolicy:
      additionalEgress:
        - to:
            - ipBlock:
                cidr: 10.0.0.0/8
          ports:
            - port: 5432
              protocol: TCP

Identité du fournisseur cloud

Pour AWS IRSA ou GCP Workload Identity, annotez le ServiceAccount géré :

spec:
  security:
    rbac:
      serviceAccountAnnotations:
        eks.amazonaws.com/role-arn: "arn:aws:iam::123456789:role/openclaw"

Proxys d’entreprise et CA privées

Si votre cluster utilise un proxy interceptant le TLS, injectez un bundle CA :

spec:
  security:
    caBundle:
      configMapName: corporate-ca-bundle
      key: ca-bundle.crt

L’opérateur monte le bundle CA dans tous les conteneurs et définit NODE_EXTRA_CA_CERTS automatiquement.

GitOps

Le CRD OpenClawInstance est un simple fichier YAML. Cela signifie qu’il s’intègre directement dans un workflow GitOps. Stockez vos manifestes d’agents dans un dépôt git et laissez ArgoCD ou Flux les synchroniser avec votre cluster.

Une structure de dépôt typique :

gitops/
└── agents/
    ├── kustomization.yaml
    ├── namespace.yaml
    ├── agent-a.yaml
    └── agent-b.yaml

Chaque modification passe par une pull request. Votre équipe examine le diff. Merge sur main, et ArgoCD l’applique. Plus de kubectl apply depuis les laptops, plus de dérive de configuration, une piste d’audit complète.

Le hachage de configuration de l’opérateur rend cela particulièrement fluide. Quand ArgoCD synchronise une spec.config.raw modifiée, l’opérateur détecte le changement de hash du contenu et déclenche automatiquement une mise à jour progressive. Idem pour la rotation des secrets : l’opérateur surveille les Secrets référencés et redémarre les pods lorsqu’ils changent.

Sauvegarde et restauration

L’opérateur prend en charge les sauvegardes compatibles S3. Lorsque vous supprimez une instance, l’opérateur crée automatiquement une sauvegarde du PVC de l’espace de travail avant la suppression.

Pour restaurer un agent depuis une sauvegarde dans une nouvelle instance :

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: my-agent-restored
  namespace: openclaw
spec:
  restoreFrom: "s3://bucket/path/to/backup.tar.gz"
  envFrom:
    - secretRef:
        name: openclaw-api-keys
  storage:
    persistence:
      enabled: true
      size: 10Gi

L’opérateur télécharge le snapshot, le décompresse dans le PVC et démarre l’agent avec toutes les données de l’espace de travail précédent, les skills et l’historique de conversation intacts.

Inférence locale avec Ollama

Si vous souhaitez que vos agents utilisent des modèles locaux (pour la confidentialité, la latence ou le coût), l’opérateur offre un support Ollama de premier ordre. Pas besoin de configurer un sidecar manuellement : spec.ollama gère le conteneur, le pré-téléchargement des modèles, le stockage et l’allocation GPU :

spec:
  ollama:
    enabled: true
    models:
      - "llama3.2"
      - "nomic-embed-text"
    gpu: 1
    resources:
      requests:
        cpu: "2"
        memory: 4Gi
      limits:
        cpu: "4"
        memory: 8Gi
    storage:
      sizeLimit: 30Gi

Lorsqu’il est activé, l’opérateur :

  1. Ajoute un conteneur sidecar Ollama au pod
  2. Lance un conteneur d’initialisation qui pré-télécharge les modèles listés avant le démarrage de l’agent
  3. Injecte OLLAMA_HOST=http://localhost:11434 dans le conteneur principal
  4. Alloue le GPU NVIDIA demandé via les limites de ressources nvidia.com/gpu

Par défaut, les modèles sont stockés dans un volume emptyDir avec une limite de taille configurable. Pour un stockage persistant des modèles entre les redémarrages (afin que les modèles ne soient pas retéléchargés à chaque fois), utilisez un PVC existant :

spec:
  ollama:
    enabled: true
    models: ["llama3.2"]
    storage:
      existingClaim: ollama-models-pvc

Intégration Tailscale

Exposez votre agent à votre tailnet sans Ingress, sans load balancer ni IP publique. Le champ spec.tailscale de l’opérateur gère l’injection de la clé d’authentification, l’enrichissement de la configuration et les règles NetworkPolicy :

spec:
  tailscale:
    enabled: true
    mode: serve       # or "funnel" for public internet access
    authKeySecretRef:
      name: tailscale-authkey
    hostname: my-agent

Créez le Secret de clé d’authentification avec une clé éphémère et réutilisable depuis la console d’administration Tailscale :

kubectl create secret generic tailscale-authkey \
  --namespace openclaw \
  --from-literal=authkey=tskey-auth-...

En mode serve (par défaut), seuls les membres de votre tailnet peuvent accéder à l’agent. En mode funnel, Tailscale l’expose sur l’Internet public avec HTTPS automatique.

L’opérateur effectue automatiquement les actions suivantes :

  • Injecte les variables d’environnement TS_AUTHKEY et TS_HOSTNAME
  • Fusionne gateway.tailscale.mode et gateway.tailscale.resetOnExit dans la configuration OpenClaw
  • Ajoute les règles d’egress STUN et WireGuard à la NetworkPolicy

Pour une connexion SSO sans mot de passe pour les membres du tailnet, activez authSSO :

spec:
  tailscale:
    enabled: true
    mode: serve
    authKeySecretRef:
      name: tailscale-authkey
    authSSO: true

Cela définit gateway.auth.allowTailscale=true dans la configuration OpenClaw, permettant aux membres du tailnet d’accéder à l’agent sans token gateway séparé.

Sidecars et conteneurs d’initialisation personnalisés

Pour les cas d’utilisation au-delà du support intégré Ollama et Tailscale, l’opérateur accepte des sidecars et des conteneurs d’initialisation arbitraires. Exécutez un Cloud SQL Proxy pour l’accès à la base de données, un transmetteur de logs ou tout autre assistant à côté de votre agent :

spec:
  sidecars:
    - name: cloudsql-proxy
      image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2
      args: ["--structured-logs", "project:region:instance"]
      resources:
        requests:
          cpu: 100m
          memory: 128Mi

Les conteneurs d’initialisation personnalisés s’exécutent après le pipeline d’initialisation de l’opérateur (seeding de configuration, pnpm, Python, skills) :

spec:
  initContainers:
    - name: fetch-data
      image: curlimages/curl:8.5.0
      command: ["sh", "-c", "curl -o /data/dataset.json https://..."]
      volumeMounts:
        - name: data
          mountPath: /data

Mode de fusion de configuration

Par défaut, l’opérateur écrase le fichier de configuration à chaque redémarrage de pod. Si votre agent modifie sa propre configuration à l’exécution (via des skills ou de l’auto-modification), définissez mergeMode: merge pour fusionner en profondeur la configuration de l’opérateur avec la configuration PVC existante :

spec:
  config:
    mergeMode: merge
    raw:
      agents:
        defaults:
          model:
            primary: "anthropic/claude-sonnet-4-20250514"

En mode fusion, les clés spécifiées par l’opérateur ont la priorité, mais les clés ajoutées par l’agent lui-même survivent aux redémarrages.

L’exemple complet

Voici un manifeste prêt pour la production qui combine tout ce qui est présenté dans ce guide :

apiVersion: openclaw.rocks/v1alpha1
kind: OpenClawInstance
metadata:
  name: production-agent
  namespace: openclaw
spec:
  envFrom:
    - secretRef:
        name: openclaw-api-keys

  config:
    mergeMode: merge
    raw:
      agents:
        defaults:
          model:
            primary: "anthropic/claude-sonnet-4-20250514"

  skills:
    - "@anthropic/mcp-server-fetch"

  runtimeDeps:
    pnpm: true

  chromium:
    enabled: true
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: 1000m
        memory: 2Gi

  ollama:
    enabled: true
    models: ["llama3.2"]
    gpu: 1
    resources:
      requests:
        cpu: "2"
        memory: 4Gi

  tailscale:
    enabled: true
    mode: serve
    authKeySecretRef:
      name: tailscale-authkey
    authSSO: true

  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2000m
      memory: 4Gi

  storage:
    persistence:
      enabled: true
      size: 10Gi

  autoUpdate:
    enabled: true
    checkInterval: "24h"
    backupBeforeUpdate: true
    rollbackOnFailure: true

  observability:
    metrics:
      enabled: true
      serviceMonitor:
        enabled: true

  # Remove or adjust these if you don't use dedicated nodes
  availability:
    nodeSelector:
      openclaw.rocks/nodepool: openclaw
    tolerations:
      - key: openclaw.rocks/dedicated
        value: openclaw
        effect: NoSchedule

Appliquez-le, et vous disposez d’un agent AI durci, mis à jour automatiquement, capable de naviguer, avec inférence locale, accès tailnet, surveillance, sauvegarde et isolation réseau. Un seul kubectl apply.

Ce que vous obtenez par défaut

Sans toucher au moindre paramètre de sécurité, chaque agent déployé par l’opérateur est livré avec :

  • Exécution non-root (UID 1000)
  • Système de fichiers root en lecture seule
  • Toutes les capabilities Linux supprimées
  • Profil Seccomp RuntimeDefault
  • NetworkPolicy deny-by-default (egress DNS + HTTPS uniquement)
  • ServiceAccount par instance sans montage automatique de token
  • PodDisruptionBudget
  • Sondes de liveness, readiness et startup
  • Token d’authentification gateway généré automatiquement
  • Réconciliation de dérive toutes les 5 minutes

Un webhook de validation bloque les tentatives d’exécution en root et avertit en cas de NetworkPolicies désactivées, d’absence de TLS sur l’Ingress et de clés de fournisseur AI non détectées.

Prochaines étapes

Si vous rencontrez des problèmes ou avez des retours, ouvrez une issue sur GitHub. Les PRs sont également les bienvenues.

Si vous ne souhaitez pas gérer Kubernetes vous-même, OpenClaw.rocks s’occupe de tout pour vous. Choisissez un plan, connectez un canal, et votre agent est en ligne en quelques secondes.