從 Docker Container 共享 Kernel 風險談 AI 時代的 MicroVM 沙盒演進

English Abstract: Running an autonomous AI agent with --dangerously-skip-permissions inside a standard docker run container is not a security sandbox. Every runc-based container shares the host Linux kernel, so a runtime flaw such as runc CVE-2025-52881, a mounted docker.sock, or API keys passed in with -e can turn one misbehaving agent loop into a host-level incident. This post contrasts standard containers with MicroVM sandboxes, walks through a Docker Sandboxes (sbx) setup with a separate guest kernel, deny-by-default egress policy and host-side credential proxying, shows how to verify each isolation layer, and closes with a two-phase governance model that moves agentic workloads in Kubernetes onto Kata Containers or gVisor through RuntimeClass.

傳統容器 vs. MicroVM 沙盒：在 AI Agent 時代，重新定義容器隔離與 Proxy 憑證防護

本文重點大綱

傳統 Container 與 MicroVM Sandbox 的本質差異：從 Linux Kernel 共用與否，切開「確定性微服務」與「非確定性 AI Agent」的執行邊界。

實務風險拆解：從 runC 漏洞（CVE-2025-52881）到環境變數外洩：分析為何 --dangerously-skip-permissions 搭配傳統 docker run 會在正式環境引發系統級災難。

多層級配置實作（延續 Docker Proxy 脈絡）：示範如何利用 Docker sbx（MicroVM Sandbox）的獨立 Kernel、L7 Network Policy 與 Credential Proxy，實現「金鑰不進容器」的零信任防護，並逐層驗證設定是否生效。

兩階段治理決策框架：為企業團隊提供從「本地端開發隔離」到「CI/CD 與生產環境 Runtime 升級」的實踐路徑，附 Kubernetes RuntimeClass 與 FQDN Egress 設定範例。

在導入 AI 輔助開發與自動化維運（AIOps）的過程中，越來越多工程團隊開始在工作流中部署具備自主執行能力的 AI Agent（例如 Claude Code、各類 Coding Agent 或自動化排障代理程式）。為了讓 Agent 能夠順暢地執行編譯、安裝套件與修改系統設定，開發者往往會在啟動指令加上 --dangerously-skip-permissions，並認為：「只要把 Agent 放在 Docker Container 裡面跑，就算執行過程出錯，把容器刪除重建就能確保主機安全。」

這正是將「傳統微服務時代的防禦假設」套用到「AI Agent 時代」的典型誤區。

在面對會動態生成程式碼並自行呼叫 Shell 的 AI Agent 時，我們必須重新審視 傳統容器（Standard Container） 與 微型虛擬機沙盒（MicroVM Sandbox） 在架構本質上的差異。

（一）Container vs. Sandbox

傳統 Docker Container 容器的設計初衷，是為了打包並執行行為已知、邏輯確定（Deterministic）的應用程式。無論是 Go 編譯出的執行檔或 Python Web API，其系統呼叫（System Calls）與網路連線行為在通過 CI/CD 測試後就已經固定。

然而，AI Agent 的運作本質是一個高不確定性（Non-deterministic）的控制迴圈（Control Loop）。當我們賦予 AI Agent 執行 bash 指令與讀寫檔案的權限時，它在容器內的行為等同於一名擁有系統權限的外部操作人員。

要理解為什麼傳統容器無法有效隔離這類行為，必須回到 Linux 容器的底層架構：

Namespaces（命名空間）：負責隔離視角（決定行程看得到哪些 PID、Mount 點與網路介面）。
Control Groups (cgroups)：負責限制資源配額（決定行程最多能使用多少 CPU 與記憶體）。
共用宿主機核心（Shared Host Kernel）：這是傳統容器最關鍵的架構特徵。無論 Namespaces 切分得多麼精細，所有預設使用 runc 作為 Runtime 的容器，底層全部直接向同一個宿主機的 Linux Kernel 發出系統呼叫。

以下命令行範例簡單測試便能確認：在宿主機與任何一個傳統容器內分別執行 uname -r，兩者回報的 Kernel 版本完全相同。

