Sicherheitsforscher haben über 135.000 OpenClaw-Instanzen entdeckt, die völlig ungeschützt im Internet erreichbar sind. Viele davon waren anfällig für Remote Code Execution. Die OpenClaw-Sicherheitskrise ist real: kritische CVEs, bösartige Skills und ein grundlegendes Problem damit, wie die meisten Deployments Authentifizierung handhaben. OpenClaw mit docker run auf einem VPS zu starten ist einfach. Es sicher zu betreiben ist eine ganz andere Herausforderung.

Kubernetes löst dieses Problem. Sie erhalten Netzwerkisolierung, Ressourcenlimits, automatische Neustarts und Sicherheitsstandards, deren manuelle Konfiguration Stunden dauern würde. Und mit dem OpenClaw Kubernetes Operator bekommen Sie all das aus einer einzigen YAML-Datei.

Diese Anleitung führt Sie von null zu einem produktionsreifen OpenClaw Agent auf Kubernetes. Jeder YAML-Block ist bereit zum Kopieren und Einfügen.

Warum ein Operator

OpenClaw auf Kubernetes zu betreiben ist mehr als ein Deployment und ein Service. Sie brauchen Netzwerkisolierung, Secret-Management, persistenten Speicher, Health Monitoring, Config Rollouts und optional Browser-Automatisierung. All das korrekt per Hand zu verdrahten ist mühsam und fehleranfällig.

Ein Kubernetes Operator kodiert diese Anforderungen in eine einzige Custom Resource. Sie deklarieren, was Sie wollen, und der Operator gleicht es kontinuierlich mit den richtigen Kubernetes-Objekten ab. Das gibt Ihnen:

  • Sicherheit ab Werk. Jeder Agent läuft als UID 1000, alle Linux Capabilities sind deaktiviert, Seccomp ist aktiviert, das Root-Dateisystem ist schreibgeschützt, und eine Default-Deny NetworkPolicy erlaubt nur DNS- und HTTPS-Egress. Kein manuelles Hardening nötig.
  • Auto-Updates mit Rollback. Der Operator prüft die OCI Registry auf neue Versionen, sichert den Workspace, rollt das Update aus und macht automatisch ein Rollback, wenn der neue Pod die Health Checks nicht besteht.
  • Config Rollouts. Ändern Sie Ihre spec.config.raw, und der Operator erkennt die geänderte Content-Hash und löst ein Rolling Update aus. Dasselbe gilt für Secret-Rotation.
  • Backup und Restore. Automatisches Workspace-Backup auf S3-kompatiblen Speicher bei Instanz-Löschung. Wiederherstellung in eine neue Instanz aus jedem Snapshot.
  • Gateway Auth. Generiert automatisch einen Gateway-Token pro Instanz. Kein manuelles Pairing, kein mDNS (das in Kubernetes ohnehin nicht funktioniert).
  • Drift Detection. Alle 5 Minuten prüft der Operator, ob jede verwaltete Ressource dem gewünschten Zustand entspricht. Wenn jemand manuell eine NetworkPolicy bearbeitet oder ein PDB löscht, wird es zurückgesetzt.

Voraussetzungen

Sie benötigen:

  • Einen Kubernetes-Cluster (1.28+). Jede konforme Distribution funktioniert: EKS, GKE, AKS, k3s oder ein lokaler Kind-Cluster zum Testen.
  • kubectl, konfiguriert für Ihren Cluster.
  • helm v3 installiert.
  • Einen API Key für Ihren AI-Provider (Anthropic, OpenAI oder einen beliebigen OpenAI-kompatiblen Endpoint).

Schritt 1: Den Operator installieren

Der Operator wird als OCI Helm Chart ausgeliefert. Ein Befehl installiert ihn:

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

Überprüfen Sie, ob er läuft:

kubectl get pods -n openclaw-operator-system

Sie sollten den Operator Pod im Status Running sehen. Der Operator installiert außerdem einen Validating Webhook, der unsichere Konfigurationen verhindert (wie das Ausführen als Root).

Schritt 2: Ihr API-Key-Secret erstellen

Speichern Sie Ihren AI-Provider-API-Key in einem Kubernetes Secret. Der Operator injiziert ihn in den Agent-Container:

