Investigadores de seguridad han encontrado más de 135.000 instancias de OpenClaw completamente expuestas en Internet. Muchas de ellas eran vulnerables a ejecución remota de código. La crisis de seguridad de OpenClaw es real: CVE críticos, skills maliciosos y un problema fundamental en la forma en que la mayoría de los despliegues manejan la autenticación. Ejecutar OpenClaw en un VPS con docker run es fácil. Ejecutarlo de forma segura es un problema completamente diferente.

Kubernetes resuelve ese problema. Obtiene aislamiento de red, límites de recursos, reinicios automáticos y configuraciones de seguridad que llevarían horas configurar manualmente. Y con el Operador de Kubernetes de OpenClaw, obtiene todo esto desde un único archivo YAML.

Esta guía le lleva de cero a un agente OpenClaw listo para producción en Kubernetes. Cada bloque YAML está listo para copiar y pegar.

Por qué un operador

Ejecutar OpenClaw en Kubernetes es más que un Deployment y un Service. Necesita aislamiento de red, gestión de Secrets, almacenamiento persistente, monitorización de salud, despliegues de configuración y, opcionalmente, automatización del navegador. Configurar todo esto correctamente a mano es tedioso y propenso a errores.

Un operador de Kubernetes codifica estas necesidades en un único Custom Resource. Usted declara lo que quiere, y el operador lo reconcilia continuamente con los objetos Kubernetes correctos. Eso le proporciona:

  • Seguridad por defecto. Cada agente se ejecuta como UID 1000, todas las capabilities de Linux eliminadas, Seccomp habilitado, sistema de archivos root de solo lectura y una NetworkPolicy deny-by-default que solo permite egress de DNS y HTTPS. Sin necesidad de endurecimiento manual.
  • Actualizaciones automáticas con rollback. El operador consulta el registro OCI en busca de nuevas versiones, respalda el espacio de trabajo, despliega la actualización y realiza automáticamente un rollback si el nuevo pod no pasa los health checks.
  • Despliegues de configuración. Cambie su spec.config.raw y el operador detecta que el hash del contenido cambió, activando una actualización progresiva. Lo mismo para la rotación de secrets.
  • Respaldo y restauración. Respaldo automático del espacio de trabajo a almacenamiento compatible con S3 al eliminar una instancia. Restauración en una nueva instancia desde cualquier snapshot.
  • Autenticación del gateway. Genera automáticamente un token de gateway por instancia. Sin emparejamiento manual, sin mDNS (que de todas formas no funciona en Kubernetes).
  • Detección de deriva. Cada 5 minutos, el operador verifica que cada recurso gestionado coincida con el estado deseado. Si alguien edita manualmente una NetworkPolicy o elimina un PDB, se reconcilia de vuelta.

Prerrequisitos

Necesita:

  • Un clúster de Kubernetes (1.28+). Cualquier distribución conforme funciona: EKS, GKE, AKS, k3s o un clúster Kind local para pruebas.
  • kubectl configurado para su clúster.
  • helm v3 instalado.
  • Una clave API de su proveedor de AI (Anthropic, OpenAI o cualquier endpoint compatible con OpenAI).

Paso 1: Instalar el operador

El operador se distribuye como un chart Helm OCI. Un comando lo instala:

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

Verifique que está en ejecución:

kubectl get pods -n openclaw-operator-system

Debería ver el pod del operador en estado Running. El operador también instala un webhook de validación que previene configuraciones inseguras (como ejecutar como root).

Paso 2: Crear su Secret de clave API

Almacene la clave API de su proveedor de AI en un Secret de Kubernetes. El operador la inyectará en el contenedor del agente:

kubectl create namespace openclaw

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

Para OpenAI u otros proveedores, use el nombre de variable de entorno apropiado (OPENAI_API_KEY, OPENROUTER_API_KEY, etc.). Puede incluir múltiples proveedores en el mismo Secret.

Consejo: Para producción, considere usar el External Secrets Operator para sincronizar claves desde AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager o Azure Key Vault. La documentación del operador tiene ejemplos detallados.

Paso 3: Desplegar su primer agente

Cree un archivo llamado 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

Aplíquelo:

kubectl apply -f my-agent.yaml

Este único recurso crea un StatefulSet, un Service, un ServiceAccount, un Role, un RoleBinding, una ConfigMap, un PVC, un PDB, una NetworkPolicy y un Secret de token de gateway. El operador reconcilia todo.

Paso 4: Verificar que está en ejecución

Observe cómo arranca la instancia:

kubectl get openclawinstances -n openclaw -w

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

Una vez que la fase muestre Running y Ready sea True, su agente está activo. Revise los logs:

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

Para interactuar con su agente, haga port-forward del gateway:

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