# 宿主機的 Kernel 版本
uname -r
# 6.8.0-45-generic

# 傳統容器內看到的 Kernel 版本——與宿主機完全相同，因為根本是同一個 Kernel
docker run --rm alpine uname -r
# 6.8.0-45-generic

架構比較維度	傳統容器（`docker run` / `runc`）	MicroVM 沙盒（`sbx` / Kata / Firecracker）	對 AI Agent 維運的實質影響
設計目標	封裝已知的確定性微服務，追求高密度與快速啟動	隔離不可信或動態生成的程式碼，追求強安全邊界	決定系統能否承受 Agent 執行未知腳本的風險
隔離層級	作業系統行程級別（OS Process Level）	硬體虛擬化級別（Hardware Virtualization / KVM）	阻斷透過 Kernel Syscall 漏洞進行的系統突破
Linux Kernel	與宿主機共用同一個 Kernel	每個沙盒擁有獨立的 Guest Kernel	即使 Agent 觸發 Kernel Panic，也不會波及宿主機
Docker Daemon	共用宿主機 Daemon（常需掛載 `docker.sock`）	沙盒內建完全獨立的私有 Docker Engine	Agent 可在沙盒內安全執行 `docker build` 而不影響外部
網路與憑證控制	預設 Bridge 全通，常以環境變數 `-e` 傳遞金鑰	內建 L7 網域白名單與外部 Proxy 憑證動態注入	防止 Agent 遭誘導後將環境變數中的 API Key 外洩

圖：傳統容器與 MicroVM 沙盒的隔離邊界對照

（二）風險分析：當自主迴圈遇上 Kernel 漏洞與憑證暴露

在正式環境或開發機上直接使用傳統 docker run 執行 AI Agent，主要面臨三大架構風險：

1. 容器逃逸風險（以 `runC` CVE-2025-52881 為例）

由於共用 Kernel 與底層 Runtime，一旦容器執行環境存在漏洞，具備檔案讀寫與程式執行能力的 Agent 就可能突破隔離邊界。

以 2025 年 11 月揭露的高風險漏洞 CVE-2025-52881（CVSS v4.0 7.3，High） 為例，該漏洞源自 runc 在處理 /proc（procfs）寫入操作時存在的 Symbolic Link 競爭條件（Race Condition）。當容器內部能夠操作共享掛載點時，可透過抽換符號連結，將原本要寫入 AppArmor 安全標籤或 sysctl 參數的操作，重新導向至宿主機的 /proc 敏感檔案，進而繞過安全限制並取得宿主機控制權。官方 Advisory 也特別註明，docker buildx build 同樣可能觸發此攻擊路徑——對會自行打包映像檔的 Agent 而言，這不是理論上的風險。

在 AI Agent 場景中，這不一定需要人為惡意攻擊。當 Agent 讀取外部套件、解析第三方 Log 或處理 GitHub Issue 時，若遭遇間接提示詞注入（Indirect Prompt Injection），就可能在自動化迴圈中下載並執行惡意腳本，直接觸發底層漏洞。

受影響版本為 runc 1.2.8、1.3.3、1.4.0-rc.3 之前的各分支版本。先確認宿主機目前使用的 runc 版本：

# 直接查詢 runc 版本
runc --version

# 或透過 Docker Engine 列出各元件版本（找 runc 那一行）
docker version --format '{{range .Server.Components}}{{.Name}}: {{.Version}}{{"\n"}}{{end}}'
# Engine: 28.5.1
# containerd: v1.7.28
# runc: 1.3.3      <- 需為 1.2.8 / 1.3.3 / 1.4.0-rc.3 以上

升級 runc 只能關閉「這一個」漏洞。只要架構仍是共用 Kernel，下一個 Runtime 或 Kernel 漏洞出現時，同樣的風險會再次出現——這正是後文要改用獨立 Guest Kernel 的根本原因。

2. 掛載 `docker.sock` 的權限失控

