獨立的 Docker Sandboxes 專門運行 Agent 的隔離環境

完整介紹 Docker Sandboxes 的 microVM 隔離架構，比較 Docker container 與 sandbox 的差異，並實作安裝、Claude Code 啟動與 network policy 設定。

CChia1104
文章7 分鐘閱讀

最近看到 Docker 多了個 Sandboxes 的功能，主要讓開發者可以在隔離的環境中快速執行 AI 產生的程式碼，避免直接跑在本機造成安全風險。

docker-sbx-claude

Kernel 差異

過去剛碰 Docker 時一直以為他是個 完全獨立 的輕量級虛擬機，跟真正的虛擬機（VM）差不多，並以為只是速度比較快、佔用資源比較少而已。

後來才知道， Container 其實是共用 Host 的 Kernel 的，不像傳統 VM 那樣完整模擬一整套硬體與作業系統，這也是為什麼 Docker 啟動速度快、資源消耗低，但相對地隔離性也沒有真正的 VM 來得徹底。

而今天要講的 Docker Sandboxes 正是為了彌補這種隔離性不足的問題而生的，它讓 Agent 產生的程式碼可以在真正獨立的環境中執行，即使程式碼想要存取或破壞系統，也不會影響到 Host 本身。

一般 Docker container 的隔離主要仰賴 Linux namespaces 與 cgroups，並共享宿主 kernel；Docker Sandboxes 則將 agent 放進具獨立 kernel 的 microVM，隔離邊界提升至 hypervisor／VM 層級。這也降低 agent 在取得 Docker 操作能力時，因掛載 /var/run/docker.sock 而間接控制主機 Docker daemon 的需求與風險。

層面一般 Docker containerDocker Sandboxes
Kernel與宿主共享每個 sandbox 有自己的 kernel
Docker daemon常與主機共用，或需掛載 Docker socketsandbox 內有私有 daemon
docker build／run可用，但若要控制主機 Docker 通常需提高權限可在 sandbox 內直接使用
隔離邊界OS／container 層Hypervisor／microVM 層
Agent 失控影響視 mount、capabilities、socket 等設定而定主要限縮在該 microVM 與明確授權資源內

檔案怎麼進出

Sandbox 不是直接看見你的整顆硬碟。它只會拿到你明確分享進去的 workspace；agent 對該 workspace 的修改，會同步反映到主機專案目錄。相對地，agent 在 sandbox 內安裝的套件、建立的 image、container 與其他內部狀態，都保留在 sandbox 自己的環境中，而非主機 Docker 環境。

microVM 保護的是未被分享的主機資源，不會自動保護你主動掛進去的 repository。因此不要把家目錄、SSH key、雲端憑證或含機密的 .env 不加篩選地帶進 workspace。

安裝設定

這裡先以 macOS 為例，流程採「安裝 → 登入 → 啟動 → 管理 → 設定網路」：

# 安裝 sbx CLI
brew trust docker/tap
brew install docker/tap/sbx

# 登入 Docker 帳號，首次設定網路 policy
sbx login

# 在專案目錄啟動 Claude Code
cd ~/workspace/my-app
sbx run --name my-app claude

接著提供最常用的生命周期指令：

# 查看 sandbox
sbx ls

# 停止但保留環境內容
sbx stop my-next-app

# 刪除 sandbox 與其內部狀態
sbx rm my-next-app

# 查看網路規則
sbx policy ls

網路 Policy

在運行 sbx 之前要先設定網路 Policy，他是控制 sandbox 裡的 agent 能連到哪裡，而不是單純決定它是否有網路。這是針對對外連線（egress）的白名單／拒絕規則：即使 agent 執行了指令、安裝了依賴或被 prompt injection 誘導，也只能把資料或請求送到被允許的目標。

Docker Sandboxes 的網路 policy 由 policy 與 rule 組成：

  • Policy：一組具名規則集合，例如「本機前端開發」或「受限 CI」。
  • Rule：一條具體的存取規則，由動作、目標與決策構成。
  • 動作：例如 connect:tcp 與 connect:udp。
  • 目標：網域名稱、CIDR 網段或特定連接埠。
  • 決策：allow 或 deny。

Sandbox 的對外流量會經由主機上的 HTTP／HTTPS proxy，proxy 根據 policy 對每個外送請求套用規則。非 HTTP 的 TCP 流量，例如 SSH，可針對 IP 與 port 額外開放；UDP 和 ICMP 則在網路層被阻擋，不能靠 policy 放行。

三種預設策略

docker-sbx-policy

首次啟動 sandbox，或執行 sbx policy reset 時，需要選擇一種預設策略：

策略行為適合情境
Open所有對外流量都允許，等同有萬用 allow 規則快速實驗、短暫除錯；不建議用於有機密的 repo
Balanced預設拒絕，但內建開放常用 AI API、套件管理器、程式碼代管、容器 registry 與部分雲端服務大多數日常 agent 開發的起點
Locked Down所有流量都阻擋，連 LLM provider API 也一併阻擋高敏感 repo、企業環境、需要明確審核每個網域時

查看目前規則：

sbx policy ls

全機器的所有 sandbox 預設都會套用你建立的規則：

# 讓 sandbox 可安裝 npm 套件
sbx policy allow network "*.npmjs.org"

# 讓 sandbox 可 clone、fetch 與 push GitHub repository
sbx policy allow network "github.com,api.github.com"

# 明確封鎖不該存取的網域
sbx policy deny network "example-tracker.com"

若規則只該給某個 sandbox，用 --sandbox 限縮範圍，避免把例外變成全域權限：

sbx policy allow network \
  --sandbox frontend-agent \
  "api.example.com"

Claude Code 使用

起初我們先指定到我們要運行的 workspace，一開始會先在 microVM 中拉取 claude 的 base image

docker-sbx-claude

# 在專案目錄啟動 Claude Code
cd ~/workspace/my-app
sbx run --name my-app claude

不過由於這是新的獨立環境，我們在每個 sandbox 中都需要針對對應的 Agent 做設定，包含登入、skills、MCP 等設定都需要重新匯入

docker-sbx-claude-tools

雖然這樣相對麻煩些，但也是最乾淨且獨立的運行環境了。

Written by: Chia1104 CC BY-NC-SA 4.0

頁面

聯絡

Chia1104
©
Chia1104