OpenClaw 安全加固实战：Docker、Gateway 与最小权限清单

TL;DR 文章速览

OpenClaw quickstart 跑通，只能说明它“能启动”，不等于“安全可用”。把它当成一个能读文件、跑命令、连接外部账号的助手来部署：优先放进 Docker 或虚拟机；只挂载专门的 workspace（工作目录）；Gateway（控制台入口）只绑定 loopback（本机地址）；工具权限从最小开始；凭据不要明文写进配置；聊天渠道必须做白名单或配对；装完立刻跑 openclaw security audit --deep。这篇按部署顺序讲：每一步做什么、为什么做、做完怎么看。

前言

上一篇把 OpenClaw 的风险拆到了攻击链级别：9 个 CVE、供应链投毒、社会工程、AI 自己失手。看完之后，最实际的问题是：到底该怎么安全地装？

官方 quickstart 三行命令跑完，页面打开，AI 能说话，很多人到这里就停了。

但 OpenClaw 不是一个普通聊天工具。它可能读文件、跑命令、连接外部账号。官方文档里那句“一个 Gateway 对应一个可信操作者边界”，换句话说：谁能碰到 Gateway，谁就有机会调动它背后的工具、文件和账号。

所以这篇不讲大而全的安全理论，只按新手真的会遇到的顺序来：先决定放在哪跑，再管入口，再调工具权限，然后处理凭据、聊天渠道和审计。配置片段怎么放、命令在哪敲、哪些开关不要碰，我会尽量讲清楚。

先说前提：尽量别在主力机上裸跑

如果只记住一句话，我希望是：先隔离，再授权。

OpenClaw 这类 AI Agent，它一旦拿到工具权限，你让它看整个用户目录，它就可能看到 SSH 密钥、下载目录、工作文档、旧 .env；你让它能跑命令，它就会真的跑。

所以第一步是选好运行环境。我推荐按这个顺序选：

Docker 容器：优先。只挂载一个专门的 workspace，别挂整个用户目录。
虚拟机：适合你想完整隔离网络、文件和系统快照。
单独的低权限系统用户：如果暂时不用 Docker / VM，至少别用日常管理员账号跑。
主力机、主账号、全权限直接跑：不建议。能避开就避开。

隔离不是万能的。Docker 参数写错、卷乱挂载，一样会出事。但它至少能把事故限制在一个更小的范围里：就算 Agent 误删、误读、误执行，影响也主要落在你给它的环境里。

后面的命令该在哪敲？

文章里的 bash 命令，默认是在终端里执行。

macOS：打开“终端”或 iTerm。
Linux：打开 Terminal。
Windows：建议用 WSL、Docker Desktop 里的 Linux 终端，或者 SSH 到 Linux 服务器。不要把 chmod 这类命令硬贴进 PowerShell，它们不是一套权限模型。

如果 OpenClaw 跑在 Docker 里，先分清命令是在宿主机还是容器里执行：

docker run ... 在宿主机终端执行。
修改容器内文件、查看容器内目录，才需要进容器。
不确定时，先跑 openclaw doctor 看它打印的配置路径和运行状态。

下面的 JSON 都是配置片段，不是让你新建一个随便命名的文件，更不是让你覆盖整份配置。它们要合并进 OpenClaw 实际读取的配置里。不同版本路径可能不一样，常见位置在 ~/.openclaw/ 或 ~/.config/openclaw/。找不到就先跑：

bash

openclaw doctor

看输出里有没有 config、data dir、profile 之类的路径。确认清楚再动手。

五件装完就要做的事

接下来这五件事，建议按顺序做。

1. Gateway：先把入口收住

Gateway 可以理解成 OpenClaw 的控制台入口。入口一旦暴露，后面工具权限、文件权限、账号权限都会跟着变危险，所以它要第一个处理。

bind 保持 loopback。 bind 指的是服务监听在哪个地址上。默认值通常是 loopback，也就是 127.0.0.1:18789。它的意思是只允许本机访问：你在同一台机器上打开浏览器能进，外面的机器不能直接访问。