有些人曾想到，為了讓 AI Agent 能夠自行建立測試容器或打包映像檔，會在啟動時加上 -v /var/run/docker.sock:/var/run/docker.sock。在 Docker 架構下，擁有 docker.sock 的讀寫權限等同於擁有宿主機的 root 權限。Agent 只要在迴圈中執行一道掛載宿主機根目錄的指令，整個隔離機制即形同虛設。

盤點目前主機上有哪些容器掛載了 docker.sock：

# 列出所有掛載 docker.sock 的執行中容器
docker ps -q | xargs -r docker inspect \
  --format '{{.Name}}{{range .Mounts}} {{.Source}}{{end}}' \
  | grep docker.sock
# /legacy-agent-container /home/dev/project /var/run/docker.sock

3. 環境變數中的金鑰外洩（Secrets in Environment Variables）

過去習慣透過 docker run -e OPENAI_API_KEY=... 或 -e GITHUB_TOKEN=... 將憑證傳入容器。然而，AI Agent 在執行除錯或環境檢查時，極易將環境變數傾印（Dump）至日誌中，或受惡意指令誘導，透過 curl 將環境變數直接發送至外部伺服器。

除此之外，以 -e 傳入的值會以明文寫入容器的設定中，任何能執行 docker inspect 的使用者都讀得到：

# 不需要進入容器，就能直接讀出啟動時傳入的金鑰
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' legacy-agent-container \
  | grep -E 'API_KEY|TOKEN'
# ANTHROPIC_API_KEY=sk-ant-api03-real-production-key
# GITHUB_TOKEN=ghp_real_production_token

（三）當前實務配置：結合 MicroVM 與 Proxy 憑證隔離

過去在規劃企業內部網路的 Docker Proxy 配置時，必須分別針對 Docker Daemon、Docker Client 與 Container 設定不同的代理伺服器環境變數。

到了 AI Agent 時代，Docker 官方正式將這套隔離與代理概念全面升級，推出基於 MicroVM 架構的 Docker Sandboxes（sbx CLI）。它不僅透過硬體虛擬化為每個沙盒提供獨立的 Linux Kernel 與獨立的 Docker Daemon，更將 Proxy 的角色從單純的「流量轉發」，升級為「憑證代理注入（Credential Proxying）」與「L7 網域白名單控制」。

以下對照傳統高風險作法與現代標準沙盒配置的具體差異：

1. 傳統高風險配置（不建議用於 AI Agent）

# 風險點：
# 1. 共用宿主機 Kernel (預設 runc)
# 2. 掛載 docker.sock 導致宿主機 Root 權限暴露
# 3. 真實 API Key 與 Token 直接以明文存在於容器環境變數中
docker run -it --rm \
  --name legacy-agent-container \
  -v $(pwd):/workspace \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e ANTHROPIC_API_KEY="sk-ant-api03-real-production-key" \
  -e GITHUB_TOKEN="ghp_real_production_token" \
  my-agent-env:latest \
  claude --dangerously-skip-permissions

2. 現代 MicroVM 沙盒與 Proxy 隔離配置（推薦實踐）

透過 sbx，我們將架構拆分為「宿主機控制層（Host Proxy & Hypervisor）」與「沙盒執行層（MicroVM Guest）」：

第一步：於 Linux 環境啟用 KVM 與安裝 sbx

# 確認系統支援 KVM 虛擬化（應出現 kvm_intel / kvm_amd / kvm 等模組）
lsmod | grep kvm

# 將當前使用者加入 kvm 群組
sudo usermod -aG kvm $USER && newgrp kvm

# 加入 Docker 官方套件庫（僅設定 repo，不安裝 Docker Engine）後安裝 sbx
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get update && sudo apt-get install -y docker-sbx

# 以 Docker 帳號登入（會開啟瀏覽器進行 OAuth）
sbx login

官方目前支援的 Linux 平台為 Ubuntu 24.04 以上（x86_64 / arm64）；若宿主機本身是 VM 或 VDI，必須開啟巢狀虛擬化（Nested Virtualization）。macOS 與 Windows 的安裝方式請參考官方文件，版本細節請依實際環境調整。

第二步：配置出站網路策略（Network Policy）

