Изследователи по сигурността откриха над 135 000 инстанции на OpenClaw, напълно изложени в интернет. Много от тях бяха уязвими към отдалечено изпълнение на код. Кризата със сигурността на OpenClaw е реална: критични CVE, зловредни skills и фундаментален проблем с начина, по който повечето разгръщания обработват удостоверяването. Стартирането на OpenClaw на VPS с docker run е лесно. Сигурното му изпълнение е съвсем друг проблем.

Kubernetes решава този проблем. Получавате мрежова изолация, лимити на ресурсите, автоматични рестартирания и настройки за сигурност, чието ръчно конфигуриране би отнело часове. А с оператора на OpenClaw за Kubernetes получавате всичко това от един единствен YAML файл.

Това ръководство Ви води от нулата до готов за продукция агент на OpenClaw върху Kubernetes. Всеки YAML блок е готов за копиране и поставяне.

Защо оператор

Изпълнението на OpenClaw върху Kubernetes е повече от Deployment и Service. Нуждаете се от мрежова изолация, управление на Secret обекти, постоянно съхранение, мониторинг на здравето, разгръщане на конфигурации и по избор автоматизация на браузъра. Правилното свързване на всичко това ръчно е досадно и податливо на грешки.

Операторът за Kubernetes кодира тези изисквания в един единствен Custom Resource. Декларирате какво искате и операторът непрекъснато го съгласува с правилните Kubernetes обекти. Това Ви дава:

  • Сигурност по подразбиране. Всеки агент работи като UID 1000, всички Linux capabilities премахнати, Seccomp активиран, файлова система root само за четене и NetworkPolicy по подразбиране deny, която разрешава само DNS и HTTPS изходящ трафик. Без ръчно укрепване.
  • Автоматични актуализации с откат. Операторът проверява OCI регистъра за нови версии, прави резервно копие на работното пространство, разгръща актуализацията и автоматично прави откат, ако новият pod не премине проверките за здраве.
  • Разгръщане на конфигурации. Промяната на spec.config.raw кара оператора да открие промяна в хеша на съдържанието, задействайки постепенна актуализация. Същото важи за ротацията на secrets.
  • Резервно копиране и възстановяване. Автоматично резервно копие на работното пространство в S3-съвместимо хранилище при изтриване на инстанция. Възстановяване в нова инстанция от произволен snapshot.
  • Удостоверяване на gateway. Автоматично генерира token за gateway за всяка инстанция. Без ръчно сдвояване, без mDNS (който в Kubernetes така или иначе не работи).
  • Засичане на отклонение. На всеки 5 минути операторът проверява дали всеки управляван ресурс съответства на желаното състояние. Ако някой ръчно редактира NetworkPolicy или изтрие PDB, то се възстановява.

Предварителни изисквания

Нуждаете се от:

  • Kubernetes клъстер (1.28+). Всяка съвместима дистрибуция работи: EKS, GKE, AKS, k3s или локален Kind клъстер за тестване.
  • kubectl, конфигуриран за Вашия клъстер.
  • Инсталиран helm v3.
  • API ключ от Вашия AI доставчик (Anthropic, OpenAI или произволен OpenAI-съвместим endpoint).

Стъпка 1: Инсталиране на оператора

Операторът се доставя като OCI Helm chart. Една команда го инсталира:

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

Проверете дали работи:

kubectl get pods -n openclaw-operator-system

Трябва да видите pod на оператора в състояние Running. Операторът също инсталира валидиращ webhook, който предотвратява несигурни конфигурации (като изпълнение като root).

Стъпка 2: Създаване на Secret с API ключ

Съхранете API ключа на Вашия AI доставчик в Kubernetes Secret. Операторът ще го инжектира в контейнера на агента:

kubectl create namespace openclaw

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

За OpenAI или други доставчици използвайте съответното име на променлива на средата (OPENAI_API_KEY, OPENROUTER_API_KEY и т.н.). Можете да включите множество доставчици в един и същ Secret.

Съвет: За продукция обмислете използването на External Secrets Operator за синхронизиране на ключове от AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager или Azure Key Vault. Документацията на оператора съдържа подробни примери.

Стъпка 3: Разгръщане на първия агент

Създайте файл с име 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

Приложете го:

kubectl apply -f my-agent.yaml

Този единствен ресурс създава StatefulSet, Service, ServiceAccount, Role, RoleBinding, ConfigMap, PVC, PDB, NetworkPolicy и Secret за token на gateway. Операторът съгласува всичко.

Стъпка 4: Проверка на работата

Наблюдавайте стартирането на инстанцията:

kubectl get openclawinstances -n openclaw -w

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