不要为了省事把它改成 0.0.0.0。这不是“无地址”，而是监听所有网卡。家里局域网、公司内网，甚至公网服务器，都可能因此暴露入口。上一篇里那些公网暴露实例，很多就是从这一步开始的。

认证必须开。 最低要求是强 token。这里的 token 可以先简单理解成“给 Gateway 用的长密码”。可以在终端里生成一个随机 token：

bash

openssl rand -hex 32

这条命令会吐出一串 64 位十六进制字符。把它放进密码管理器，不要截图、发群、贴聊天记录，也不要提交到 Git。

启动 Gateway 时类似这样：

bash

openclaw gateway --bind loopback \
  --auth token \
  --token "你的随机 token"

如果用配置文件，方向也一样：

json

{
  "gateway": {
    "bind": "loopback",
    "auth": "token",
    "dangerouslyDisableDeviceAuth": false
  }
}

这里有两个坑。

第一个是 bind: "0.0.0.0"。上一篇里 ClawJacked（CVE-2026-25253）已经说明，哪怕 Gateway 只绑在 loopback，浏览器里的恶意页面也可能折腾 token。再把 Gateway 放到公网，只会把入口暴露给更多人。

第二个是 dangerouslyDisableDeviceAuth: true。名字里已经写了 dangerous。Control UI 的设备认证是最后一道闸，不要关。

需要远程访问怎么办？ 能不远程访问控制台，就别远程访问。如果必须远程访问，正路是反向代理 + HTTPS + 正确的 trusted proxy 配置。反向代理很容易配错，后面单独讲。暂时搞不明白时，宁可用 SSH 隧道或 VPN，也别把 bind 改成 0.0.0.0。

2. 工具权限：从最小权限开始

入口处理以后，再看 Agent 能做什么。重点就两件事：文件访问范围和命令执行权限。

工具权限不要从“全给”开始。先给最小，再按需要一项一项放开。

建议从这个基线起步：

json

{
  "tools": {
    "profile": "messaging",
    "fs": {
      "workspaceOnly": true
    },
    "exec": {
      "security": "deny",
      "ask": "always"
    },
    "elevated": {
      "enabled": false
    }
  }
}

这段是配置片段。合并之前先备份原配置，哪怕只是复制一份放旁边，也能少很多麻烦。

逐行说：

profile: "messaging"：先按低风险消息场景跑，不要一上来就给自动化、运行时、系统级工具。
workspaceOnly: true：文件访问限制在工作区内，别让 AI 随意访问宿主机的文件。
exec.security: "deny"：命令执行默认拒绝，需要时再开。
exec.ask: "always"：即使允许某些命令，也要每次确认。网页、文档、聊天内容都可能被模型误当成指令。
elevated.enabled: false：高权限操作默认关闭。能不用管理员权限，就别用。

如果你的版本支持更细的 deny 组，优先关掉 automation、runtime、额外文件系统访问这些高风险能力。它们不是不能用，而是不该默认开。

判断一项能力能不能开，可以问三个问题：

它能不能读到我不想给 AI 看的东西？
它能不能改掉我不想让 AI 改的东西？
出事以后，我能不能快速回滚？

前两个只要有一个是“能”，就先别开。第三个如果是“不知道”，也先别开。

3. 凭据和日志：密钥别散在各处

工具权限收住以后，要处理的是密钥和记录。很多事故不是从主配置漏的，而是从 logs、transcripts、workspace 里的残留漏的。

先对齐几个词：

API Key / Token：机器用的密码。别人拿到它，不一定需要你的账号密码，也可能调用你的服务。
日志 logs：程序运行记录。排障有用，但容易带出敏感内容。
转录 transcripts：AI 对话和工具调用记录。它可能包含文件路径、命令、接口返回，甚至密钥片段。

Token 不要明文写进主配置。 更好的做法是放进环境变量、密钥管理系统，或者至少放进单独的 secrets 文件，并收紧权限。

在 Linux / macOS / WSL 终端里可以这样准备：

bash

mkdir -p ~/.config/openclaw
touch ~/.config/openclaw/secrets.env
chmod 600 ~/.config/openclaw/secrets.env

