Docker Sandboxes 深度解析：用 microVM 安全隔离 AI 编码 Agent

AI开发者工具Docker

AI 编码 Agent（Claude Code、Gemini CLI、Codex 等）越来越自动化：安装包、改配置、跑构建，甚至直接执行 git commit。让这些 Agent 在你的开发机上自由奔跑，等于把整个系统交出去。Docker 推出的 Sandboxes（sbx CLI）把这个问题用 microVM 隔离解决：Agent 在一个独立的虚拟机里做任何事，宿主机不受影响，一行命令创建，一行命令销毁。

核心架构：五层隔离

Docker Sandboxes 的安全模型基于五层隔离，每层解决一个特定威胁面。

Docker Sandboxes 安全模型：沙盒 VM 与宿主机之间的 hypervisor 边界

Hypervisor 隔离是最硬的一道边界。每个沙盒运行在独立的 microVM 中，拥有自己的 Linux 内核。Docker 自研了 VMM（虚拟机监视器）而非使用 Firecracker，因为后者面向 Linux 服务器，而 Docker 需要同时覆盖 macOS、Windows 和 Linux 三端。microVM 与容器隔离有本质区别：容器共享宿主机内核，内核级别的破坏可能波及整个系统；microVM 有硬件级虚拟化边界，沙盒内的 Agent 拥有 sudo 权限，在 VM 内部做什么都不影响宿主机。

网络隔离采用 deny-by-default 策略。所有出站流量经过宿主机上的 HTTP/HTTPS 代理，非 HTTP 协议（裸 TCP、UDP、ICMP）在网络层直接阻断。默认配置下，私有 IP 段、回环地址、链路本地地址全部不可达。三档预设策略控制域名白名单：Open（全放行）、Balanced（放行 npm/PyPI/GitHub 等常见开发服务）、Locked Down（全阻断，需逐条放行）。

Docker Engine 隔离意味着每个沙盒拥有独立的 Docker 守护进程，与宿主机 Docker 守护进程之间没有任何路径连通。Agent 可以在沙盒内构建镜像、运行容器，但这些操作对宿主机不可见。

工作区隔离有两种模式。默认的直接挂载（direct mount）将工作目录以读写方式映射进沙盒，Agent 修改的文件在宿主机实时可见。--clone 模式则将仓库以只读方式挂载，Agent 在 VM 内部操作私有克隆，适合需要隔离 Agent 改动的场景。--branch 模式进一步创建 Git worktree，Agent 在独立分支上工作，宿主机的主分支不受影响。

凭据隔离是安全设计中最精巧的一环。API Key 不进入沙盒 VM，而是存储在宿主机的 OS keychain 中。宿主机代理拦截出站 HTTP 请求，在转发前注入认证 header。这意味着即使沙盒被攻破，攻击者也无法从环境变量或文件系统中读取到原始密钥。

sbx CLI：使用流程

安装和启动只需要几条命令。

macOS（Apple Silicon，需要 macOS Tahoe 26+）：

bash
brew trust docker/tap
brew install docker/tap/sbx
sbx login

Windows（需要 Windows 11 和 HypervisorPlatform）：

powershell
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All
winget install -h Docker.sbx
sbx login

Linux（Ubuntu 24.04+，需要 KVM）：

bash
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm
sbx login

登录后选择默认网络策略，然后进入项目目录启动 Agent：

bash
cd ~/my-project
sbx run claude

sbx 支持的 Agent 列表覆盖了当前主流的编码工具：Claude Code、Codex、GitHub Copilot CLI、Gemini、Kiro、OpenCode，以及内置的 Shell Agent（用于测试沙盒连通性）。首次运行会拉取 Agent 镜像，后续启动复用缓存。

关键命令一览：

命令用途
sbx run <agent>在沙盒中启动 Agent
sbx run <agent> --branch auto在 Git worktree 中启动，Agent 操作独立分支
sbx ls查看运行中的沙盒列表
sbx stop <name>停止沙盒（不删除）
sbx rm <name>删除沙盒及其所有内容
sbx rm --all删除所有沙盒
sbx policy ls查看当前网络策略
sbx policy allow network <domain>添加域名白名单
sbx ports <name> --publish 8080:3000端口转发，将沙盒内服务暴露到宿主机
sbx secret set -g <provider>设置凭据（存入 OS keychain，代理注入）

网络策略与凭据管理

网络策略的颗粒度控制是 Docker Sandboxes 区别于普通容器方案的关键。

登录时选择 Balanced 策略后，sbx policy ls 可以看到当前的白名单规则。默认放行 GitHub、npm registry、PyPI、Docker Hub 等开发常用域名。添加新域名只需一条命令：

bash
sbx policy allow network registry.npmjs.org

如果沙盒内的 Agent 需要访问宿主机上运行的本地服务（如 Ollama 在 11434 端口），可以通过 host.docker.internal 配置：

bash
sbx policy allow network localhost:11434
# 沙盒内访问: curl http://host.docker.internal:11434

端口转发让网络隔离不阻碍开发调试。沙盒默认网络隔离，Agent 启动的开发服务器无法通过 localhost 直接访问。sbx ports 命令转发流量：

bash
sbx ports my-sandbox --publish 8080:3000
open http://localhost:8080

