OpenClaw z Dockerem: zainstalować i utwardzić bramkę

OpenClaw instaluje się jedną komendą, i to jest dokładnie problem: 11 lutego 2026 SecurityScorecard naliczył ponad czterdzieści tysięcy otwartych bramek w internecie w pierwszych dwudziestu czterech godzinach swojego pomiaru, z czego 35,4% uznano za podatne na zdalne wykonanie kodu. Docker sam z siebie niczego nie rozwiązuje, liczy się to, co udostępnia Twój plik compose, co odbiera kontenerowi, i gdzie żyją sekrety.

Czym jest OpenClaw?

OpenClaw to osobisty asystent open source, na licencji MIT, znany wcześniej pod nazwami Clawdbot, a potem Moltbot. To nie jest agent kodu w sensie Claude Code czy Codex, tylko gateway, proces działający bez przerwy, który udostępnia interfejs webowy (Control UI) i API WebSocket na porcie 18789, podłącza kanały komunikatorów (WhatsApp, Telegram, Discord) i wykonuje „skille” w imieniu swojego właściciela.

Model językowy przychodzi skądinąd: oficjalny obraz zawiera wtyczki dla Anthropic, OpenAI, xAI i Ollama, a Ty dostarczasz klucz albo adres lokalnego serwera. Bramka jest więc maszyną do wykonywania instrukcji, a model tylko jednym z jej dostawców. To właśnie czyni jej ekspozycję sieciową niebezpieczną, o wiele bardziej niż wybrany model.

Dlaczego Docker zamiast lokalnej instalacji?

Dokumentacja mówi, że Docker jest opcjonalny, i ma rację na płaszczyźnie funkcjonalnej. Na płaszczyźnie bezpieczeństwa różnica jest wyraźna. Lokalna instalacja daje bramce Twoje konto użytkownika: Twój folder domowy, Twoje klucze SSH, Twój keychain, Twoje repozytoria. Kontener daje jej użytkownika bez uprawnień, trzy woluminy i nic więcej. To samo rozumowanie co przy agentach kodu, opisane szczegółowo w izolowaniu Claude Code i Codex: jedyną granicą, która trzyma, jest ta egzekwowana przez system operacyjny.

Cena do zapłacenia jest realna. Zależności systemowe, których wymagają niektóre skille (ffmpeg, tmux, przeglądarka), nie są w obrazie, a dokumentacja jest kategoryczna: instalowanie binarek w działającym kontenerze to pułapka, trzeba je wypiec w momencie budowania, przez OPENCLAW_IMAGE_APT_PACKAGES.

Który obraz wybrać?

Dokumentacja Docker OpenClaw wymienia dwa repozytoria. Oficjalny rejestr to ghcr.io/openclaw/openclaw, z lustrem Docker Hub pod openclaw/openclaw. Trzecie, alpine/openclaw, to nieoficjalne lustro, którego dokumentacja wyraźnie każe unikać, bo nie podąża ani za harmonogramem publikacji, ani za polityką retencji projektu.

Pobrałem oba 7 września 2026, żeby zweryfikować różnicę.

docker pull ghcr.io/openclaw/openclaw:latest   # 2 min 30 s
docker pull alpine/openclaw:latest             # 1 min 28 s

docker run --rm ghcr.io/openclaw/openclaw:latest openclaw --version
# OpenClaw 2026.9.2 (3928bad)

docker run --rm alpine/openclaw:latest openclaw --version
# OpenClaw 2026.6.9

docker image inspect ghcr.io/openclaw/openclaw:latest \
  --format '{{index .Config.Labels "org.opencontainers.image.created"}}'
# 2026-09-05T15:21:16.692Z

Lustro alpine/openclaw było zamrożone na wersji 2026.6.9, zbudowanej 21 czerwca 2026: prawie trzy miesiące opóźnienia, poprawki bezpieczeństwa Debiana włącznie. Oficjalny obraz z kolei nosił wersję 2026.9.2, zbudowaną 5 września, dwa dni przed moim testem. Wybór nie jest kwestią gustu.

