Investigadores de segurança encontraram mais de 135.000 instâncias OpenClaw completamente expostas na Internet. Muitas delas eram vulneráveis a execução remota de código. A crise de segurança do OpenClaw é real: CVEs críticos, skills maliciosos e um problema fundamental na forma como a maioria das implementações lida com a autenticação. Executar o OpenClaw num VPS com docker run é fácil. Executá-lo de forma segura é um problema completamente diferente.

O Kubernetes resolve esse problema. Obtém isolamento de rede, limites de recursos, reinícios automáticos e configurações de segurança que levariam horas a configurar manualmente. E com o Operador Kubernetes do OpenClaw, obtém tudo isto a partir de um único ficheiro YAML.

Este guia leva-o de zero a um agente OpenClaw pronto para produção no Kubernetes. Cada bloco YAML está pronto para copiar e colar.

Porquê um operador

Executar o OpenClaw no Kubernetes é mais do que um Deployment e um Service. Precisa de isolamento de rede, gestão de Secrets, armazenamento persistente, monitorização de saúde, rollouts de configuração e, opcionalmente, automação de browser. Configurar tudo isto corretamente à mão é tedioso e propenso a erros.

Um operador Kubernetes codifica estas preocupações num único Custom Resource. Declara-se o que se pretende, e o operador reconcilia-o continuamente com os objetos Kubernetes corretos. Isto proporciona:

  • Segurança por defeito. Cada agente executa como UID 1000, todas as capabilities Linux removidas, Seccomp ativado, sistema de ficheiros root apenas de leitura e uma NetworkPolicy deny-by-default que apenas permite egress DNS e HTTPS. Sem necessidade de hardening manual.
  • Atualizações automáticas com rollback. O operador consulta o registo OCI para novas versões, faz backup do workspace, implementa a atualização e automaticamente faz rollback se o novo pod falhar os health checks.
  • Rollouts de configuração. Altere o seu spec.config.raw e o operador deteta que o hash do conteúdo mudou, ativando uma atualização progressiva. O mesmo para a rotação de secrets.
  • Backup e restauro. Backup automático do workspace para armazenamento compatível com S3 na eliminação da instância. Restauro para uma nova instância a partir de qualquer snapshot.
  • Autenticação do gateway. Gera automaticamente um token de gateway por instância. Sem emparelhamento manual, sem mDNS (que não funciona no Kubernetes de qualquer forma).
  • Deteção de desvios. A cada 5 minutos, o operador verifica que cada recurso gerido corresponde ao estado desejado. Se alguém editar manualmente uma NetworkPolicy ou eliminar um PDB, é reconciliado de volta.

Pré-requisitos

Necessita de:

  • Um cluster Kubernetes (1.28+). Qualquer distribuição conforme funciona: EKS, GKE, AKS, k3s, ou um cluster Kind local para testes.
  • kubectl configurado para o seu cluster.
  • helm v3 instalado.
  • Uma chave API do seu provider de AI (Anthropic, OpenAI, ou qualquer endpoint compatível com OpenAI).

Passo 1: Instalar o operador

O operador é distribuído como um chart Helm OCI. Um comando instala-o:

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

Verificar que está em execução:

kubectl get pods -n openclaw-operator-system

Deverá ver o pod do operador no estado Running. O operador também instala um webhook de validação que previne configurações inseguras (como executar como root).

Passo 2: Criar o Secret da chave API

Armazene a chave API do seu provider de AI num Secret Kubernetes. O operador irá injetá-la no container do 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 ou outros providers, utilize o nome de variável de ambiente apropriado (OPENAI_API_KEY, OPENROUTER_API_KEY, etc.). Pode incluir múltiplos providers no mesmo Secret.

Dica: Para produção, considere utilizar o External Secrets Operator para sincronizar chaves do AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager ou Azure Key Vault. A documentação do operador tem exemplos detalhados.

Passo 3: Implementar o primeiro agente

Crie um ficheiro chamado 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

Aplique-o:

kubectl apply -f my-agent.yaml

Este único recurso cria um StatefulSet, um Service, um ServiceAccount, um Role, um RoleBinding, uma ConfigMap, um PVC, um PDB, uma NetworkPolicy e um Secret de token de gateway. O operador reconcilia tudo.

Passo 4: Verificar que está em execução

Observe o arranque da instância:

kubectl get openclawinstances -n openclaw -w

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

Quando a fase mostrar Running e Ready for True, o agente está ativo. Verifique os logs:

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