不再允許容器預設連往任意外部 IP，而是採用預設攔截或平衡策略，僅放行必要的官方 API 與套件庫網域：

# 初始化預設網路策略（本機首次啟動沙盒前必須執行一次）
sbx policy init balanced

# 明確指定允許連線的外部網域
sbx policy allow network api.anthropic.com
sbx policy allow network api.openai.com
sbx policy allow network registry.npmjs.org

# 檢視目前生效的所有規則
sbx policy ls

balanced 本身已放行常見的 AI 服務與套件庫，上面的 allow 規則用途是把 Agent 實際需要的網域「明文宣告」在團隊的設定腳本中。官方文件也提醒，預設允許清單包含 *.googleapis.com 這類範圍很廣的萬用字元，正式導入前應以 sbx policy ls 逐條檢視。要求更嚴格的團隊可改用 sbx policy init deny-all，再逐一 allow 必要網域；init 只能執行一次，若要切換模式需先執行 sbx policy reset。

第三步：配置 Proxy 憑證注入（真實金鑰不進沙盒）

這是延續 Docker Proxy 架構最核心的安全機制。我們將真實憑證交由宿主機端的 Sandbox Proxy 保管，沙盒內部只會看到一組代用字串（Placeholder）。當沙盒內的 Agent 發出請求時，必須經過 Proxy 檢查目標網域合法後，才會在網路傳輸層動態替換為真實的 Authorization Header：

# 由 Host 端動態取得 GitHub Token 並註冊至 Sandbox Proxy
# 沙盒內的 Agent 執行 env 時，絕對看不到真實的 Token 內容
sbx secret set github --command 'gh auth token'

# 從宿主機既有的環境變數，經由 stdin 傳給 Sandbox Proxy（不會留在 shell history）
echo "$ANTHROPIC_API_KEY" | sbx secret set anthropic

# 若團隊使用 1Password，也可以只存參照，不透露明文內容
# sbx secret set anthropic --ref 'op://Private/Anthropic/api-key'

# 確認已註冊的憑證（只列服務名稱，不顯示值）
sbx secret ls

第四步：啟動具備獨立 Kernel 與 Git Clone 隔離的沙盒

# 以 clone 模式啟動 MicroVM 沙盒：Agent 只在沙盒內的私有 Git clone 上工作
# 宿主機的 repo 在沙盒內僅以唯讀方式出現於 /run/sandbox/source
# 確保 Agent 連主分支 (main) 的本地檔案都無法直接覆寫
cd ~/projects/myrepo
sbx run --clone claude .

沙盒名稱預設為 <agent>-<工作目錄名稱>，以上例而言就是 claude-myrepo。Agent 在沙盒內建立 feat/automated-refactoring 分支並提交後，變更只存在於沙盒內；需要時再由宿主機主動取回審查：

# 從沙盒取回 Agent 的分支，在宿主機端審查後才決定是否合併
git fetch sandbox-claude-myrepo
git diff main..sandbox-claude-myrepo/feat/automated-refactoring
git checkout -b feat/automated-refactoring sandbox-claude-myrepo/feat/automated-refactoring

--clone 只能在建立沙盒時指定，無法事後加到既有沙盒。若團隊偏好由人在宿主機端掌握 commit，也可以改用 host worktree 模式：先 git worktree add -b feat/automated-refactoring ../myrepo-refactor，再以 sbx run claude ../myrepo-refactor 啟動；此模式下 Agent 只能改檔案，不能 commit。

第五步：逐層驗證隔離是否生效

設定完成後，不要只看沙盒「跑得起來」就結束，應逐層確認每一道防線確實存在：

# 1. Kernel 隔離：沙盒內回報的 Kernel 版本應與宿主機不同
uname -r
sbx exec claude-myrepo uname -r

# 2. 憑證代理：沙盒內不應出現任何真實金鑰（最多只看得到 sentinel 代用值）
sbx exec claude-myrepo env | grep -i -E 'anthropic|github|token'

# 3. Docker Daemon 隔離：沙盒內的 docker ps 看不到宿主機上的任何容器
docker ps --format '{{.Names}}'
sbx exec claude-myrepo docker ps --format '{{.Names}}'