Przewidź miejsce: docker image inspect zapowiada 1,10 GB treści dla oficjalnego obrazu, ale kolumna DISK USAGE w docker images pod Dockerem 29 naliczała 4,43 GB rzeczywiście zajętych na dysku.

Utwardzony plik compose

Dokumentacja dostarcza kompletny docker-compose.yml, ale zakłada sklonowane repozytorium i skrypt instalacyjny. Oto minimalna wersja, którą napisałem i uruchomiłem, wyłącznie z gotowym obrazem.

name: openclaw-lab

x-openclaw-env: &openclaw-env
  HOME: /home/node
  OPENCLAW_HOME: /home/node
  OPENCLAW_STATE_DIR: /home/node/.openclaw
  OPENCLAW_CONFIG_DIR: /home/node/.openclaw
  OPENCLAW_CONFIG_PATH: /home/node/.openclaw/openclaw.json
  OPENCLAW_WORKSPACE_DIR: /home/node/.openclaw/workspace
  OPENCLAW_GATEWAY_PORT: "18789"
  OPENCLAW_DISABLE_BONJOUR: "1"
  TZ: Europe/Paris

services:
  gateway:
    image: ghcr.io/openclaw/openclaw:2026.9.2
    container_name: openclaw-lab-gateway
    init: true
    restart: unless-stopped
    env_file:
      - path: .env          # token żyje tutaj, nie w compose
        required: true
    environment: *openclaw-env
    command: ["node", "openclaw.mjs", "gateway", "--bind", "lan", "--port", "18789"]
    ports:
      - "127.0.0.1:18789:18789"
    volumes:
      - state:/home/node/.openclaw
      - workspace:/home/node/.openclaw/workspace
      - authsecrets:/home/node/.config/openclaw
    networks: [openclaw]
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "node", "dist/docker-healthcheck.js"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s

  cli:
    image: ghcr.io/openclaw/openclaw:2026.9.2
    profiles: ["cli"]
    network_mode: "service:gateway"
    init: true
    env_file:
      - path: .env
        required: true
    environment: *openclaw-env
    entrypoint: ["node", "openclaw.mjs"]
    volumes:
      - state:/home/node/.openclaw
      - workspace:/home/node/.openclaw/workspace
      - authsecrets:/home/node/.config/openclaw
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    depends_on: [gateway]

networks:
  openclaw:
    name: openclaw-lab

volumes:
  state:
  workspace:
  authsecrets:

Sześć decyzji zasługuje na wyjaśnienie.

• Prefiks 127.0.0.1: w ports: bez niego Docker publikuje na wszystkich interfejsach maszyny, łącznie z tym od sieci lokalnej. To najczęstszy błąd, i wyjaśnia dużą część bramek znalezionych przez skanery.
• --bind lan mimo wszystko: w kontenerze loopback oznaczałoby „nikt nie może mnie dosięgnąć, nawet Docker”. To publikacja portu na 127.0.0.1 hosta wykonuje pracę ograniczenia, nie wewnętrzny tryb wiązania.
• cap_drop: [ALL]: oficjalny compose usuwa tylko NET_RAW i NET_ADMIN. Usunięcie wszystkiego też działa, weryfikacja niżej.
• Usługa cli za profiles: dzieli stos sieciowy bramki (network_mode: "service:gateway"), więc jest wewnątrz granicy zaufania. Profil zapobiega temu, żeby rozproszony docker compose up zostawił ją działającą na stałe.
• Woluminy nazwane, nie bind mounts: dokumentacja nalega na montowanie stanu jako katalogu, nigdy jako pojedynczego pliku, pod groźbą rozjazdu między hostem a kontenerem po zapisie konfiguracji.
• env_file zamiast environment: token nie pojawia się ani w compose, ani w repozytorium Git.