Para interagir com o agente, faça port-forward do gateway:

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

Depois abra http://localhost:18789 no browser.

Passo 5: Conectar um canal

O OpenClaw suporta Telegram, Discord, WhatsApp, Signal e outros canais de mensagens. Cada canal é configurado através de variáveis de ambiente. Adicione o token relevante ao seu Secret:

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

Depois referencie-o na sua instância:

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

O OpenClaw deteta automaticamente o token e ativa o canal. Sem configuração adicional necessária.

Isto cobre os fundamentos. O agente está em execução, protegido e acessível. O resto deste guia cobre funcionalidades opcionais que pode ativar quando estiver pronto.

Automação de browser

O OpenClaw pode navegar na web, tirar screenshots e interagir com páginas. O operador torna isto numa adição de uma única linha. Executa um sidecar Chromium reforçado no mesmo pod, ligado via localhost:

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

O operador injeta automaticamente uma variável de ambiente CHROMIUM_URL no container principal. O sidecar executa como UID 1001 com um sistema de ficheiros root apenas de leitura e o seu próprio security context.

Skills e dependências de runtime

Os skills do OpenClaw do ClawHub podem ser instalados de forma declarativa. O operador executa um init container que obtém cada skill antes do agente arrancar:

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

Se os seus skills ou servidores MCP precisam de pnpm ou Python, ative os init containers integrados para dependências de runtime:

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

Os init containers instalam estas ferramentas no PVC de dados, de modo que persistem entre reinícios sem aumentar a imagem do container.

Atualizações automáticas

O OpenClaw lança novas versões frequentemente. O operador pode rastreá-las automaticamente, fazer backup antes de atualizar e reverter se algo correr mal:

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

Quando uma nova versão aparece no registo, o operador:

  1. Cria um backup do PVC do workspace para armazenamento compatível com S3
  2. Atualiza o tag da imagem no StatefulSet
  3. Espera até healthCheckTimeout que o pod passe as verificações de disponibilidade
  4. Se o pod não ficar ready, restaura o tag da imagem anterior e o backup

Após 3 rollbacks falhados consecutivos, o operador pausa as atualizações automáticas e define uma condição para que possa investigar.

Nota: A atualização automática não tem efeito para imagens fixadas por digest (spec.image.digest). Se fixar por digest, controla as atualizações manualmente.

Reforço para produção

O operador vem seguro por defeito. Aqui estão os controlos adicionais para implementações em produção.

Monitorização com Prometheus

Ative o ServiceMonitor para recolher métricas do operador e das instâncias:

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

O operador expõe openclaw_reconcile_total, openclaw_reconcile_duration_seconds, openclaw_instance_phase e contadores de atualizações automáticas.

Agendar em nós dedicados

Se operar um cluster misto, utilize nodeSelector e tolerations para fixar agentes em nós dedicados:

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

Adicionar regras de egress personalizadas

A NetworkPolicy por defeito apenas permite DNS (porta 53) e HTTPS (porta 443). Se o agente precisar de alcançar outros serviços (uma base de dados, uma fila de mensagens, uma API interna), adicione regras de egress:

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

Identidade do provider cloud

Para AWS IRSA ou GCP Workload Identity, anote o ServiceAccount gerido:

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

Proxies corporativos e CAs privadas

Se o seu cluster utiliza um proxy que interceta TLS, injete um bundle CA:

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

O operador monta o bundle CA em todos os containers e define NODE_EXTRA_CA_CERTS automaticamente.

GitOps

O CRD OpenClawInstance é um ficheiro YAML simples. Isso significa que se integra diretamente num workflow GitOps. Armazene os manifests dos agentes num repositório git e deixe o ArgoCD ou Flux sincronizá-los com o cluster.

Uma estrutura de repositório típica:

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

Cada alteração passa por um pull request. A equipa revê o diff. Merge para main, e o ArgoCD aplica-o. Sem kubectl apply de laptops, sem desvio de configuração, trilha de auditoria completa.

O hashing de configuração do operador torna isto especialmente fluido. Quando o ArgoCD sincroniza uma spec.config.raw alterada, o operador deteta que o hash do conteúdo mudou e ativa automaticamente uma atualização progressiva. O mesmo para a rotação de secrets: o operador monitoriza os Secrets referenciados e reinicia pods quando mudam.

Backup e restauro

O operador suporta backups compatíveis com S3. Quando elimina uma instância, o operador cria automaticamente um backup do PVC do workspace antes da remoção.