# 4. 網路策略：允許清單內的網域應為 allow，未列入的網域應被阻擋
sbx policy check network api.anthropic.com
sbx policy check network exfil.example.net

# 5. 實際流量紀錄：確認 Agent 連過哪些主機、哪些被 Proxy 擋下
sbx policy log claude-myrepo --limit 20

第 2 項是最容易被忽略的檢查：如果在沙盒的 env 輸出中看到 sk-ant- 或 ghp_ 開頭的真實值，代表有人仍在用 sbx run -e 直接把金鑰傳進沙盒，等於繞過了第三步的 Credential Proxy。

（四）如何依場景選擇隔離機制？兩階段治理策略

架構師在企業內部導入 AI Agent 結合容器化工作流時，不需要將所有服務一刀切地全部改為虛擬機，而是應該根據「程式碼的可預測性」建立兩階段的防禦邊界：

第一階段：開發端與自主型 AI Agent ── 強制採用 MicroVM 與 Proxy 憑證分離

適用場景：開發人員本地端執行 AI Coding Agent、自動化安全測試 Agent、或需要動態執行未知腳本的 AIOps 任務。
治理準則：
1. 硬體級核心隔離：本地與測試環境全面使用 sbx（基於 KVM / Hypervisor 的 MicroVM），確保單一 Agent 失控時不會影響宿主機與其他專案。
2. 零信任憑證代理：嚴禁在 Agent 容器的 .env 或啟動參數中寫入真實的雲端金鑰（AWS/GCP Credentials）與資料庫密碼，全面改由外部 Egress Proxy 或 API Gateway 進行身分驗證注入。

第二階段：Kubernetes 生產環境叢集 ── 導入 RuntimeClass 分流治理

適用場景：當 AI Agent 通過驗證，需要部署至生產環境的 Kubernetes 叢集長期提供服務時。
治理準則：
1. 一般確定性微服務（Standard Workloads）：維持使用預設的 runc Runtime，保留傳統容器高密度、低資源耗損的優勢。
2. AI Agent 與高風險動態工作負載（Untrusted / Agentic Workloads）：在 K8s 中配置專屬的 RuntimeClass，指定使用 Kata Containers（runtimeClassName: kata） 或 gVisor（runtimeClassName: gvisor），並搭配 Cilium 等 CNI 實作嚴格的 FQDN Egress 網路白名單，搭配 Linux cgroups 與 pids-limit 限制最大行程數，為失控迴圈建立物理級的熔斷防線。

以下是第二階段的最小可用設定。前提是節點的 containerd 已安裝 Kata Containers（或 gVisor 的 runsc），handler 名稱需與 containerd 設定中的 runtime 名稱一致，請依實際安裝方式調整：

# runtimeclass.yaml：宣告兩種隔離 Runtime
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata          # 依 kata-deploy 安裝結果，可能是 kata-qemu / kata-clh 等
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
# ai-agent.yaml：只有 Agent 工作負載指定 runtimeClassName，一般微服務維持預設 runc
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-agent
  namespace: agents
spec:
  replicas: 1
  selector:
    matchLabels: { app: ai-agent }
  template:
    metadata:
      labels: { app: ai-agent }
    spec:
      runtimeClassName: kata
      automountServiceAccountToken: false
      containers:
        - name: agent
          image: registry.example.com/platform/ai-agent:1.4.2
          resources:
            requests: { cpu: "500m", memory: "1Gi" }
            limits:   { cpu: "2",    memory: "4Gi" }
          securityContext:
            allowPrivilegeEscalation: false
            runAsNonRoot: true

FQDN Egress 白名單以 Cilium 為例，必須同時放行 DNS 查詢，Cilium 才能把網域解析結果對應到允許的 IP：

# ai-agent-egress.yaml：Agent 只能連往 DNS 與指定的 API 網域
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: ai-agent-egress
  namespace: agents
spec:
  endpointSelector:
    matchLabels: { app: ai-agent }
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports: [{ port: "53", protocol: ANY }]
          rules:
            dns: [{ matchPattern: "*" }]
    - toFQDNs:
        - matchName: api.anthropic.com
        - matchName: api.github.com
      toPorts:
        - ports: [{ port: "443", protocol: TCP }]