注意两点：沙盒内的服务必须绑定 0.0.0.0 而非 127.0.0.1（大多数开发服务器默认绑定回环地址）；端口映射在沙盒重启后不保留，需要重新配置。

凭据管理的流程如下。对于使用订阅制（如 Claude Max/Team/Enterprise）的 Agent，sbx login 后在沙盒内执行 /login 即可通过 OAuth 认证，会话令牌存在宿主机上由代理注入。对于 API Key 认证：

bash
sbx secret set -g anthropic
# 输入 API Key，存入 OS keychain

需要 GitHub 访问权限（创建 PR 等）：

bash
sbx secret set -g github -t "$(gh auth token)"

Docker Sandboxes 管理界面：展示沙盒列表与网络日志

Branch 模式：Agent 的独立工作区

--branch 模式解决了 Agent 并行工作的冲突问题。

bash
sbx run claude --branch my-feature

这条命令在仓库下的 .sbx/ 目录中创建一个 Git worktree，Agent 在 my-feature 分支上工作，与宿主机的 main 分支完全隔离。你可以继续在 main 上写代码，Agent 在自己的分支上推进。

text
my-project/
├── src/                          ← 你的主工作区
├── .sbx/
│   └── claude-my-project-worktrees/
│       └── my-feature/           ← Agent 在这里工作
└── .gitignore

Agent 完成后，审查并合并：

bash
cd .sbx/claude-my-project-worktrees/my-feature
git log
git diff main
git push -u origin my-feature
gh pr create

多个 Agent 可以同时在同一个仓库上工作，各自拥有独立的 worktree：

bash
sbx run --branch feature-a sandbox-1
sbx run --branch feature-b sandbox-2

Kits 与 Templates：可复用的环境配置

Templates 是预构建的 Docker 镜像。如果项目需要 .NET、Rust 或其他非默认工具链，构建一个 Dockerfile 扩展默认沙盒模板，推送到 registry，然后通过 --template 使用：

bash
sbx run claude --template ghcr.io/myorg/my-dotnet-sandbox:1.0

Kits 是运行时应用的 YAML 工件，可以安装工具、注入环境变量和凭据、配置网络规则、放置文件、执行启动命令，甚至定义全新的 Agent。Kits 支持三种分发方式：ZIP 文件（sbx kit pack）、OCI registry（sbx kit push/pull）、Git 引用（--kit "git+https://..."）。

bash
# 使用本地 Kit
sbx run claude --kit ./my-kit/

# 使用 Git 仓库中的 Kit
sbx run claude --kit "git+https://github.com/docker/sbx-kits-contrib.git#ref=v0.1.0&dir=code-server"

# 使用 OCI registry 中的 Kit
sbx run claude --kit ghcr.io/myorg/my-kit:1.0

Templates 和 Kits 设计为协同工作：Template 作为重依赖的基础镜像，Kit 在启动时叠加薄层的项目或团队配置。

与替代方案的对比

Docker 官方文档给出了四种隔离方案的对比：

方案隔离级别Docker 访问适用场景
Sandboxes (microVM)完整（Hypervisor）独立守护进程自主 Agent
容器 + Socket 挂载部分（Namespace）共享宿主守护进程受信工具
Docker-in-Docker部分（特权）嵌套守护进程CI/CD 流水线
直接在宿主机执行无宿主守护进程手动开发

Sandboxes 用更高的资源开销（一个 VM 加上其独立守护进程）换取完整隔离。需要轻量打包且不需要 Docker 访问的场景用容器即可；需要给自主 Agent 完整 Docker 能力但不信任它的场景用 Sandboxes。

定价与许可

sbx CLI 免费使用，包括商业用途。组织级治理（集中管理网络策略、文件系统策略、审计日志、SIEM 转发）需要单独的付费订阅。sbx 是独立二进制文件，不绑定 Docker Desktop 许可。

局限性

了解几个实际限制有助于判断适用场景：

工作区直接挂载模式下，Agent 修改的文件实时反映到宿主机。这包括 Git hooks、CI 配置、IDE 任务配置、Makefile、package.json 脚本等构建文件。Git hooks 位于 .git/ 目录内，git diff 输出不显示这些变更，需要单独检查。

默认域名白名单包含宽泛的通配符。例如 *.googleapis.com 覆盖了远超 AI API 的众多服务。sbx policy ls 可以查看完整规则列表，按需移除不需要的条目。

Kits 在安装时以 root 权限执行命令。sbx 默认限制 Kit 安装来源为 Docker Hub（可通过配置扩展），以降低供应链风险。

端口映射不跨沙盒重启保留。每次沙盒重启后需要重新 sbx ports 配置转发。

支持的 Agent

sbx 当前支持以下编码 Agent，每个 Agent 有独立的配置文档：

  • Claude Code（Anthropic）
  • Codex（OpenAI）
  • GitHub Copilot CLI
  • Gemini（Google）
  • Kiro（AWS）
  • OpenCode
  • Docker Agent（内置）
  • Shell（内置，用于测试）

此外，通过 Integrations 支持 VS Code、Cursor、Claude Desktop 和 ChatGPT 以 SSH 方式连接到沙盒。

来源：Docker Sandboxes 官方文档、Docker 博客