逆向工程 Docker Sandbox 未公开 MicroVM API：隔离机制与工程化实践

Docker Desktop 4.58 引入的 Sandboxes 功能标志着容器运行时架构的一次重要演进 —— 它不再依赖传统的 Linux namespace 隔离，而是为每个 Agent 会话启动一个独立的 MicroVM，并在其中运行完整的 Docker daemon。Rivet 团队通过逆向工程发现了这一未公开的 HTTP API 接口，揭示了其底层通信机制与隔离实现细节。本文基于这些发现，结合 Docker 官方架构说明，分析该接口的设计思路、隔离边界以及工程实践中需要关注的关键参数。

MicroVM 架构的设计动机

在 Sandboxes 出现之前，运行 AI Coding Agent 面临一个两难选择：直接使用宿主机 Docker 存在安全风险，而传统虚拟机又带来过高的启动延迟。Docker 团队评估了四种主流方案：全量虚拟机启动过慢且资源开销大；纯容器方案无法满足 Docker-in-Docker 的安全需求；WASM/V8 隔离虽然启动快，但无法支持完整的操作系统环境，Agent 无法安装系统包或执行任意 shell 命令。

MicroVM 方案的核心优势在于硬件级隔离与容器生态的兼容性兼得。每个 Sandbox 获得独立的内核，通过虚拟机边界实现与宿主机的完全隔离。与此同时，每个 MicroVM 内部运行一个私有的 Docker daemon，Agent 可以执行完整的 docker build、docker run 和 docker compose 操作，无需挂载宿主机 Docker socket 或获取特权模式。

逆向发现的 API 接口

Rivet 团队在分析 Docker Desktop 进程时发现，Sandbox 管理通过一个 Unix domain socket 暴露 HTTP API，默认路径为 /var/run/sandboxd.sock。该接口虽未公开文档，但遵循标准的 RESTful 设计。

核心端点包括：

• GET /vms：列出当前运行的所有 MicroVM 实例
• POST /vm：创建新的 MicroVM，返回包含 VM ID、docker.sock 路径和 CA 证书路径的配置对象
• DELETE /vm/{id}：销毁指定 VM 及其内部所有容器

创建 VM 的响应体包含两个关键路径：per-VM 的 docker.sock 用于后续容器操作，以及 CA 证书路径用于 TLS 验证。这种设计允许宿主机进程与 VM 内的 Docker daemon 建立安全通信，同时保持网络隔离。

隔离机制的三层边界

Docker Sandboxes 的隔离模型由三个层次构成，每层都有明确的职责边界。

第一层：VM 硬件边界。每个 MicroVM 拥有独立的内核和内存空间，通过 macOS Hypervisor.framework、Windows Hypervisor Platform 或 Linux KVM 实现硬件级隔离。这意味着即使 MicroVM 内的内核遭到攻破，攻击者仍需突破虚拟机监控器才能触及宿主机。

第二层：私有 Docker daemon。与传统 DinD（Docker-in-Docker）方案不同，这里的 Docker daemon 完全运行在 MicroVM 内部，通过 VM 边界与宿主机隔离。Agent 获得的是完整的 Docker 环境，而非特权容器的受限视图。

第三层：网络代理策略。MicroVM 的出站流量并非直接访问外部网络，而是通过宿主机侧的代理进行转发。这一设计使得网络策略可以在基础设施层面强制执行，而非依赖 Agent 自身的配置。文件访问、网络端点和密钥注入都在 VM 启动前完成配置，Agent 运行期间无法修改这些边界。

镜像分发与生命周期管理

由于 MicroVM 内部无法直接访问宿主机的镜像仓库，Docker Sandboxes 采用了一种特殊的镜像分发机制。镜像首先在宿主机上构建完成，然后被导出为 tarball 格式，最后通过 docker --host unix://<vm-sock-path> load 命令加载到目标 VM 中。

这一流程对 CI/CD 集成有直接影响。在多 Agent 并发场景下，建议采用以下策略：

1. 镜像预缓存：在 VM 创建前完成镜像构建和导出，避免在 Agent 运行期间执行耗时操作
2. 分层加载：对于基础镜像和依赖层，考虑使用 docker save 的层级别导出，减少重复传输
3. 生命周期绑定：将 VM 生命周期与 Agent 会话绑定，任务完成后立即销毁 VM，确保无状态残留

可落地的工程参数

基于上述架构分析，以下是实际部署时需要关注的关键参数和检查点。

VM 资源配额：

• CPU：建议为每个 MicroVM 分配 2-4 核，根据 Agent 并发任务数调整
• 内存：基础开销约 512MB，加上容器工作负载，建议预留 2-4GB
• 磁盘：VM 镜像和容器层占用空间，建议单 VM 预留 10-20GB

API 调用监控：

• 监控 /var/run/sandboxd.sock 的响应延迟，正常创建 VM 应在 3-5 秒内完成
• 追踪 VM 数量上限，避免资源耗尽导致新 Agent 无法启动
• 记录镜像加载耗时，识别网络瓶颈或存储性能问题

安全边界检查清单：

• 确认宿主机文件系统挂载遵循最小权限原则
• 验证网络代理策略阻止了 VM 对敏感内网服务的访问
• 定期轮换 VM 内 Docker daemon 的 TLS 证书

局限性与风险提示

需要明确的是，通过 sandboxd.sock 访问的 API 属于未公开接口，Docker 可能在后续版本中修改其契约。生产环境若依赖此接口，建议：

1. 锁定 Docker Desktop 版本，在升级前进行回归测试
2. 封装 API 调用逻辑，隔离底层变更的影响范围
3. 关注 Docker 官方文档，一旦公开 API 可用即迁移至稳定接口

此外，Sandboxes 功能目前仅支持 macOS 和 Windows 平台的 Docker Desktop 4.58+，Linux 用户暂时无法使用此功能。

结语

Docker Sandboxes 的 MicroVM 架构代表了一种新的隔离范式 —— 它既保留了容器的开发体验，又提供了接近虚拟机的安全边界。通过逆向工程揭示的 sandboxd.sock 接口，开发者可以更深入地理解其内部机制，并在自动化工具中集成 VM 生命周期管理。随着 AI Agent 的普及，这种 "每个 Agent 一个 MicroVM" 的模式可能成为云原生安全的新基准。

资料来源：

• Rivet: "We Reverse-Engineered Docker Sandbox's Undocumented MicroVM API" (2026-02-04)
• Docker: "Why MicroVMs: The Architecture Behind Docker Sandboxes" (2026-04-16)

systems