Luego abra http://localhost:18789 en su navegador.

Paso 5: Conectar un canal

OpenClaw soporta Telegram, Discord, WhatsApp, Signal y otros canales de mensajería. Cada canal se configura mediante variables de entorno. Agregue el token correspondiente a su Secret:

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

Luego refiéralo en su instancia:

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

OpenClaw detecta automáticamente el token y habilita el canal. No se necesita configuración adicional.

Eso cubre lo básico. Su agente está en ejecución, asegurado y accesible. El resto de esta guía cubre funcionalidades opcionales que puede habilitar cuando esté listo.

Automatización del navegador

OpenClaw puede navegar por la web, tomar capturas de pantalla e interactuar con páginas. El operador lo convierte en una adición de una sola línea. Ejecuta un sidecar Chromium endurecido en el mismo pod, conectado a través de localhost:

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

El operador inyecta automáticamente una variable de entorno CHROMIUM_URL en el contenedor principal. El sidecar se ejecuta como UID 1001 con un sistema de archivos root de solo lectura y su propio contexto de seguridad.

Skills y dependencias de ejecución

Los skills de OpenClaw desde ClawHub se pueden instalar de forma declarativa. El operador ejecuta un contenedor de inicialización que descarga cada skill antes de que el agente arranque:

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

Si sus skills o servidores MCP necesitan pnpm o Python, habilite los contenedores de inicialización integrados para dependencias de ejecución:

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

Los contenedores de inicialización instalan estas herramientas en el PVC de datos, por lo que persisten entre reinicios sin inflar la imagen del contenedor.

Actualizaciones automáticas

OpenClaw publica nuevas versiones con frecuencia. El operador puede rastrearlas automáticamente, respaldar antes de actualizar y revertir si algo sale mal:

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

Cuando aparece una nueva versión en el registro, el operador:

  1. Crea un respaldo del PVC del espacio de trabajo en almacenamiento compatible con S3
  2. Actualiza el tag de la imagen en el StatefulSet
  3. Espera hasta healthCheckTimeout a que el pod pase las verificaciones de disponibilidad
  4. Si el pod no logra estar ready, restaura el tag de imagen anterior y el respaldo

Después de 3 rollbacks fallidos consecutivos, el operador pausa las actualizaciones automáticas y establece una condición para que pueda investigar.

Nota: La actualización automática no tiene efecto para imágenes fijadas por digest (spec.image.digest). Si fija por digest, usted controla las actualizaciones manualmente.

Endurecimiento para producción

El operador viene seguro por defecto. Aquí están los controles adicionales para despliegues en producción.

Monitorización con Prometheus

Habilite el ServiceMonitor para recopilar métricas del operador y las instancias:

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

El operador expone openclaw_reconcile_total, openclaw_reconcile_duration_seconds, openclaw_instance_phase y contadores de actualizaciones automáticas.

Programar en nodos dedicados

Si ejecuta un clúster mixto, use nodeSelector y tolerations para fijar agentes a nodos dedicados:

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

Agregar reglas de egress personalizadas

La NetworkPolicy por defecto solo permite DNS (puerto 53) y HTTPS (puerto 443). Si su agente necesita alcanzar otros servicios (una base de datos, una cola de mensajes, una API interna), agregue reglas de egress:

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

Identidad del proveedor cloud

Para AWS IRSA o GCP Workload Identity, anote el ServiceAccount gestionado:

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

Proxies corporativos y CAs privadas

Si su clúster usa un proxy que intercepta TLS, inyecte un bundle de CA:

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

El operador monta el bundle de CA en todos los contenedores y establece NODE_EXTRA_CA_CERTS automáticamente.

GitOps

El CRD OpenClawInstance es un archivo YAML simple. Eso significa que se integra directamente en un flujo de trabajo GitOps. Almacene sus manifiestos de agentes en un repositorio git y deje que ArgoCD o Flux los sincronicen con su clúster.

Una estructura de repositorio típica:

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

Cada cambio pasa por un pull request. Su equipo revisa el diff. Merge a main, y ArgoCD lo aplica. Sin kubectl apply desde laptops, sin deriva de configuración, registro de auditoría completo.

El hashing de configuración del operador hace que esto sea especialmente fluido. Cuando ArgoCD sincroniza una spec.config.raw modificada, el operador detecta que el hash del contenido cambió y activa automáticamente una actualización progresiva. Lo mismo para la rotación de secrets: el operador vigila los Secrets referenciados y reinicia pods cuando cambian.

Respaldo y restauración

El operador soporta respaldos compatibles con S3. Cuando elimina una instancia, el operador crea automáticamente un respaldo del PVC del espacio de trabajo antes de la eliminación.