Para restaurar um agente a partir de um backup numa nova instância:

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

O operador descarrega o snapshot, descompacta-o no PVC e inicia o agente com todos os dados do workspace anterior, skills e histórico de conversas intactos.

Inferência local com Ollama

Se pretender que os agentes utilizem modelos locais (por privacidade, latência ou custo), o operador tem suporte Ollama de primeira classe. Sem necessidade de configurar um sidecar manualmente: spec.ollama gere o container, o pré-download de modelos, o armazenamento e a alocação 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

Quando ativado, o operador:

  1. Adiciona um container sidecar Ollama ao pod
  2. Executa um init container que pré-descarrega os modelos listados antes do agente arrancar
  3. Injeta OLLAMA_HOST=http://localhost:11434 no container principal
  4. Aloca a GPU NVIDIA solicitada através dos limites de recursos nvidia.com/gpu

Por defeito, os modelos são armazenados num volume emptyDir com um limite de tamanho configurável. Para armazenamento persistente de modelos entre reinícios (para que os modelos não sejam descarregados de novo a cada vez), utilize um PVC existente:

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

Integração Tailscale

Exponha o agente ao seu tailnet sem Ingress, load balancers ou IPs públicos. O campo spec.tailscale do operador gere a injeção da chave de autenticação, o enriquecimento da configuração e as regras de NetworkPolicy:

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

Crie o Secret da chave de autenticação com uma chave efémera e reutilizável da consola de administração Tailscale:

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

No modo serve (predefinido), apenas os membros do seu tailnet podem aceder ao agente. No modo funnel, o Tailscale expõe-no à Internet pública com HTTPS automático.

O operador executa automaticamente as seguintes ações:

  • Injeta as variáveis de ambiente TS_AUTHKEY e TS_HOSTNAME
  • Funde gateway.tailscale.mode e gateway.tailscale.resetOnExit na configuração OpenClaw
  • Adiciona regras de egress STUN e WireGuard à NetworkPolicy

Para login SSO sem password para membros do tailnet, ative authSSO:

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

Isto define gateway.auth.allowTailscale=true na configuração OpenClaw, permitindo que os membros do tailnet acedam ao agente sem um token de gateway separado.

Sidecars e init containers personalizados

Para casos de uso além do suporte integrado de Ollama e Tailscale, o operador aceita sidecars e init containers arbitrários. Execute um Cloud SQL Proxy para acesso à base de dados, um reencaminhador de logs ou qualquer outro auxiliar junto ao 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

Os init containers personalizados executam após o pipeline de inicialização do operador (seeding de configuração, 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 merge de configuração

Por defeito, o operador sobrescreve o ficheiro de configuração a cada reinício de pod. Se o agente modifica a sua própria configuração em runtime (através de skills ou auto-modificação), defina mergeMode: merge para fazer deep-merge da configuração do operador com a configuração PVC existente:

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

No modo merge, as chaves especificadas pelo operador têm prioridade, mas as chaves que o agente adicionou por conta própria sobrevivem aos reinícios.

O exemplo completo

Aqui está um manifest pronto para produção que combina tudo o que foi apresentado neste guia:

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

Aplique-o, e terá um agente AI reforçado, com atualizações automáticas, capacidade de navegação, inferência local, acesso tailnet, monitorização, backup e isolamento de rede. Um único kubectl apply.

O que obtém de imediato

Sem tocar numa única configuração de segurança, cada agente implementado pelo operador vem com:

  • Execução não-root (UID 1000)
  • Sistema de ficheiros root apenas de leitura
  • Todas as capabilities Linux removidas
  • Perfil Seccomp RuntimeDefault
  • NetworkPolicy deny-by-default (apenas egress DNS + HTTPS)
  • ServiceAccount por instância sem montagem automática de token
  • PodDisruptionBudget
  • Probes de liveness, readiness e startup
  • Token de autenticação de gateway gerado automaticamente
  • Reconciliação de desvios a cada 5 minutos

Um webhook de validação bloqueia tentativas de execução como root e avisa sobre NetworkPolicies desativadas, falta de TLS em Ingress e chaves de provider AI não detetadas.

Próximos passos

Se encontrar problemas ou tiver feedback, abra uma issue no GitHub. PRs também são bem-vindos.

Se não pretende operar Kubernetes por conta própria, o OpenClaw.rocks trata de tudo por si. Escolha um plano, ligue um canal, e o seu agente fica ativo em segundos.