行程數上限則由 kubelet 統一控管，在 KubeletConfiguration 中設定 podPidsLimit（例如 podPidsLimit: 1024），避免失控迴圈以 fork 耗盡節點資源。套用後以下列指令驗證：

# 1. 確認 Pod 確實以 kata 執行
kubectl -n agents get pod -l app=ai-agent \
  -o jsonpath='{.items[0].spec.runtimeClassName}{"\n"}'

# 2. Kernel 隔離：Pod 內的 Kernel 版本應與節點不同（gVisor 會回報其模擬的版本）
kubectl -n agents exec deploy/ai-agent -- uname -r
kubectl get node <node-name> -o jsonpath='{.status.nodeInfo.kernelVersion}{"\n"}'

# 3. Egress 白名單：允許網域應回應，未列入的網域應逾時
kubectl -n agents exec deploy/ai-agent -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.anthropic.com
kubectl -n agents exec deploy/ai-agent -- curl -sS -m 5 https://example.com || echo "blocked as expected"

將不可預測的 AI 放進為確定性程式設計的傳統容器裡，本身就是一種架構上的錯置。透過 MicroVM 重建 Kernel 隔離邊界，並運用 Proxy 機制收回憑證控制權，我們才能在安全可控的前提下，真正釋放 AI Agent 在自動化維運與軟體工程中的生產力。

常見問題（FAQ）

把 AI Agent 放在 Docker 容器裡再加上 --dangerously-skip-permissions，主機就安全了嗎？

不安全。以 runc 執行的傳統容器與宿主機共用同一個 Linux Kernel，Namespaces 與 cgroups 只隔離視角與資源配額。Agent 一旦觸發 runc 或 Kernel 漏洞（例如 CVE-2025-52881）、取得掛載進來的 docker.sock，或把 -e 傳入的金鑰送出，影響範圍就是整台宿主機，刪除容器也無法撤回已外洩的憑證。需要讓 Agent 自主執行指令時，應改用擁有獨立 Guest Kernel 的 MicroVM 沙盒，例如 Docker Sandboxes（sbx）。

runc 已經升級到修補版本，還需要改用 MicroVM 沙盒嗎？

需要。升級到 runc 1.2.8、1.3.3 或 1.4.0-rc.3 以上只修補了 CVE-2025-52881 這一個漏洞，共用 Kernel 的架構沒有改變，下一個 Runtime 或 Kernel 漏洞出現時風險會再次出現。對於會執行未知腳本的 AI Agent，獨立 Guest Kernel 才是結構性的隔離；runc 升級仍應照常進行，但兩者是不同層次的防線。

sbx 沙盒裡執行 env 看不到 API Key，Agent 為什麼還能正常呼叫 API？

這是 Credential Proxy 的設計。以 sbx secret set 註冊的憑證保存在宿主機端，沙盒內的 Agent 只會看到 sentinel 代用值；請求離開 MicroVM、經過 Host Proxy 檢查目標網域符合網路策略後，Proxy 才把代用值替換成真實憑證。若在沙盒的 env 輸出中看到 sk-ant- 或 ghp_ 開頭的真實值，代表金鑰是以 sbx run -e 直接傳入，等於繞過了 Credential Proxy。

Kubernetes 設定 runtimeClassName: kata 之後，Pod 卡在 ContainerCreating 怎麼檢查？

先執行 kubectl describe pod 查看事件，常見訊息是 no runtime for "kata" is configured，代表節點的 containerd 沒有名稱相符的 runtime handler。確認 RuntimeClass 的 handler 與 containerd 設定中的 runtime 名稱一致（kata-deploy 常見名稱為 kata-qemu 或 kata-clh），並確認 Pod 被排程到已安裝 Kata 的節點，必要時在 RuntimeClass 的 scheduling.nodeSelector 指定節點標籤。節點本身若是雲端 VM，還需要支援巢狀虛擬化。

搜尋此網誌

Autocruise