Para restaurar un agente desde un respaldo en una nueva instancia:

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

El operador descarga el snapshot, lo descomprime en el PVC e inicia el agente con todos los datos del espacio de trabajo anterior, skills e historial de conversación intactos.

Inferencia local con Ollama

Si desea que los agentes usen modelos locales (por privacidad, latencia o costo), el operador tiene soporte de primera clase para Ollama. No necesita configurar un sidecar manualmente: spec.ollama gestiona el contenedor, la descarga previa de modelos, el almacenamiento y la asignación de 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

Cuando está habilitado, el operador:

  1. Agrega un contenedor sidecar Ollama al pod
  2. Ejecuta un contenedor de inicialización que descarga previamente los modelos listados antes de que el agente arranque
  3. Inyecta OLLAMA_HOST=http://localhost:11434 en el contenedor principal
  4. Asigna la GPU NVIDIA solicitada a través de límites de recursos nvidia.com/gpu

Por defecto, los modelos se almacenan en un volumen emptyDir con un límite de tamaño configurable. Para almacenamiento persistente de modelos entre reinicios (para que los modelos no se vuelvan a descargar cada vez), use un PVC existente:

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

Integración con Tailscale

Exponga su agente a su tailnet sin Ingress, load balancers ni IPs públicas. El campo spec.tailscale del operador gestiona la inyección de la clave de autenticación, el enriquecimiento de la configuración y las reglas de NetworkPolicy:

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

Cree el Secret de clave de autenticación con una clave efímera y reutilizable desde la consola de administración de Tailscale:

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

En modo serve (el predeterminado), solo los miembros de su tailnet pueden acceder al agente. En modo funnel, Tailscale lo expone a Internet público con HTTPS automático.

El operador realiza automáticamente las siguientes acciones:

  • Inyecta las variables de entorno TS_AUTHKEY y TS_HOSTNAME
  • Fusiona gateway.tailscale.mode y gateway.tailscale.resetOnExit en la configuración de OpenClaw
  • Agrega reglas de egress STUN y WireGuard a la NetworkPolicy

Para inicio de sesión SSO sin contraseña para miembros del tailnet, habilite authSSO:

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

Esto establece gateway.auth.allowTailscale=true en la configuración de OpenClaw, permitiendo a los miembros del tailnet acceder al agente sin un token de gateway separado.

Sidecars y contenedores de inicialización personalizados

Para casos de uso más allá del soporte integrado de Ollama y Tailscale, el operador acepta sidecars y contenedores de inicialización arbitrarios. Ejecute un Cloud SQL Proxy para acceso a base de datos, un reenviador de logs o cualquier otro auxiliar junto a su agente:

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

Los contenedores de inicialización personalizados se ejecutan después del pipeline de inicialización del operador (seeding de configuración, 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

Modo de fusión de configuración

Por defecto, el operador sobrescribe el archivo de configuración en cada reinicio de pod. Si su agente modifica su propia configuración en tiempo de ejecución (a través de skills o automodificación), establezca mergeMode: merge para fusionar en profundidad la configuración del operador con la configuración PVC existente:

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

En modo fusión, las claves especificadas por el operador tienen prioridad, pero las claves que el agente agregó por su cuenta sobreviven a los reinicios.

El ejemplo completo

Aquí tiene un manifiesto listo para producción que combina todo lo presentado en esta guía:

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

Aplíquelo, y tendrá un agente AI endurecido, con actualizaciones automáticas, capacidad de navegación, inferencia local, acceso tailnet, monitorización, respaldo y aislamiento de red. Un solo kubectl apply.

Lo que obtiene de serie

Sin tocar una sola configuración de seguridad, cada agente desplegado por el operador incluye:

  • Ejecución no root (UID 1000)
  • Sistema de archivos root de solo lectura
  • Todas las capabilities de Linux eliminadas
  • Perfil Seccomp RuntimeDefault
  • NetworkPolicy deny-by-default (solo egress DNS + HTTPS)
  • ServiceAccount por instancia sin montaje automático de token
  • PodDisruptionBudget
  • Sondas de liveness, readiness y startup
  • Token de autenticación de gateway generado automáticamente
  • Reconciliación de deriva cada 5 minutos

Un webhook de validación bloquea intentos de ejecutar como root y advierte sobre NetworkPolicies deshabilitadas, falta de TLS en Ingress y claves de proveedor AI no detectadas.

Próximos pasos

Si encuentra problemas o tiene comentarios, abra una issue en GitHub. Los PRs también son bienvenidos.

Si no desea operar Kubernetes usted mismo, OpenClaw.rocks se encarga de todo por usted. Elija un plan, conecte un canal, y su agente estará activo en segundos.