Doprecyzowanie co do portu: 18789 był już zajęty na mojej maszynie przez inną bramkę, więc opublikowałem laboratorium na 127.0.0.1:18889. Wszystkie pomiary, które następują, dotyczą tego portu, zastąp go u siebie przez 18789, także w gateway.controlUi.allowedOrigins.

Plik .env generuje się lokalnie i nigdy nie trafia do commita.

umask 077
printf 'OPENCLAW_GATEWAY_TOKEN=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .env
echo '.env' >> .gitignore

Pierwsze uruchomienie: brakująca konfiguracja

Uruchomienie stosu w tej postaci nie wystarcza. Kontener startuje, zawodzi, restartuje się, i zaczyna od nowa.

docker compose up -d gateway
docker compose logs gateway | tail -3
# [gateway] loading configuration…
# [gateway] resolving authentication…
# Missing config. Run `openclaw setup` or set gateway.mode=local (or pass --allow-unconfigured).

Z restart: unless-stopped, Docker doszedł do jedenastu restartów, zanim spojrzałem na dzienniki, a kontener był oznaczony jako unhealthy. Bramka odmawia obsługi bez jawnej konfiguracji: to dobre domyślne zachowanie, ale trzeba o nim wiedzieć. Poprawka nie wymaga żadnego klucza dostawcy.

docker compose stop gateway

docker compose run --rm -T --no-deps --entrypoint node gateway openclaw.mjs \
  config set --batch-json '[
    {"path":"gateway.mode","value":"local"},
    {"path":"gateway.bind","value":"lan"},
    {"path":"gateway.auth.mode","value":"token"},
    {"path":"gateway.controlUi.allowedOrigins","value":["http://127.0.0.1:18789"]}
  ]'
# Updated 4 config paths. Restart the gateway to apply.

docker compose up -d --force-recreate gateway

--no-deps --entrypoint node nie jest dekoracyjne: usługa cli dzieli stos sieciowy bramki, więc działa dopiero po utworzeniu kontenera gateway. Żeby zapisać konfigurację przed pierwszym uruchomieniem, trzeba przejść przez sam obraz bramki.

Wynik, zmierzony w czasie: /healthz odpowiedział 200 w 7,6 sekundy, a Docker oznaczył kontener jako healthy po 11,9 sekundy. Restart na gorąco, ze stanem już zainicjowanym, spada do 5,0 sekundy.

curl -s http://127.0.0.1:18789/healthz   # {"ok":true,"status":"live"}
curl -s http://127.0.0.1:18789/startupz  # {"ok":true,"status":"started"}
curl -s http://127.0.0.1:18789/readyz    # {"ready":true}

Dzienniki uruchamiania są gadatliwe, i pouczające.

[gateway] ⚠️  Gateway is binding to a non-loopback address. Ensure authentication
          is configured before exposing to public networks.
[gateway] agent model: openai/gpt-5.6-sol (thinking=medium, fast=off)
[gateway] http server listening (13 plugins: anthropic, browser, canvas,
          cua-computer, device-pair, file-transfer, geolocation, linux-node,
          memory-core, ollama, openai, talk-voice, xai; 2.7s)
[gateway] log file: /tmp/openclaw/openclaw-2026-09-07.log
[gateway] remote model catalog updated; restart the Gateway to apply it

Zwróć uwagę na ostatnią linię: bez żadnego skonfigurowanego klucza bramka poszła szukać katalogu modeli w internecie. Bramka „w spoczynku” i tak wychodzi do sieci.

Zapisany plik konfiguracyjny ma 348 bajtów i nie zawiera żadnego sekretu: token zostaje w zmiennej środowiskowej.

{
  "gateway": {
    "mode": "local",
    "bind": "lan",
    "auth": { "mode": "token" },
    "controlUi": { "allowedOrigins": ["http://127.0.0.1:18789"] }
  },
  "meta": { "lastTouchedVersion": "2026.9.2" }
}

Obok, state/openclaw.sqlite ważył już 1,5 MB. To tam kończą tokeny OAuth, jawnym tekstem: dokumentacja każe traktować ten katalog i jego kopie zapasowe jak dane uwierzytelniające.

