容器不是沙箱：2026 年的 MicroVM 隔離現狀
emirb.github.io · 2026-03-27
Booking.com Staff SRE Emir Beganović 整理了容器安全隔離的現況：容器提供的是資源隔離（cgroup、namespace），而非安全隔離（security boundary）。Linux 核心約 4000 萬行 C 程式碼、450+ 個系統呼叫構成了容器共用的攻擊面，2024–2025 年間有八個 CVE 實證了容器逃逸的可行性（包括 "Leaky Vessels" 系列與 "NVIDIAScape"）。相對地，microVM 的 hypervisor CVE 稀少到業界懸賞 25 萬至 50 萬美元仍鮮有漏洞回報。
MicroVM 的效能現狀
「VM 太慢」的反對意見在 2026 年已不成立。Firecracker（AWS 開源）的啟動時間約為 125 毫秒，記憶體額外開銷低於 5 MiB；執行期 CPU 額外開銷為個位數百分比。相比之下，傳統 QEMU 啟動需要數秒，記憶體開銷百 MB 起跳——但這是兩種完全不同的工具。
Firecracker 對比 Cloud Hypervisor
兩者均基於 rust-vmm（由 AWS、Intel、Google、Microsoft、Red Hat 共同維護的 Rust VMM 元件庫），但設計目標不同：
- Firecracker（約 83,000 行 Rust）：極簡主義，刻意移除 GPU passthrough、巢狀 KVM、USB 等功能以縮小攻擊面。適用 AWS Lambda 這類短暫工作負載。
- Cloud Hypervisor（約 106,000 行 Rust）：保留 VFIO passthrough、巢狀虛擬化、Windows 支援。功能更豐富，但攻擊面相對較大。
rust-vmm 生態系統的意義
rust-vmm 是一組可組合的 Rust crate，提供 KVM 介面封裝（kvm-ioctls）、virtio 裝置模擬（vm-virtio）、記憶體管理（vm-memory）等元件。各 VMM 專案共用這些元件意味著：安全修補可以在整個生態系統中傳播，而不必在每個 VMM 中獨立修復相同的邏輯錯誤。
gVisor 與 microVM 的比較
gVisor（Google）採用不同路徑：以 Go 撰寫的使用者空間核心攔截系統呼叫，啟動時間約 50 毫秒，比 microVM 更快。其 GPU 隔離能力在 AI 工作負載中有特定優勢。但 gVisor 的系統呼叫相容性有缺口，Google 已將部分 Cloud Run Gen 2 工作負載從 gVisor 遷移至 microVM。
2026 年的使用場景
AI 代理程式執行不受信任程式碼的需求在短時間內推動了 microVM 採用：Fly.io Sprites、E2B、Vercel Sandbox、Docker Sandboxes 均以 microVM 為基礎。Kubernetes 整合方面，Kata Containers 提供 OCI runtime 相容介面，Edera 使用 Type-1 hypervisor，KubeVirt 將 VM 作為 Kubernetes Pod 管理。設計目標是讓開發者繼續使用熟悉的容器工作流程，底層安全邊界由硬體虛擬化強制執行。
C8s：機密 Kubernetes 叢集架構
arXiv cs.CR · 2026-04-27
arXiv:2604.26974 提出 C8s（Confidential Kubernetes），一個在 Kubernetes 叢集中提供密碼學可驗證機密性保證的架構，由 Amean Asad、Patrick McClurg、João Andrade 撰寫，論文共 47 頁。
信任模型
傳統 Kubernetes 叢集中，雲端基礎設施業者（hyperscaler operator）對工作負載具有完全的可見性：etcd 中的 secret、記憶體中的模型權重、網路傳輸的推論結果均對業者透明。C8s 的目標是建立以硬體遠端認證（attestation）為根的信任邊界，讓三類利害關係人各自獲得不同的安全保證：
- 資料擁有者：可在第三方基礎設施部署敏感工作負載，無需信任業者不窺探資料
- 運算提供者：可提供算力服務，而不需要向雲端業者披露工作負載細節
- 終端使用者：可發送請求，該請求對除受認證處理器以外的所有中間方保持不透明
技術基礎
C8s 依賴三種硬體可信執行環境（TEE）：AMD SEV-SNP（Secure Nested Paging）、Intel TDX（Trust Domain Extensions）、NVIDIA Confidential Computing（Hopper 及以上架構的 GPU TEE）。這些硬體提供記憶體加密與完整性保護，以及遠端認證（remote attestation）能力——允許第三方驗證給定的 VM 確實在真實的 TEE 硬體上運行，且執行的是未被篡改的軟體映像。
C8s 的架構設計相容於受管理的 Kubernetes 服務（Amazon EKS、Google GKE、Microsoft AKS），即使這些服務的控制平面（control plane）本身無法被認證。這是一個重要的實際考量：純粹學術的方案往往假設連控制平面都在 TEE 中，但這在商業受管理服務中不可行。
應用場景
主要面向 AI 推論（保護模型權重不被業者複製）、敏感資料上的模型訓練/微調，以及法規遵循需要資料處理地點可驗證的場景（如 GDPR 下的醫療資料）。
原始來源：arXiv:2604.26974 C8s
Grafana 13 發布：AI 代理可觀測性、建議儀表板、Git Sync GA
Grafana Blog · 2026-04-21
Grafana Labs 發布 Grafana 13，帶來多項對 AI 工作負載監控與大規模維運有實際影響的功能。所有現有儀表板在開啟後自動遷移至新的 v2 schema，無需手動操作。
AI 代理可觀測性
Grafana Cloud 新增 AI Observability 模組，提供針對 agentic 工作負載的監控解決方案。具體功能包括：追蹤 LLM API 呼叫的 token 消耗、延遲分佈、錯誤率；跨多步驟工具呼叫（tool calls）建立 trace；以及識別代理迴圈（agent loops）中的效能瓶頸。這與 OpenTelemetry 的 GenAI 語意慣例（semantic conventions）整合，可接收來自 LangChain、LlamaIndex 等框架自動埋入的遙測資料。
Grafana Assistant 與建議儀表板
Grafana Assistant 現在對開源版與 Enterprise 版使用者均開放，可執行自然語言的儀表板調整、SQL 表達式最佳化和資料分析。「建議儀表板」功能根據已連接的資料來源自動推薦相符的儀表板，對 Prometheus 提供相容性評分。
Git Sync 正式可用
Git Sync 從預覽版升至正式可用（GA），支援 GitHub App 認證（取代 Personal Access Token），並新增多平台支援（GitLab、Bitbucket）。這讓儀表板配置可以像程式碼一樣管理：版本歷史、Pull Request 審查、CI 驗證均可套用。
其他主要功能
- Grafana Advisor（GA）：自動識別失效資料來源、過期外掛、SSO 設定問題
- Graphviz 面板：將工作流程圖表（DOT 格式）連接至即時資料
- IBM DB2 資料來源（公開預覽）
- Grafana Marketplace：外掛發布平台正式上線
- 儀表板 v2 schema：面板間樣式複製貼上、每 panel 獨立資料來源選擇