kubectl create namespace openclaw

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

Für OpenAI oder andere Provider verwenden Sie den entsprechenden Umgebungsvariablennamen (OPENAI_API_KEY, OPENROUTER_API_KEY usw.). Sie können mehrere Provider im selben Secret hinterlegen.

Tipp: Für die Produktion sollten Sie den External Secrets Operator in Betracht ziehen, um Keys aus AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager oder Azure Key Vault zu synchronisieren. Die Operator-Dokumentation enthält detaillierte Beispiele.

Schritt 3: Ihren ersten Agent deployen

Erstellen Sie eine Datei namens 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

Wenden Sie es an:

kubectl apply -f my-agent.yaml

Diese einzelne Ressource erstellt ein StatefulSet, einen Service, ein ServiceAccount, eine Role, ein RoleBinding, eine ConfigMap, ein PVC, ein PDB, eine NetworkPolicy und ein Gateway-Token-Secret. Der Operator gleicht alles ab.

Schritt 4: Prüfen, ob es läuft

Beobachten Sie, wie die Instanz hochfährt:

kubectl get openclawinstances -n openclaw -w

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

Sobald die Phase Running und Ready True anzeigt, ist Ihr Agent aktiv. Prüfen Sie die Logs:

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

Um mit Ihrem Agent zu interagieren, leiten Sie das Gateway per Port-Forward weiter:

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

Öffnen Sie dann http://localhost:18789 in Ihrem Browser.

Schritt 5: Einen Kanal verbinden

OpenClaw unterstützt Telegram, Discord, WhatsApp, Signal und weitere Messaging-Kanäle. Jeder Kanal wird über Umgebungsvariablen konfiguriert. Fügen Sie das entsprechende Token zu Ihrem Secret hinzu:

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

Referenzieren Sie es dann in Ihrer Instanz:

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

OpenClaw erkennt das Token automatisch und aktiviert den Kanal. Keine zusätzliche Konfiguration nötig.

Das deckt die Grundlagen ab. Ihr Agent läuft, ist abgesichert und erreichbar. Der Rest dieser Anleitung behandelt optionale Features, die Sie aktivieren können, wenn Sie bereit sind.

Browser-Automatisierung

OpenClaw kann im Web surfen, Screenshots erstellen und mit Seiten interagieren. Der Operator macht das zu einer einzeiligen Ergänzung. Er führt einen gehärteten Chromium Sidecar im selben Pod aus, verbunden über localhost:

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

Der Operator injiziert automatisch eine CHROMIUM_URL-Umgebungsvariable in den Hauptcontainer. Der Sidecar läuft als UID 1001 mit einem schreibgeschützten Root-Dateisystem und eigenem Security Context.

Skills und Laufzeitabhängigkeiten

OpenClaw Skills von ClawHub können deklarativ installiert werden. Der Operator führt einen Init Container aus, der jeden Skill vor dem Start des Agents abruft:

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

Wenn Ihre Skills oder MCP Server pnpm oder Python benötigen, aktivieren Sie die eingebauten Init Container für Laufzeitabhängigkeiten:

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

Die Init Container installieren diese Tools auf dem Data PVC, sodass sie Neustarts überleben, ohne das Container-Image aufzublähen.

Auto-Updates

OpenClaw veröffentlicht häufig neue Versionen. Der Operator kann diese automatisch verfolgen, vor dem Update sichern und bei Problemen zurückrollen:

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

Wenn eine neue Version in der Registry erscheint, führt der Operator folgende Schritte aus:

  1. Erstellt ein Backup des Workspace PVC auf S3-kompatiblen Speicher
  2. Aktualisiert den Image Tag am StatefulSet
  3. Wartet bis zu healthCheckTimeout, bis der Pod die Readiness Checks besteht
  4. Falls der Pod nicht ready wird, stellt er den vorherigen Image Tag und das Backup wieder her

Nach 3 aufeinanderfolgenden fehlgeschlagenen Rollbacks pausiert der Operator Auto-Update und setzt eine Condition, damit Sie untersuchen können.

