解鎖 Docker Sandboxes：逆向工程分析未公開的 MicroVM API

多年來，Docker containers 一直是後端部署的業界標準。然而，隨著 AI coding agents（如 Claude Code、Codex 和 Gemini）的興起，對執行任意、不可信程式碼的需求日益增加，標準 containers 的限制也變得顯而易見。Containers 與主機共享核心（kernel），這意味著受損的 container 可能會危及整個主機。

為了應對這一點，Docker 推出了 "Docker Sandboxes"，這是一個專為 AI agent 安全性設計的解決方案。雖然 Docker 為少數白名單 agents 提供有限的 CLI，但他們悄悄地發布了一個未公開的 API，用於啟動 microVMs。此 API 提供了一種 containers 無法提供的隔離層級，有效地為執行不可信程式碼建立了 "gold standard"。

Containers vs. MicroVMs：安全性差距

要理解為什麼 Docker 將沙盒功能轉向 microVMs，必須區分這兩種技術。Containers 使用 namespaces 和 cgroups 來提供隔離，但因為它們與主機核心共享，因此容易受到核心層級的漏洞攻擊。

相比之下，MicroVMs 為每個實例提供獨立的核心。它們比傳統的虛擬機器（VMs）輕量得多，但提供了 VM 的安全性配置。這種架構對於無法信任執行中的程式碼的工作負載至關重要，例如使用者提交的腳本或多租戶插件。

比較概覽

Feature Docker Container Docker Sandbox
Security Shared kernel (namespaces) Separate kernel (microVM)
Untrusted Code Not safe Safe
Network Access Direct HTTP Via filtering proxy
Volumes Direct mount Bidirectional file sync
Platform Linux, macOS, Windows macOS, Windows only (initially)

逆向工程分析 sandboxd API

Docker 的沙盒功能由 sandboxd daemon 管理，該 daemon 在 Unix socket 於 ~/.docker/sandboxes/sandboxd.sock 進行監聽。透過對此 daemon 進行逆向工程，發現它暴露了三個主要的端點（endpoints）：

  • GET /vm: 列出所有啟動中的 VMs
  • POST /vm: 建立新的 VM
  • DELETE /vm/{vm_name}: 銷毀特定的 VM

隔離模型

Docker Sandboxes 中最重要的架構轉變之一是 Docker daemon 的處理方式。在標準設置中，所有 containers 共享 /var/run/docker.sock。在沙盒模型中，每個 microVM 都擁有自己專用的 Docker daemon，位於 ~/.docker/sandboxes/vm/<name>/docker.sock。

這確保了在一個 microVM 中運行的 containers 與另一個 VM 中的 containers 以及主機完全隔離。為了與這些 VMs 互動，開發者必須使用 curl --unix-socket 或 docker --host unix://... 來覆寫 Unix socket 路徑。

實作自定義工作負載

由於新的 VMs 是隔離的，因此必須手動將 images 加載到 VM 中。這可以透過建立 image、將其封存，然後將其加載到 VM 的特定 socket 中來實現。

網路與 Volumes

這些 microVMs 中的網路是透過位於 host.docker.internal:3128 的過濾代理（filtering proxy）進行路由。此代理對 HTTPS 流量執行中間人攻擊（MITM）操作，以強制執行網路策略。對於生產環境，建議安裝 VM 回應中提供的 CA certificate，而不是禁用 TLS 驗證。

工作空間同步是透過絕對路徑處理的，這使得 volume mounts 可以像在標準 Docker 環境中一樣運作。

使用 Sandbox Agent SDK 進行編排

雖然原始的 /vm API 功能強大，但管理這些 VMs 的生命週期（建立它們、加載 images、以及在失敗後進行清理）非常複雜。為了簡化這一點，Sandbox Agent SDK 被開發出來。它封裝了未公開的 API，為啟動和與 AI agents 互動提供了一個統一的介面，並處理串流輸出和人機協作（human-in-the-loop）工作流。

社群觀點與演進

此 API 的發現引發了關於目前沙盒化狀態的幾項技術討論：

  • Platform Support: 雖然最初的實作是在 macOS 和 Windows（利用 Apple Virtualization.framework 和 Hyper-V），但一些社群成員指出，透過 KVM，Linux 支援是可能的，儘管 Docker Desktop 的特定實作可能會有所不同。

  • Alternative Tools: Podman 等工具被提及為可以在 Linux 上透過 libkrun 透明地啟動 microVMs 的替代方案。

  • The sbx Binary: 自從最初的逆向工程工作之後，Docker 已發布了 sbx，這是一個獨立的 50MB 的 binary，可以在不需要完整安裝 Docker Desktop 的情況下提供 microVM sandbox engine。

  • The "Agent Problem": 一些批評者認為，VM 隔離僅解決了基礎設施入侵問題。他們指出，agents 可以透過安裝受損的 packages 或濫用 access tokens 來造成傷害，因此建議隔離只是更大安全謎題的一部分。

透過暴露 microVMs 的原語（primitives），Docker 為任何工作負載（不僅僅是白名單的 AI agents）提供了一條通往安全、可擴展隔離的道路——有效地將十年前為 containers 帶來的革命帶入到沙盒化領域。

Sources