Co utwardzenie naprawdę blokuje

Trzy weryfikacje są warte więcej niż deklaracja intencji.

Możliwości i użytkownik

docker compose exec -T gateway sh -lc \
  'grep -E "^Cap(Prm|Eff|Bnd)" /proc/1/status; id; grep NoNewPrivs /proc/self/status'
# CapPrm: 0000000000000000
# CapEff: 0000000000000000
# CapBnd: 0000000000000000
# uid=1000(node) gid=1000(node) groups=1000(node)
# NoNewPrivs: 1

Żadnej możliwości, użytkownik bez uprawnień, eskalacja niemożliwa. Oficjalny obraz wykonuje już połowę pracy: działa jako node (uid 1000) i uruchamia tini jako proces 1.

Port opublikowany na pętli lokalnej nie chroni przed Dockerem

To wynik, który zaskoczył mnie najbardziej. Port jest opublikowany tylko na 127.0.0.1, a mimo to dowolny kontener, nawet z innej sieci Docker, dosięga bramki przez jej adres bridge.

GWIP=$(docker inspect -f \
  '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' openclaw-lab-gateway)
echo "$GWIP"   # 172.29.0.2

# z sieci domyślnej, nie tej z laboratorium
docker run --rm alpine:3.22 sh -lc \
  "apk add --no-cache curl >/dev/null; \
   curl -s -o /dev/null -w '%{http_code}\n' http://$GWIP:18789/healthz"
# 200

Prefiks 127.0.0.1: zamyka interfejsy maszyny, nie sieć demona Dockera. Jeśli hostujesz inne kontenery na tej samej maszynie, wystarczy, że jeden z nich zostanie skompromitowany, żeby rozmawiać z bramką. Zabezpieczeniem jest uwierzytelnianie gateway i, na serwerze Linux, reguły w łańcuchu DOCKER-USER: dokumentacja utwardzania OpenClaw podaje ich komplet dla UFW, ponieważ zwykłe reguły INPUT nigdy nie widzą ruchu publikowanego przez Docker.

Sieć wewnętrzna kosztuje więcej, niż się wydaje

Kolejnym odruchem jest przełączenie sieci na internal: true. Zmierzyłem, co to zabiera.

# docker-compose.internal.yml
networks:
  openclaw:
    internal: true

Dwie konsekwencje są sprzeczne z intuicją. Po pierwsze, Docker Compose po cichu ignoruje sekcję ports na sieci wewnętrznej: docker compose ps pokazuje 18789/tcp zamiast 127.0.0.1:18789->18789/tcp, bez najmniejszego ostrzeżenia, a Control UI staje się nieosiągalny. Po drugie, host.docker.internal wciąż się rozwiązuje, ale już nie routuje: Ollama działająca na maszynie hosta też nie jest osiągalna.

Sieć wewnętrzna nadaje się więc do użycia tylko dla bramki sterowanej całkowicie przez docker compose exec, z modelem serwowanym przez inny kontener tej samej sieci. Dla całej reszty właściwą odpowiedzią jest dedykowany bridge plus tunel SSH: dokumentacja OpenClaw zresztą zaleca Tailscale Serve zamiast łącza LAN.

Podłączyć model, nie wpisując klucza w compose

Istnieją trzy drogi, i żadna nie wymaga wklejania klucza do wersjonowanego pliku.

1. Zdalny dostawca: klucz trafia do .env (ANTHROPIC_API_KEY, OPENAI_API_KEY), czytany przez env_file. Nigdy nie trafia do openclaw.json.
2. Lokalny model na maszynie hosta: w kontenerze 127.0.0.1 oznacza kontener. Dokumentacja narzuca http://host.docker.internal:11434 dla Ollama, a host musi nasłuchiwać poza swoją pętlą lokalną (OLLAMA_HOST=0.0.0.0:11434 ollama serve).
3. Binarny plik Claude Code w kontenerze: możliwe, ale trzeba utrwalić /home/node w nazwanym woluminie, inaczej kolejna aktualizacja obrazu wymaże instalację i uwierzytelnianie.