Когато фазата покаже Running и Ready е True, Вашият агент е активен. Проверете логовете:

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

За да взаимодействате с агента, направете port-forward на gateway:

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

След това отворете http://localhost:18789 в браузъра си.

Стъпка 5: Свързване на канал

OpenClaw поддържа Telegram, Discord, WhatsApp, Signal и други канали за съобщения. Всеки канал се конфигурира чрез променливи на средата. Добавете съответния token към Вашия Secret:

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

След това го посочете в инстанцията:

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

OpenClaw автоматично открива token и активира канала. Не е необходима допълнителна конфигурация.

Това покрива основите. Вашият агент работи, защитен е и достъпен. Останалата част от това ръководство обхваща допълнителни функции, които можете да активирате, когато сте готови.

Автоматизация на браузъра

OpenClaw може да сърфира в уеб, да прави екранни снимки и да взаимодейства със страници. Операторът превръща това в едноредово допълнение. Изпълнява укрепен Chromium sidecar в същия pod, свързан чрез localhost:

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

Операторът автоматично инжектира променлива на средата CHROMIUM_URL в основния контейнер. Sidecar контейнерът работи като UID 1001 с файлова система root само за четене и собствен контекст за сигурност.

Skills и зависимости за изпълнение

Skills на OpenClaw от ClawHub могат да бъдат инсталирани декларативно. Операторът изпълнява init контейнер, който изтегля всеки skill преди стартирането на агента:

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

Ако Вашите skills или MCP сървъри изискват pnpm или Python, активирайте вградените init контейнери за зависимости за изпълнение:

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

Init контейнерите инсталират тези инструменти на PVC за данни, така че те се запазват между рестартиранията, без да раздуват образа на контейнера.

Автоматични актуализации

OpenClaw редовно издава нови версии. Операторът може автоматично да ги проследява, да прави резервно копие преди актуализация и да се връща назад, ако нещо се обърка:

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

Когато нова версия се появи в регистъра, операторът:

  1. Създава резервно копие на PVC на работното пространство в S3-съвместимо хранилище
  2. Актуализира image tag на StatefulSet
  3. Изчаква до healthCheckTimeout pod да премине проверките за наличност
  4. Ако pod не стане ready, възстановява предишния image tag и резервното копие

След 3 последователни неуспешни отката операторът поставя на пауза автоматичните актуализации и задава условие за разследване.

Забележка: Автоматичната актуализация няма ефект за образи, фиксирани по digest (spec.image.digest). Ако фиксирате по digest, контролирате актуализациите ръчно.

Укрепване за продукция

Операторът е сигурен по подразбиране. Ето допълнителните настройки за продукционни разгръщания.

Мониторинг с Prometheus

Активирайте ServiceMonitor за събиране на метрики от оператора и инстанциите:

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

Операторът предоставя openclaw_reconcile_total, openclaw_reconcile_duration_seconds, openclaw_instance_phase и броячи за автоматични актуализации.

Планиране на специализирани възли

Ако работите със смесен клъстер, използвайте nodeSelector и tolerations, за да закрепите агентите към специализирани възли:

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

Добавяне на персонализирани правила за изходящ трафик

NetworkPolicy по подразбиране разрешава само DNS (порт 53) и HTTPS (порт 443). Ако Вашият агент трябва да достига други услуги (база данни, опашка за съобщения, вътрешен API), добавете правила за изходящ трафик:

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

Идентичност на облачния доставчик

За AWS IRSA или GCP Workload Identity анотирайте управлявания ServiceAccount:

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

Корпоративни проксита и частни CA

Ако Вашият клъстер използва TLS-прихващащ прокси, инжектирайте CA пакет:

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

Операторът монтира CA пакета във всички контейнери и автоматично задава NODE_EXTRA_CA_CERTS.

GitOps

CRD OpenClawInstance е обикновен YAML файл. Това означава, че се вписва директно в GitOps работен процес. Съхранявайте манифестите на агентите в git хранилище и оставете ArgoCD или Flux да ги синхронизира с клъстера.

Типична структура на хранилище:

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

Всяка промяна минава през pull request. Вашият екип преглежда diff. Merge в main и ArgoCD го прилага. Без kubectl apply от лаптопи, без отклонение на конфигурацията, пълна одитна следа.

Хеширането на конфигурацията от оператора прави това особено гладко. Когато ArgoCD синхронизира променена spec.config.raw, операторът открива промяната в хеша на съдържанието и автоматично задейства постепенна актуализация. Същото важи за ротацията на secrets: операторът наблюдава реферираните Secrets и рестартира podове, когато се променят.

Резервно копиране и възстановяване

Операторът поддържа S3-съвместими резервни копия. Когато изтриете инстанция, операторът автоматично създава резервно копие на PVC на работното пространство преди изтриването.

