解锁 Docker Sandboxes：逆向工程未公开的 MicroVM API

多年来，Docker 容器一直是后端部署的行业标准。然而，随着 AI 编程代理（如 Claude Code、Codex 和 Gemini）的兴起，对执行任意、不可信代码的需求不断增加，标准容器的局限性也变得显而易见。容器共享宿主机的内核，这意味着被攻破的容器可能会危及整个宿主机。

为了解决这个问题，Docker 推出了 "Docker Sandboxes"，这是一种专门为 AI 代理安全设计的解决方案。虽然 Docker 为少数白名单代理提供了有限的 CLI，但他们悄悄发布了一个用于启动 microVM 的未公开 API。该 API 提供了容器无法提供的隔离级别，有效地为运行不可信代码创建了 "金标准"。

容器 vs. MicroVMs：安全差距

要理解为什么 Docker 在其沙箱功能中转向了 microVMs，有必要区分这两种技术。容器使用 namespaces 和 cgroups 来提供隔离，但由于它们共享宿主内核，因此容易受到内核级漏洞利用。 \n相比之下，microVMs 为每个实例提供独立的内核。它们比传统的虚拟机显著更轻量，但提供了 VM 的安全特性。这种架构对于无法信任正在执行的代码的工作负载至关重要，例如用户提交的脚本或多租户插件。

对比概览

特性 Docker Container Docker Sandbox
安全 共享内核 (namespaces) 独立内核 (microVM)
不可信代码 不安全 安全
网络访问 直接 HTTP 通过过滤代理
Volumes 直接挂载 双向文件同步
平台 Linux, macOS, Windows macOS, Windows 仅限 (最初)

逆向工程 sandboxd API

Docker 的沙箱功能由 sandboxd 守护进程管理，该守护进程监听在 Unix socket 位于 ~/.docker/sandboxes/sandboxd.sock。 通过对该守护进程进行逆向工程，发现它暴露了三个主要端点：

  • GET /vm: 列出所有活跃的 VM
  • POST /vm: 创建一个新的 VM
  • DELETE /vm/{vm_name}: 销毁特定的 VM

隔离模型

Docker Sandboxes 中最显著的架构转变之一是 Docker daemon 的处理方式。在标准设置中，所有容器共享 /var/run/docker.sock。在沙箱模型中，每个 microVM 都有自己专用的 Docker daemon，位于 ~/.docker/sandboxes/vm/<name>/docker.sock。

这确保了在单个 microVM 中运行的容器与另一个 VM 中的容器以及与宿主机完全隔离。为了与这些 VM 交互，开发者必须使用 curl --unix-socket 或 docker --host unix://... 来覆盖 Unix socket 路径。

实现自定义工作负载

由于新的 VM 是隔离的，镜像必须手动加载到 VM 中。这可以通过构建镜像、将其归档并将其加载到 VM 的特定 socket 中来实现。

网络与 Volumes

这些 microVMs 中的网络是通过位于 host.docker.internal:3128 的过滤代理进行路由的。该代理对 HTTPS 流量执行中间人 (MITM) 操作以强制执行网络策略。对于生产环境，建议安装 VM 响应中提供的 CA 证书，而不是禁用 TLS 验证。

工作区同步是通过绝对路径处理的，允许 volume mounts 像在标准 Docker 环境中那样工作。

使用 Sandbox Agent SDK 进行编排

虽然原始的 /vm API 功能强大，但管理这些 VM 的生命周期（创建它们、加载镜像以及在失败后清理）非常复杂。为了简化这一点，Sandbox Agent SDK 被开发了出来。它封装了未公开的 API，为启动和与 AI 代理交互提供了一个统一的接口，处理流式输出和人机协作 (human-in-the-loop) 工作流。

社区观点与演进

发现此 API 引起了关于当前沙箱状态的几次技术讨论：

  • 平台支持： 虽然最初的实现侧重于 macOS 和 Windows (利用 Apple Virtualization.framework 和 Hyper-V)，但一些社区成员指出，通过 KVM 在 Linux 上实现支持是可能的，尽管 Docker Desktop 的具体实现可能会有所不同。

  • 替代工具： Podman 等工具被提及为可以在 Linux 上通过 libkrun 透明地启动 microVMs 的替代方案。

  • sbx 二进制文件： 自最初的逆向工程工作以来，Docker 已发布了 sbx，这是一个独立的 50MB 二进制文件，可以在不需要安装完整的 Docker Desktop 的情况下提供 microVM 沙箱引擎。

  • "代理问题"： 一些批评者认为，VM 隔离仅解决了 基础设施 泄露问题。他们指出，代理仍然可以通过安装受损的包或滥用访问令牌来造成危害，从而表明隔离只是更大安全拼图的一部分。

通过暴露 microVMs 的原语，Docker 为任何工作负载（不仅是白名单的 AI 代理）提供了一条通往安全、可扩展隔离的路径——有效地为沙箱技术带来了与十年前为容器技术带来的同样的革命。

Sources