OpenClaw 安全使用全攻略：从 Docker 本地部署到权限加固，零风险 AI 智能体实战

1. 为什么 OpenClaw 本地部署后反而更容易出事OpenClaw 是一个可本地部署、具备系统执行能力的开源 AI 智能体网关它能读写文件、控制浏览器、跨应用自动化把「一句话指挥电脑」变成现实。适合谁适合想把 AI 智能体真正落到自己机器上、又不愿意把数据交给第三方云端的开发者和重度效率用户。但恰恰因为它跑在你自己的机器上、又握着系统级执行权限默认配置下的风险比纯云端助手高得多。我见过太多人docker run一把梭端口直接映射到0.0.0.0容器里用 root 跑工作目录挂载整个/home。这种部署方式等于把家门钥匙插在门上还贴了张纸条写「欢迎光临」。OpenClaw 的风险集中在三个方向权限越权默认高权限运行可访问桌面、文档、密钥文件容易被提示注入诱导执行恶意命令、网络暴露默认端口 18789/19890 会被公网扫描无认证即可被接管、数据泄露本地缓存、会话记录、API 密钥未加密一旦容器被突破全部裸奔。这篇不讲花活只讲可复制、能跟做的安全闭环以 Docker 部署为起点把网络暴露面收窄到回环地址把文件系统权限压到最小把工具调用边界用白名单锁死最后用一次越权访问验证动作确认加固真的生效。全程系统原生能力加官方配置不依赖任何第三方加固工具。需要先说明一个前提OpenClaw 本身只是执行框架它调用的大模型能力需要你自己接。我实测下来用 TaoToken 这类兼容 OpenAI 协议的中转来提供模型侧能力比较省事Base URL 填https://taotoken.net/apiKey 在控制台生成模型 ID 按需选。这样 OpenClaw 负责本地执行模型推理走独立通道两边职责清晰也方便后面单独审计模型调用日志。下面所有配置都以这个组合为例。2. Docker 部署 OpenClaw 的隔离基线配置这一节给你一份可以直接复制运行的 compose 配置核心目标是把容器关进笼子非 root 运行、丢弃全部 Linux capabilities、根文件系统只读、只挂载一个专用工作目录、网络只绑本地回环。很多人部署 OpenClaw 时习惯network_mode: host图省事但这会把容器网络和宿主机完全打通端口直接暴露是安全大忌。正确做法是用端口映射并显式绑定127.0.0.1。先建目录结构注意工作目录和配置目录分开配置目录单独控制权限mkdir -p /opt/openclaw/{data,config,work} sudo chown -R 1001:1001 /opt/openclaw sudo chmod -R 700 /opt/openclaw然后是docker-compose.yml这份配置我反复调过重点是user、cap_drop、read_only、security_opt四个字段services: openclaw: image: openclaw/openclaw:latest container_name: openclaw-secure user: 1001:1001 cap_drop: - ALL security_opt: - no-new-privileges:true read_only: true tmpfs: - /tmp:size64m,mode1777 ports: - 127.0.0.1:18789:18789 - 127.0.0.1:19890:19890 volumes: - /opt/openclaw/work:/home/clawuser/.openclaw/work:rw - /opt/openclaw/config:/home/clawuser/.openclaw/config:rw - /opt/openclaw/data:/home/clawuser/.openclaw/data:rw environment: - OPENCLAW_GATEWAY_BIND127.0.0.1 - OPENCLAW_LOG_LEVELinfo - TZAsia/Shanghai restart: unless-stopped healthcheck: test: [CMD, wget, -qO-, http://127.0.0.1:18789/health] interval: 30s timeout: 5s retries: 3几个字段值得展开说。cap_drop: ALL把容器内所有特权能力全部丢弃包括NET_RAW、SYS_ADMIN这些常被利用的能力OpenClaw 正常跑不需要任何一个。read_only: true让根文件系统只读即使 AI 被诱导执行写系统文件的操作也会直接失败只留/tmp用 tmpfs 挂载供临时文件使用。no-new-privileges:true阻止容器内进程通过 setuid 提权。ports里写127.0.0.1:18789:18789而不是18789:18789这一条是网络加固的关键前者只监听回环后者会监听所有网卡。启动并确认状态cd /opt/openclaw docker compose up -d docker compose ps docker compose logs --tail50 openclaw正常的话你会看到容器状态是healthy日志里出现网关监听127.0.0.1:18789的记录。如果状态一直是starting然后转unhealthy多半是工作目录权限不对容器内 UID 1001 写不进去回去检查chown那一步。3. 权限最小化与工具调用边界的可复制配置容器隔离解决的是「AI 能不能碰到宿主机」权限配置解决的是「AI 在容器内能碰什么」。OpenClaw 的配置文件默认在~/.openclaw/openclaw.json对应到我们的挂载就是/opt/openclaw/config/openclaw.json。这份文件是安全加固的核心路径白名单、系统命令开关、屏幕录制、无障碍权限全在这里控制。先看完整的配置片段可以直接复制后按需改路径{ gateway: { bind: 127.0.0.1, port: 18789, token: 替换为至少32位随机字符串, auth: { enabled: true, requireToken: true } }, security: { allowedPaths: [ /home/clawuser/.openclaw/work ], blockedPaths: [ /etc, /root, /home/clawuser/.ssh, /home/clawuser/.openclaw/config, /proc, /sys ], allowSystemCommands: false, allowScreenCapture: false, allowAccessibility: false, allowFileDelete: false, allowFileWrite: true }, tools: { whitelist: [ file_read, file_write, http_request ], blacklist: [ shell_exec, browser_automation, clipboard_read ] }, model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelId: claude-sonnet-4-5 }, logging: { persistChat: false, uploadLogs: false, level: info } }allowedPaths只留工作目录blockedPaths把配置目录本身也拉黑防止 AI 读到网关令牌。allowSystemCommands设为false是整份配置里最关键的一行它直接切断 AI 执行 shell 命令的能力绝大多数越权事故都从这一步被堵死。tools.whitelist用白名单而不是黑名单思路只放行file_read、file_write、http_request三个必要工具其余一律不可用。模型侧的 Key 不要写进 JSON用环境变量注入。在/opt/openclaw/config/.env里写TAOTOKEN_API_KEYsk-你的实际密钥然后chmod 600 /opt/openclaw/config/.env并在 compose 里加一行env_file: /opt/openclaw/config/.env。这样密钥不进 Git、不进镜像、不进日志。模型 ID 按你实际订阅的填Claude 系列、GPT 系列都支持具体可用列表在控制台的模型对话页能查到。改完配置重启容器docker compose restart openclaw docker compose logs --tail20 openclaw | grep -i security\|whitelist日志里应该能看到安全策略加载成功的提示。如果启动直接报配置解析错误多半是 JSON 里多了尾逗号用python -m json.tool /opt/openclaw/config/openclaw.json校验一下。4. 验证请求与越权访问测试配置写完不算数得验证。这一节做两件事确认正常请求能通确认越权请求被拦。先测网关健康检查和认证是否生效# 不带 token应该返回 401 curl -i http://127.0.0.1:18789/health # 带 token应该返回 200 curl -i -H Authorization: Bearer 你的网关令牌 \ http://127.0.0.1:18789/health第一次请求返回401 Unauthorized说明认证生效这是好事。如果两次都返回 200说明requireToken没起作用回去检查配置有没有被正确加载。接着测模型通道是否打通直接调 TaoToken 的兼容接口curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 OK 两个字母}] } | head -c 300返回里能看到choices字段和内容就说明模型侧通了。这一步单独测的意义在于后面 OpenClaw 报错时你能快速判断是模型通道问题还是本地执行问题。现在做越权验证这是整篇最关键的动作。通过 OpenClaw 发一条试图读取敏感目录的指令观察是否被拦截curl -s -X POST http://127.0.0.1:18789/api/tool \ -H Authorization: Bearer 你的网关令牌 \ -H Content-Type: application/json \ -d { tool: file_read, params: {path: /home/clawuser/.ssh/id_rsa} }预期结果是返回权限拒绝错误类似path not allowed by security policy。如果它真的把私钥内容读出来了说明blockedPaths没生效立刻停服务排查。再测一条系统命令curl -s -X POST http://127.0.0.1:18789/api/tool \ -H Authorization: Bearer 你的网关令牌 \ -H Content-Type: application/json \ -d { tool: shell_exec, params: {command: cat /etc/passwd} }因为shell_exec不在白名单且allowSystemCommands为 false这条应该直接返回工具不可用。两条都被拦说明权限最小化和工具边界都生效了加固闭环完成。5. 常见报错排查对照部署和加固过程中会撞到几类典型报错这里按真实错误信息对照排查。401 Unauthorized出现在网关请求里两种可能一是请求头没带Authorization: Bearer二是令牌和配置里的不一致。先确认配置里gateway.token的值再确认请求头拼写注意 Bearer 后面有一个空格。如果重启过容器但令牌没变还报 401检查是不是读到了旧的配置文件docker compose config能看到实际挂载路径。local proxy failed或connection refused出现在模型调用时说明 OpenClaw 连不上模型通道。先单独用第 4 节的 curl 测https://taotoken.net/api/v1/chat/completions能通就是 OpenClaw 配置里的baseUrl写错了注意结尾不要多加/v1兼容层会自动补。容器内网络和宿主机不同如果宿主机能通容器不通检查容器 DNS必要时在 compose 里加dns: 223.5.5.5。reading choices: unexpected end of JSON input这类报错通常是模型返回了非 JSON 内容常见于模型 ID 写错导致接口返回错误页。核对modelId是否在可用列表里控制台的模型对话页可以直接验证某个 ID 能不能调通。另外检查请求体是不是被截断大 payload 时容易出这个问题。OAuth相关报错一般出现在你用了需要 OAuth 的模型供应商但没配回调。用 API Key 方式接入就绕开了这个问题TaoToken 走的是标准 Bearer 认证不需要 OAuth 流程。如果你在 OpenClaw 里配了别的 provider 又混用了 OAuth把 provider 统一成openai-compatible即可。permission denied写文件失败检查三处容器内 UID 是不是 1001、挂载目录属主是不是 1001、allowedPaths有没有包含目标路径。三者缺一不可。read_only根文件系统下只有挂载的卷和/tmp可写往别处写必然失败这是预期行为。container unhealthy但日志没明显错误多半是 healthcheck 的 wget 在容器里不存在。把 healthcheck 换成[CMD, curl, -f, http://127.0.0.1:18789/health]或者干脆去掉 healthcheck 用docker compose logs人工确认。6. 长期运行的安全运维与能力接入加固不是一次性的OpenClaw 这类有执行能力的智能体需要持续运维。更新镜像前先备份配置和工作目录docker compose pull之后docker compose up -d起来后重跑第 4 节的两条越权测试确认新版本没有放宽默认策略。订阅官方 GitHub 的安全公告有补丁第一时间跟。日志审计每周做一次重点看shell_exec有没有被调用记录正常情况下应该一次都没有、file_read有没有触碰白名单外的路径、有没有异常来源 IP 访问网关。因为persistChat关了会话记录不落盘审计只看操作日志即可隐私面更小。如果你要把 OpenClaw 接到长期编码或 Agent 工作流里模型侧的额度消耗会比较快这时候用 Coding Plan 比按量付费更划算适合高频调用的场景。日常想快速验证某个模型 ID 能不能用直接去模型对话页试一句就行不用改配置重启。所有接入需要的 Key 都在 API Keys 页面生成接入细节看接入文档里面有各语言的完整示例。最后留一个我踩过的坑allowedPaths里写相对路径在容器里会解析到意料之外的位置一律用绝对路径。还有工作目录不要图省事挂载宿主机家目录哪怕只读也别挂一旦挂上去前面所有权限配置的意义就打了对折。把工作目录当成 AI 的沙箱它只能在这个盒子里活动盒子外面的事它一概碰不到这才是本地智能体安全落地该有的样子。