За възстановяване на агент от резервно копие в нова инстанция:

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

Операторът изтегля snapshot, разархивира го в PVC и стартира агента с всички предишни данни от работното пространство, skills и история на разговорите.

Локално извеждане с Ollama

Ако искате агентите да използват локални модели (за поверителност, латентност или цена), операторът предлага първокласна поддръжка на Ollama. Не е необходимо ръчно да конфигурирате sidecar: spec.ollama управлява контейнера, предварителното изтегляне на модели, съхранението и разпределението на 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

При активиране операторът:

  1. Добавя Ollama sidecar контейнер към pod
  2. Изпълнява init контейнер, който предварително изтегля изброените модели преди стартирането на агента
  3. Инжектира OLLAMA_HOST=http://localhost:11434 в основния контейнер
  4. Разпределя заявения NVIDIA GPU чрез ресурсни лимити nvidia.com/gpu

По подразбиране моделите се съхраняват в emptyDir том с конфигурируем лимит за размер. За постоянно съхранение на модели между рестартирания (за да не се изтеглят отново всеки път) използвайте съществуващ PVC:

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

Интеграция с Tailscale

Направете Вашия агент достъпен в tailnet мрежата без Ingress, load balancer или публични IP адреси. Полето spec.tailscale на оператора управлява инжектирането на ключа за удостоверяване, обогатяването на конфигурацията и правилата на NetworkPolicy:

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

Създайте Secret с ключ за удостоверяване с ефимерен, многократен ключ от административната конзола на Tailscale:

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

В режим serve (по подразбиране) само членовете на Вашата tailnet мрежа могат да достигнат агента. В режим funnel Tailscale го излага на публичния интернет с автоматичен HTTPS.

Операторът автоматично:

  • Инжектира променливите на средата TS_AUTHKEY и TS_HOSTNAME
  • Слива gateway.tailscale.mode и gateway.tailscale.resetOnExit в конфигурацията на OpenClaw
  • Добавя STUN и WireGuard правила за изходящ трафик в NetworkPolicy

За вход със SSO без парола за членове на tailnet мрежата активирайте authSSO:

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

Това задава gateway.auth.allowTailscale=true в конфигурацията на OpenClaw, позволявайки на членовете на tailnet мрежата да достъпят агента без отделен token за gateway.

Персонализирани sidecar и init контейнери

За случаи на употреба извън вградената поддръжка на Ollama и Tailscale, операторът приема произволни sidecar и init контейнери. Изпълнявайте Cloud SQL Proxy за достъп до база данни, препращач на логове или друг помощник до Вашия агент:

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

Персонализираните init контейнери се изпълняват след собствения init pipeline на оператора (зареждане на конфигурация, 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

Режим на сливане на конфигурация

По подразбиране операторът презаписва конфигурационния файл при всяко рестартиране на pod. Ако Вашият агент модифицира собствената си конфигурация по време на изпълнение (чрез skills или самомодификация), задайте mergeMode: merge за дълбоко сливане на конфигурацията на оператора с наличната PVC конфигурация:

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

В режим на сливане ключовете, определени от оператора, имат приоритет, но ключовете, добавени от самия агент, се запазват при рестартирания.

Пълният пример

Ето манифест, готов за продукция, който комбинира всичко от това ръководство:

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

Приложете го и имате укрепен, автоматично актуализиращ се AI агент с браузър, локално извеждане, достъп до tailnet, мониторинг, резервно копиране и мрежова изолация. Един kubectl apply.

Какво получавате веднага

Без да докоснете нито една настройка за сигурност, всеки агент, разгърнат от оператора, е снабден с:

  • Изпълнение без root (UID 1000)
  • Файлова система root само за четене
  • Всички Linux capabilities премахнати
  • Seccomp RuntimeDefault профил
  • NetworkPolicy по подразбиране deny (само DNS + HTTPS изходящ трафик)
  • ServiceAccount за инстанция без автоматично монтиране на token
  • PodDisruptionBudget
  • Проби за liveness, readiness и startup
  • Автоматично генериран token за удостоверяване на gateway
  • 5-минутно съгласуване на отклоненията

Валидиращ webhook блокира опитите за изпълнение като root и предупреждава за деактивирани NetworkPolicy, липсващ TLS на Ingress и неоткрити ключове на AI доставчик.

Следващи стъпки

Ако срещнете проблеми или имате обратна връзка, отворете issue в GitHub. PR също са добре дошли.

Ако не искате да управлявате Kubernetes сами, OpenClaw.rocks се грижи за всичко вместо Вас. Изберете план, свържете канал и Вашият агент е активен за секунди.