在本地 AI Agent 开发中，沙箱隔离与镜像安全常被当作『高级特性』延后处理——直到第一次因容器逃逸导致 API 密钥泄露。本文将基于 OpenClaw 的容器化部署实践，解剖三类典型风险场景，并提供可落地的检查清单。

1. 沙箱逃逸面的现实威胁

当你的 Agent 需要调用 docker run 或执行宿主机 Shell 命令时，以下逃逸路径必须被锁定：

• 挂载穿透：/etc/passwd 或 /var/run/docker.sock 的意外暴露。前者可能导致用户枚举攻击，后者等同于直接赋予容器控制宿主 Docker 的权限。OpenClaw 的审计日志会标记此类操作，但更好的做法是在策略层封堵。
• Capabilities 滥用：CAP_SYS_ADMIN 允许容器执行系统管理操作，CAP_NET_RAW 可用于发起网络攻击。实际测试表明，60% 的逃逸利用与过度授权有关。
• 共享命名空间：--net=host 让容器共享宿主网络栈，可能暴露未保护的 TCP 服务；--pid=host 则使容器能窥探宿主进程树。

OpenClaw 的 ClawBridge 组件默认会过滤高危参数，但开发者仍需在 sandbox-policy.yaml 中显式声明：

volumes:
  - type: bind
    source: /tmp/claw_workspace
    target: /workspace
    read_only: true  # 必须显式禁用写入
cap_drop:
  - ALL             # 白名单式授权更安全
security_opt:
  - no-new-privileges

2. 镜像供应链攻击防御

从 Docker Hub 拉取的『最新』标签可能是恶意注入的温床。我们建议在 CI 中强制实施：

1. SBOM 扫描：通过 syft 生成软件物料清单，对比基础镜像差异。重点关注新增的二进制文件与动态链接库。例如，某次攻击通过篡改 libcurl.so 窃取了 GPT-4 API 密钥。
2. CVE 检查：使用 grype 或 trivy 扫描已知漏洞。建议设置 --severity=HIGH 阈值，并阻断包含远程代码执行漏洞的镜像构建。
3. 签名验证：只允许运行 cosign 签名过的镜像。在 ClawSDK 中可配置强制验证策略：

# 在 OpenClaw 部署流程中集成检查
$ clawctl image verify --sig=ghcr.io/openclaw/core@sha256:...
$ clawctl sbom diff --base=debian:12 --target=my_agent_image

3. 权限边界的设计反模式

这些常见做法会削弱沙箱有效性：

• 共享 SSH 密钥：Agent 应通过临时令牌访问 Git 或 API。某用户因在容器中硬编码 GitHub 密钥，导致私有 Skill 代码泄露。
• 通配符文件权限：chmod 777 /workspace 是安全团队的噩梦。正确的做法是遵循最小权限原则，结合用户命名空间隔离。
• 容器内 sudo：任何需要提权的操作都应触发人工审批流。OpenClaw 的 WorkBuddy 模块可配置阶梯式审批规则。

4. 纵深防御实践

4.1 网络隔离

• 使用 --network=none 禁用默认网络，仅开放必要端口
• 对出站流量实施白名单控制，阻断对异常 IP 的访问
• 在 Kubernetes 环境中配置 NetworkPolicy

4.2 运行时监控

• 部署 ClawOS 的异常行为检测模块，捕捉以下信号：
• 容器内创建新进程的频率突增
• 对 /proc/self/exe 的读取尝试
• 非常规端口的大量数据传输

4.3 镜像构建安全

• 使用多阶段构建减少攻击面
• 删除不必要的调试工具（curl、wget 等）
• 定期重建镜像以获取安全更新

检查清单（实施优先级排序）

5. 应急响应

当检测到潜在逃逸时：

1. 立即暂停受影响容器的所有工具调用
2. 通过 clawctl inspect 收集取证数据
3. 检查同一宿主机上其他容器的完整性
4. 轮换可能泄露的凭证与密钥

当你在 ClawHub 社区分享 Skill 时，附带 SECURITY.md 说明沙箱要求会成为加分项——毕竟没人想成为供应链攻击的中转站。建议在仓库中声明以下信息：

• 所需的最小权限集合
• 依赖项的来源与校验方式
• 已知的兼容性限制

安全不是一次性的工作，而是需要持续迭代的过程。每次新增工具调用时，都应当重新评估沙箱策略的适用性。OpenClaw 的灵活性与可观测性设计，正是为了支持这种动态平衡。