Podczas tego testu nie wpisano żadnego klucza, a wtyczka ollama jest rzeczywiście ładowana przez bramkę. Ścieżkę modelu lokalnego da się sprawdzić bez klucza: przy Ollamie opublikowanej na porcie 11434 hosta http://host.docker.internal:11434/v1 odpowiada 200 i w formacie OpenAI z kontenera sieci bridge. To dokładnie ten adres, którego wymaga dokumentacja, i powód, dla którego 127.0.0.1 by nie zadziałał: w kontenerze oznacza kontener.

Zaktualizować obraz, nie psując stanu

Ruchome etykiety (latest, main, extended-stable) są przebudowywane co tydzień z tego samego źródła, żeby odzyskać poprawki bezpieczeństwa systemu bazowego między dwiema wersjami OpenClaw. Każda przebudowa publikuje też niezmienną etykietę z datą, typu 2026.8.1-r20260820: to ją trzeba przypiąć, gdy nie chcesz, żeby wdrożenie podążało za ruchomą etykietą.

Przy zmianie obrazu bramka stosuje swoje migracje przy starcie. Jeśli jej się nie uda, kończy się błędem, zamiast ogłosić się zdrową, a z polityką restartu zobaczysz pętlę. Udokumentowanym lekarstwem jest uruchomienie tego samego obrazu raz z openclaw doctor --fix na tych samych woluminach, a potem normalny restart.

docker compose pull
docker run --rm -v openclaw-lab_state:/home/node/.openclaw \
  ghcr.io/openclaw/openclaw:2026.9.2 openclaw doctor --fix
docker compose up -d gateway

Wybrać swoje skille na ClawHub

Obraz dostarcza 53 gotowe do użycia skille: 51 w podstawowym pakiecie, 2 dodatkowe. To już dużo, i wystarcza do większości zastosowań. Reszta pochodzi z ClawHub, publicznego rejestru, i to tam zaczynają się kłopoty. Format to ten sam SKILL.md, co opisany w przewodniku Agent Skills: frontmatter YAML, treść Markdown, pliki dodatkowe.

Dokumentacja skilli nie owija w bawełnę: każe traktować każdy zewnętrzny skill jak niezaufany kod i przeczytać go przed aktywacją. Liczby przyznają jej rację. Zestawienie opublikowane 1 marca 2026 przypisuje Antiy CERT 1 184 potwierdzone złośliwe skille na ClawHub, czyli mniej więcej jeden pakiet na pięć w szczycie kampanii.

skills verify odpytuje rejestr, nie instalując niczego, i to się ceni. Jego ogólny werdykt natomiast zasługuje na otwarcie. Oto, co zwraca dla popularnego skilla Docker, w dniu testu.

docker compose run --rm -T cli skills verify @ivangdavila/docker

# decision            : pass
# security.status     : clean
# security.verdict    : benign      (confidence: high)
# signature.status    : unsigned
# provenance.source   : unavailable
# signals.staticScan  : suspicious  -> suspicious.exposed_secret_literal
# signals.skillSpector: suspicious
# signals.virusTotal  : clean
# artifact.files      : 16 plików, w tym SKILL.md (24 283 bajty)

Dwa z trzech sygnałów mówią „podejrzany”, pakiet nie jest podpisany, jego pochodzenie z GitHuba nie jest zarejestrowane, a zagregowany werdykt zostaje „łagodny, wysoka pewność”. Czytelne podsumowanie mówi o lokalnym asystencie bez wykrytej eksfiltracji, i to nie ten konkretny skill jest tu problemem. Zapamiętaj rozbieżność między sygnałami a wnioskiem: zielony wynik to nie to samo co przeczytanie.