Hinweis: Auto-Update ist ein No-Op für Digest-gepinnte Images (spec.image.digest). Wenn Sie per Digest pinnen, steuern Sie Updates manuell.

Produktionshärtung

Der Operator wird standardmäßig sicher ausgeliefert. Hier sind die zusätzlichen Stellschrauben für Produktions-Deployments.

Monitoring mit Prometheus

Aktivieren Sie den ServiceMonitor, um Operator- und Instanz-Metriken zu scrapen:

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

Der Operator stellt openclaw_reconcile_total, openclaw_reconcile_duration_seconds, openclaw_instance_phase und Auto-Update-Zähler bereit.

Auf dedizierten Nodes planen

Wenn Sie einen gemischten Cluster betreiben, verwenden Sie nodeSelector und tolerations, um Agents an dedizierte Nodes zu binden:

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

Benutzerdefinierte Egress-Regeln hinzufügen

Die Standard-NetworkPolicy erlaubt nur DNS (Port 53) und HTTPS (Port 443). Wenn Ihr Agent andere Services erreichen muss (eine Datenbank, eine Message Queue, eine interne API), fügen Sie Egress-Regeln hinzu:

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

Cloud-Provider-Identität

Für AWS IRSA oder GCP Workload Identity annotieren Sie das verwaltete ServiceAccount:

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

Firmeneigene Proxys und private CAs

Wenn Ihr Cluster einen TLS-terminierenden Proxy verwendet, injizieren Sie ein CA-Bundle:

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

Der Operator mountet das CA-Bundle in alle Container und setzt NODE_EXTRA_CA_CERTS automatisch.

GitOps

Das OpenClawInstance CRD ist eine einfache YAML-Datei. Das bedeutet, es passt direkt in einen GitOps-Workflow. Speichern Sie Ihre Agent-Manifeste in einem Git-Repository und lassen Sie ArgoCD oder Flux sie mit Ihrem Cluster synchronisieren.

Eine typische Repo-Struktur:

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

Jede Änderung geht durch einen Pull Request. Ihr Team reviewed den Diff. Merge auf main, und ArgoCD wendet es an. Kein kubectl apply von Laptops, kein Configuration Drift, vollständiges Audit Trail.

Das Config Hashing des Operators macht dies besonders reibungslos. Wenn ArgoCD eine geänderte spec.config.raw synchronisiert, erkennt der Operator die geänderte Content-Hash und löst automatisch ein Rolling Update aus. Dasselbe gilt für Secret-Rotation: Der Operator überwacht referenzierte Secrets und startet Pods bei Änderungen neu.

Backup und Restore

Der Operator unterstützt S3-kompatible Backups. Wenn Sie eine Instanz löschen, erstellt der Operator automatisch ein Backup des Workspace PVC vor dem Teardown.

Um einen Agent aus einem Backup in eine neue Instanz wiederherzustellen:

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

Der Operator lädt den Snapshot herunter, entpackt ihn in das PVC und startet den Agent mit allen vorherigen Workspace-Daten, Skills und dem Konversationsverlauf.

Lokale Inferenz mit Ollama

Wenn Sie möchten, dass Agents lokale Modelle verwenden (für Datenschutz, Latenz oder Kosten), bietet der Operator erstklassigen Ollama-Support. Kein manuelles Sidecar-Setup nötig: spec.ollama übernimmt Container, Model Pre-Pulling, Speicher und GPU-Zuweisung:

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

Bei Aktivierung führt der Operator folgende Schritte aus:

  1. Fügt einen Ollama Sidecar Container zum Pod hinzu
  2. Führt einen Init Container aus, der die aufgelisteten Modelle vor dem Agent-Start herunterlädt
  3. Injiziert OLLAMA_HOST=http://localhost:11434 in den Hauptcontainer
  4. Weist die angeforderte NVIDIA GPU über nvidia.com/gpu Ressourcenlimits zu

Standardmäßig werden Modelle in einem emptyDir-Volume mit konfigurierbarer Größenbegrenzung gespeichert. Für persistenten Modellspeicher über Neustarts hinweg (damit Modelle nicht jedes Mal neu heruntergeladen werden) verwenden Sie ein vorhandenes PVC:

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

Tailscale-Integration

