刪減六成程式碼 Kata Containers 收斂稽核面
srcreigh.ca · 2026-09-19
Kata Containers 的 Firecracker 執行路徑經過一次大規模砍碼，作者把自己維護的 fork 從上游 4.2.0 版程式碼砍掉約六成，只留下 x86_64 搭配 Firecracker 的 Kubernetes 容器工作流程。這篇來自作者個人工程部落格的紀錄，詳細列出十五輪程式碼審查與刪減的過程。目標不是加新功能，而是讓 host 與 guest VM 之間的稽核面小到能一次讀完。砍完之後，host runtime 只剩 13.5k SLOC，agent 只剩 8.1k SLOC。
原本的問題
Kubernetes 預設的容器隔離仰賴 runc 之類的 namespace／cgroup 邊界，這些邊界共用同一個 host kernel，對多租戶叢集來說不是真正的安全邊界。改用 Kata Containers 的 VM 級隔離雖然把每個 pod 包進獨立的 Firecracker microVM，但 host 端的 runtime 與 guest 內的 agent 之間仍然靠 RPC 通道溝通，agent 回傳的資料一旦解析邏輯龐雜，反而變成新的攻擊面。作者引用的觀點是「VM 本身不天生等於安全邊界」，溝通通道越肥大，被惡意或已被入侵的 guest 觸發解析錯誤的機會就越大。上游 Kata 要同時支援多種 hypervisor、guest 內的 systemd／D-Bus、OCI hooks 等功能，程式碼庫龐大到難以逐行稽核，過去也曾因為 agent 傳回的資料格式異常而觸發 host 端的 runtime panic，以及網路初始化時的死結（deadlock）。
採用的方法
作者把 fork 的支援範圍收斂到單一 hypervisor 與單一情境：containerd shim v2 整合、靜態 VM CPU／RAM 配置、tcfilter 網路，guest 內 PID 1 只剩 agent 本身，並改用 hybrid-vsock 做 agent I/O。以下是主線與精簡後 fork 的支援範圍對照：
原本（Kata Containers 4.2.0 主線） 精簡後（Firecracker-only fork）
支援多種 hypervisor（QEMU、CH 等） 僅保留 Firecracker，強制 jailed+seccomp
cgroup v1 與 v2 皆支援 僅 cgroup v2
guest 內建 systemd/D-Bus、OCI hooks 移除，PID 1 僅剩 agent 行程
支援多種磁碟傳輸、profiling 僅 MMIO 磁碟傳輸，移除 profiling
host runtime／agent 完整功能集合 host 13.5k SLOC／agent 8.1k SLOC移除的功能清單裡包含以下幾類：
- 替代 hypervisor 支援與舊版 Go runtime
- kernel module 動態載入功能
- host 檔案系統共享機制
- 非 MMIO 的磁碟傳輸路徑
同時修掉了兩個實際的穩定性問題：agent 傳回異常資料時 host 端會 panic 的狀況，以及網路初始化流程裡的死結。這兩項修正都直接減少了 host runtime 在解析 guest 資料時的失敗路徑，也讓刪減後的程式碼路徑更值得信任。
實際效果
受影響的主要是跑多租戶 Kubernetes 叢集、已經用 RuntimeClass 指定 Kata 當執行時期的維運者，以及需要比 namespace 隔離更強保證的工作負載擁有者。對他們來說，可稽核的程式碼量從完整的 Kata 主線縮小到一個實際能讀完的規模，host 端因解析 guest 資料而觸發例外的路徑也變少。代價是支援範圍變窄：只能用 x86_64 搭配 Firecracker，CPU／RAM 必須靜態配置，儲存只能用 CSI volume 或唯讀的 raw volumeDevices，也拿掉了 profiling 與多 hypervisor 的彈性。要採用這條路線的維運者，需要重新盤點自己的叢集是否只依賴這個精簡後的支援矩陣，而不是上游完整的功能集合。
原始來源：Secure VMs for Kubernetes: Hardening Kata Containers、srcreigh/kata-containers fork on GitHub