这三行分别是：创建配置目录、创建空文件、只允许当前用户读写这个文件。

secrets.env 里放类似这样的内容：

bash

OPENROUTER_API_KEY="sk-or-..."
OPENCLAW_GATEWAY_TOKEN="你的复杂随机 token"

然后在启动 OpenClaw 前加载它。具体方式看你的部署脚本：可能是 source ~/.config/openclaw/secrets.env，也可能是 Docker 的 --env-file，或者 systemd 的 EnvironmentFile。目标只有一个：密钥不要出现在 Git、文章、截图、群聊、长期日志里。

日志脱敏开起来：

json

{
  "logging": {
    "redactSensitive": "tools"
  }
}

这表示工具调用里疑似 API Key、Token、Bearer 这类敏感值，不要原样写进日志。它挡不住所有情况，但不开更糟。

~/.openclaw/ 目录权限收紧：

bash

chmod -R 700 ~/.openclaw
chmod 600 ~/.openclaw/transcripts/* 2>/dev/null

700 表示只有当前用户能读、写、进入这个目录。第二行把 transcripts 下的文件改成只有当前用户可读写。末尾的 2>/dev/null 只是隐藏“没有这个目录/文件”之类的报错。

扫一遍残留：

bash

grep -RIn "token\|apikey\|secret\|bearer" ~/.openclaw 2>/dev/null

这条命令会在 ~/.openclaw 里搜索常见敏感词。搜到东西别急着删，先判断它是什么：配置、日志、转录，还是误报。如果是真密钥，先轮换，再清理。

还有两件事容易忘：

~/.openclaw/、workspace、transcripts、logs 不要放进 OneDrive / iCloud / Google Drive 自动同步目录。
日常备份脚本不要把 .env、日志、转录整包打上云。

4. 渠道策略：别让陌生人指挥 Agent

如果只在本机网页里用 OpenClaw，主要风险来自 Gateway 和工具权限。可一旦接到 Telegram、WhatsApp、Discord，问题就变成了：谁能给它下指令。

推荐的 WhatsApp 配置大概是这样：

json

{
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "allowFrom": ["+15555550123"],
      "groupPolicy": "allowlist",
      "groups": {
        "*": {
          "requireMention": true
        }
      }
    }
  }
}

这段要改成自己的账号（如手机号），具体解释：

dmPolicy: "pairing"：私聊要先配对。
allowFrom：只允许明确列出来的人控制。
groupPolicy: "allowlist"：群聊走白名单。
requireMention: true：群里必须明确 @ 它，它才响应。

不要为了测试方便把私聊策略改成 open。open 的意思接近：只要能给这个账号发消息，谁都可以尝试指挥你的 Agent。

5. 装完立刻跑 security audit

前面几步做完，不代表配置一定正确。装完、改完配置、接完渠道，都该跑一遍检查。

打开终端，进入你运行 OpenClaw 的环境，然后执行：

bash

openclaw doctor
openclaw security audit --deep

我会这样看这两个命令：

命令	你要看什么
`openclaw doctor`	当前环境是否正常、配置路径在哪里、有没有迁移或修复提示
`openclaw security audit --deep`	Gateway 有没有暴露、device auth 有没有关、工具权限和渠道策略有没有危险配置
`openclaw security audit --deep --fix`	自动修一部分问题，但会改配置，别无脑运行

如果 audit 提示 warning，不要只看最后有没有 “passed”。重点看这些关键词：Gateway、bind、device auth、trusted proxy、exec、workspace、token、logging、channel。

--fix 不是保险按钮。先跑不带 --fix 的版本，看清楚它要改什么，再决定要不要自动修。

反代：最容易配错的一层

很多人会想：套一层 Nginx 或 Caddy，上 HTTPS，不就安全了吗？

方向没错，但还不够。

反代，也就是反向代理，作用是让外部用户先访问 Nginx / Caddy，再由它转发到 OpenClaw Gateway。这样可以统一做 HTTPS、域名、访问控制。

如果没有设置过反代，或者不懂反代是什么的，可以直接跳过这一小节的内容。

真正容易出错的地方不在“页面能不能打开”，而在“OpenClaw 以为请求是从哪来的”。Gateway 判断来源时，往往要看代理传过来的来源信息。反代如果把所有请求都改写成 127.0.0.1，Gateway 可能会误以为它们都来自本机。

一个能用的 Nginx 片段大概是这样：

nginx

server {
    listen 443 ssl http2;
    server_name openclaw.example.com;

    ssl_certificate /etc/letsencrypt/live/openclaw/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw/privkey.pem;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        proxy_pass http://127.0.0.1:18789/;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

最关键的是这一行：

nginx

proxy_set_header X-Forwarded-For $remote_addr;

它的意思是：把真实连接到 Nginx 的客户端地址写进去。

不要写成：

nginx

proxy_set_header X-Forwarded-For $http_x_forwarded_for;

后者会把客户端自己带来的 X-Forwarded-For 继续往后传，而这个头可以伪造。简单说，你不能让访问者自己告诉你“我是谁”，再把这句话原样交给 Gateway。

反代这里记住四条：

trustedProxies 只写你真的信任的代理 IP。别写大网段，更别全放开。
X-Forwarded-For 要 overwrite，不要沿用客户端传来的头。
WebSocket 的 Upgrade / Connection 头不能漏，否则控制界面和实时连接可能断。
不懂 trusted proxy 时，先别开远程控制台。保持 loopback + token 更稳。

页面能打开，只说明流量通了。真正要确认的是：系统把谁当成可信来源。

Docker：多加几个参数，少掉一类事故

如果选择 Docker，可以从这个启动方式开始：

bash

docker run -d --name openclaw \
  --user openclaw \
  --read-only \
  --tmpfs /tmp \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  -v /opt/openclaw/workspace:/workspace \
  -p 127.0.0.1:18789:18789 \
  openclaw-secure

这条命令是在宿主机终端执行的。镜像名 openclaw-secure 只是示例，要换成你实际使用的镜像。

这些参数其实都是在做一件事：让容器少拿权限、少写文件、少碰宿主机。

逐个解释：

--user openclaw：不用 root 用户跑容器。
--read-only：容器根文件系统只读，降低被持久化篡改的机会。
--tmpfs /tmp：临时文件放内存里，减少落盘残留。
--cap-drop=ALL：先去掉 Linux capabilities，也就是容器里的额外系统能力，需要什么再单独加。
--security-opt=no-new-privileges：防止进程通过某些路径拿到更高权限。
-v /opt/openclaw/workspace:/workspace：只挂载一个工作区，不把整个家目录交出去。
-p 127.0.0.1:18789:18789：端口只绑定本机。

两件事要避开：

不要挂载 Docker socket。 也就是别把 /var/run/docker.sock 递给 OpenClaw。容器一旦能控制 Docker socket，基本就能绕过容器隔离去操作宿主机。

不要把整个 $HOME 挂进去。 只给 /workspace。SSH 密钥、下载目录、浏览器配置、桌面文件，不需要 AI 碰到。

如果选择虚拟机，道理一样：给一个干净 VM，开快照，只放这个项目需要的目录和凭据。出事以后回滚快照就行。

如果暂时只能裸机跑

不是每个人一开始都有 Docker / VM 环境。那至少把下面几件事做掉：

新建一个低权限系统用户，只用它跑 OpenClaw。
不用管理员 / root 权限启动。
workspace 单独建目录，别放在桌面、下载、OneDrive 同步目录里。
配置改动前先备份。
命令执行默认关，需要时再临时开。
API Key 用单独 secrets 文件或系统密钥管理，不写进项目目录。

这不是最佳形态，只是底线。别把底线当最佳实践。

装完不是终点

很多问题不是第一次配置时犯的，而是后面一点点“图方便”改出来的。

今天 Gateway 绑 loopback，工具权限也收得很紧。两周后为了手机访问方便，你把 bind 改成 0.0.0.0。又过几天为了少点确认，把 exec.ask 改成 never。再后来接了群聊机器人，私聊策略顺手开成 open。

每一步看起来都只是省事一点，连起来就很危险。

建议按这个节奏复查：

每次配置变更后，跑 openclaw security audit --deep。
每次升级后，复查 Gateway、trusted proxy、日志脱敏、pairings。
每次新增渠道后，检查私聊策略、群聊白名单、是否需要 @。
每季度盘一遍已安装 Skills、有效 allowlist、还在用的 API Key。

下面几种情况，我会直接轮换凭据：

升级修复了安全问题。
怀疑 logs / transcripts 里带出过 token。
装过来源不明的 Skill。
渠道机器人被拉进陌生群组。
配置文件或 .env 曾经进入 Git、网盘、备份包。

要换的不只是 Gateway Token，还有 Bot Token、API Key、任何曾经进过配置文件、日志、转录的密钥。

Skills 也别当应用商店逛。只装业务上真需要的，安装前看发布者和源码，能固定版本就固定版本，关闭自动更新。上一篇 ClawHavoc 事件里，恶意 Skills 已经到四位数了。

小白版安全加固检查表

这张表可以直接收藏。每次装完、升级、改配置、接新渠道，都拿出来扫一遍。

阶段	检查项
运行环境	☐ 优先使用 Docker 或虚拟机
	☐ 只挂载专门的 workspace，不挂整个 `$HOME`
	☐ 不用 root / 管理员账号跑
	☐ 工作目录不放在 OneDrive / iCloud / Google Drive 同步目录
改配置前	☐ 已确认 OpenClaw 实际读取的配置路径
	☐ 已备份原配置
	☐ JSON 片段是合并进去，不是覆盖整个文件
Gateway	☐ Gateway 绑定 `loopback` / `127.0.0.1`
	☐ 没有使用 `0.0.0.0` 对外监听
	☐ 启用高熵 token / password
	☐ `dangerouslyDisableDeviceAuth = false`
工具权限	☐ Tools 基线：`messaging` + `workspaceOnly` + `exec deny` + `ask always`
	☐ 高权限能力默认关闭
	☐ automation / runtime / 额外文件系统访问没有默认放开
凭据和日志	☐ API Key / Token 不写进 Git 和主配置明文
	☐ secrets 文件权限是 600
	☐ `~/.openclaw/` 权限收紧到 700
	☐ 日志脱敏 `redactSensitive: "tools"` 已开启
	☐ 已扫描 transcripts / logs / `.env` 残留
渠道	☐ 私聊策略不是 `open`
	☐ 只允许明确配对或白名单用户
	☐ 群聊开启 `requireMention`
反代	☐ `X-Forwarded-For` 是 overwrite，不信客户端伪造头
	☐ `trustedProxies` 只包含真实代理 IP
	☐ WebSocket `Upgrade` / `Connection` 头已配置
Docker	☐ 加了 `--read-only --cap-drop=ALL --security-opt=no-new-privileges`
	☐ 不挂载 docker.sock
	☐ 端口只绑定 `127.0.0.1`
持续维护	☐ 升级后 / 变更后跑 `security audit --deep`
	☐ 凭据轮换触发条件已建立
	☐ Skills 使用白名单和固定版本

OpenClaw 系列（三）：OpenClaw 安全加固实战

TL;DR 文章速览

前言

先说前提：尽量别在主力机上裸跑

后面的命令该在哪敲？

五件装完就要做的事

1. Gateway：先把入口收住

2. 工具权限：从最小权限开始

3. 凭据和日志：密钥别散在各处

4. 渠道策略：别让陌生人指挥 Agent

5. 装完立刻跑 security audit

反代：最容易配错的一层

Docker：多加几个参数，少掉一类事故

如果暂时只能裸机跑

装完不是终点

小白版安全加固检查表

推荐阅读

/// 相关日志 ///

OpenClaw 系列（二）：OpenClaw 安全风险详细拆解

OpenClaw 系列（一）：装完小龙虾直接用？当心背后的巨大安全风险

教 AI 写工作月报：从一次性投喂到节点化工作流，再到 Skills 模块化改造