Machen Sie Ihren Agent ohne Ingress, Load Balancer oder öffentliche IPs in Ihrem Tailnet erreichbar. Das spec.tailscale-Feld des Operators übernimmt Auth-Key-Injection, Config-Anreicherung und NetworkPolicy-Regeln:

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

Erstellen Sie das Auth-Key-Secret mit einem ephemeren, wiederverwendbaren Key aus der Tailscale Admin-Konsole:

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

Im serve-Modus (Standard) können nur Mitglieder Ihres Tailnets den Agent erreichen. Im funnel-Modus macht Tailscale ihn mit automatischem HTTPS im öffentlichen Internet erreichbar.

Der Operator führt automatisch folgende Schritte aus:

  • Injiziert die Umgebungsvariablen TS_AUTHKEY und TS_HOSTNAME
  • Fügt gateway.tailscale.mode und gateway.tailscale.resetOnExit in die OpenClaw-Konfiguration ein
  • Fügt STUN- und WireGuard-Egress-Regeln zur NetworkPolicy hinzu

Für passwortloses SSO-Login für Tailnet-Mitglieder aktivieren Sie authSSO:

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

Dies setzt gateway.auth.allowTailscale=true in der OpenClaw-Konfiguration, sodass Tailnet-Mitglieder den Agent ohne separaten Gateway-Token nutzen können.

Benutzerdefinierte Sidecars und Init Container

Für Anwendungsfälle über den eingebauten Ollama- und Tailscale-Support hinaus akzeptiert der Operator beliebige Sidecars und Init Container. Betreiben Sie einen Cloud SQL Proxy für Datenbankzugriff, einen Log Forwarder oder einen beliebigen anderen Helper neben Ihrem 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

Benutzerdefinierte Init Container laufen nach der eigenen Init-Pipeline des Operators (Config Seeding, 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

Config Merge Mode

Standardmäßig überschreibt der Operator die Config-Datei bei jedem Pod-Neustart. Wenn Ihr Agent seine eigene Konfiguration zur Laufzeit modifiziert (durch Skills oder Selbstmodifikation), setzen Sie mergeMode: merge, um die Operator-Konfiguration mit der vorhandenen PVC-Konfiguration tief zu mergen:

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

Im Merge-Modus haben vom Operator angegebene Schlüssel Vorrang, aber vom Agent selbst hinzugefügte Schlüssel überleben Neustarts.

Das vollständige Beispiel

Hier ist ein produktionsreifes Manifest, das alles aus dieser Anleitung kombiniert:

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

Wenden Sie es an, und Sie haben einen gehärteten, automatisch aktualisierenden, browserfähigen AI Agent mit lokaler Inferenz, Tailnet-Zugang, Monitoring, Backup und Netzwerkisolierung. Ein einziges kubectl apply.

Was Sie sofort erhalten

Ohne eine einzige Sicherheitseinstellung anzufassen, wird jeder vom Operator deployte Agent ausgeliefert mit:

  • Nicht-Root-Ausführung (UID 1000)
  • Schreibgeschütztem Root-Dateisystem
  • Allen deaktivierten Linux Capabilities
  • Seccomp RuntimeDefault Profil
  • Default-Deny NetworkPolicy (nur DNS + HTTPS Egress)
  • Eigenem ServiceAccount pro Instanz ohne Token-Auto-Mounting
  • PodDisruptionBudget
  • Liveness, Readiness und Startup Probes
  • Automatisch generiertem Gateway-Authentifizierungstoken
  • 5-Minuten-Drift-Reconciliation

Ein Validating Webhook blockiert Versuche, als Root zu starten, und warnt bei deaktivierten NetworkPolicies, fehlendem TLS auf Ingress und nicht erkannten AI-Provider-Keys.

Nächste Schritte

Wenn Sie auf Probleme stoßen oder Feedback haben, eröffnen Sie ein Issue auf GitHub. PRs sind ebenfalls willkommen.

Wenn Sie Kubernetes nicht selbst betreiben möchten, übernimmt OpenClaw.rocks all das für Sie. Wählen Sie einen Plan, verbinden Sie einen Kanal, und Ihr Agent ist in Sekunden live.