Zasada, którą zapamiętuję, mieści się w trzech punktach: przeczytać SKILL.md przed instalacją (skills info podaje dokładną ścieżkę pliku), odrzucać każdy skill, który wychodzi do sieci, choć jego funkcja tego nie wymaga, i preferować 53 skille dostarczone z obrazem, dopóki wystarczają. Pole security.installPolicy konfiguracji pozwala narzucić tę barierę, zamiast liczyć na dyscyplinę.

Dodać serwery MCP

Bramka zarządza swoimi serwerami MCP w mcp.servers, z kompletną powierzchnią komend: add (który sonduje serwer przed zarejestrowaniem), probe, doctor, status, tools do filtrowania udostępnianych narzędzi, i login / logout dla serwerów OAuth.

docker compose run --rm -T cli mcp doctor     # statyczne wady konfiguracji
docker compose run --rm -T cli mcp status     # transporty, bez łączenia się
docker compose run --rm -T cli mcp probe      # prawdziwe połączenie, wylicza możliwości
docker compose run --rm -T cli mcp tools      # filtry include/exclude na serwer

Warto zachować dwa odruchy. mcp tools istnieje, korzystaj z niego. Serwer MCP często udostępnia trzydzieści narzędzi, gdy chcesz tylko trzech, a każde dodatkowe narzędzie to opis, który model czyta jak polecenie. A serwer MCP w STDIO działa wewnątrz kontenera bramki, więc z jej woluminami i zmiennymi środowiskowymi. Notatka badawcza Cloud Security Alliance z 4 maja 2026 zaleca dokładnie odwrotnie: dedykowany kontener na serwer, bez dostępu do danych uwierzytelniających hosta. Temat jest omówiony szczegółowo w tworzeniu serwera MCP w PHP.

OpenClaw, Claude Code czy Hermes Agent?

Cała trójka nie gra w tym samym miejscu, a pomylenie ich prowadzi do złych wyborów.

Claude Code niczego nie nasłuchuje: zamknij terminal, powierzchnia ataku znika. OpenClaw nasłuchuje bez przerwy, z założenia, bo tego się od niego wymaga: odpowiedzieć na wiadomość Telegram o trzeciej nad ranem. Hermes Agent, instalowany w ten sam sposób w osobnym artykule, zajmuje trzecią pozycję: agent pomyślany od początku do działania w kontenerze. Przegląd agentów w linii poleceń sytuuje pozostałych, a OpenCode obejmuje przypadek agenta kodu open source.

Usunąć wszystko

Laboratorium się demontuje. Samo docker compose down zostawia za sobą woluminy, z bazą SQLite i jej tokenami.

docker compose down --volumes --remove-orphans
docker rmi ghcr.io/openclaw/openclaw:2026.9.2 alpine/openclaw:latest
rm -f .env

# weryfikacja: nic nie powinno wyjść
docker ps -a --format '{{.Names}}' | grep -i claw
docker volume ls --format '{{.Name}}' | grep -i claw
docker images --format '{{.Repository}}' | grep -i claw
docker network ls --format '{{.Name}}' | grep -i claw

Co warto zapamiętać

• Weź ghcr.io/openclaw/openclaw: lustro alpine/openclaw miało trzy miesiące opóźnienia w dniu testu (2026.6.9 wobec 2026.9.2).
• Bramka odmawia startu bez konfiguracji i wpada w pętlę restartów: zapisz gateway.mode=local przed pierwszym up.
• Publikacja na 127.0.0.1 zamyka interfejsy maszyny, nie sieć Docker: sąsiedni kontener dosięgał bramki z HTTP 200.
• internal: true po cichu usuwa opublikowany port i dostęp do host.docker.internal: do zarezerwowania dla bramek sterowanych przez exec.
• Token żyje w .env, nigdy w compose. state/openclaw.sqlite zawiera tokeny OAuth jawnym tekstem i traktuje się go jak sekret.
• Na ClawHub werdykt „clean” może kryć dwa sygnały „podejrzany”, niepodpisany pakiet i nieznane pochodzenie. Czytaj SKILL.md.