2026-04-27 — K8s v1.36 User Namespaces GA、SELinux 卷軸標籤 GA、Docker Sandboxes MicroVM 架構

Kubernetes v1.36 User Namespaces GA：十年開發歷程的安全隔離里程碑

Kubernetes Blog · 2026-04-23

Kubernetes v1.36（代號 Haru）正式將 User Namespaces 支援升至 GA（General Availability），結束了從 2016 年 KEP-127 提案算起長達十年的開發歷程。此功能限 Linux 平台使用，需要 Linux 5.12+ 的核心支援（ID-mapped mounts）。

問題根源

在傳統容器模型中，容器內以 UID 0（root）執行的程序在宿主機核心層面同樣被視為 root。一旦發生容器逃逸（container escape）——無論是透過核心漏洞或錯誤設定的 mount——攻擊者即獲得宿主機完整的 root 權限。

User Namespaces 的解決方案

Linux User Namespace 將容器內的 UID/GID 映射至宿主機的非特權 UID/GID。容器內的 root（UID 0）在宿主機上對應為一個無特權的使用者帳號（如 UID 100000），核心在邊界處透明地進行 ID 轉換。

ID-Mapped Mounts 的突破

過去 User Namespaces 的最大技術障礙是 volume 掛載的效能問題：需要遞迴 chown 整個卷軸，對大型 volume（數萬個檔案）啟動延遲不可接受。Linux 5.12 引入的 ID-mapped mounts 解決了此問題：核心在掛載層面進行 UID/GID 轉換，時間複雜度為 O(1)，無需修改磁碟上的實際擁有者資訊。容器看到檔案由 UID 0 擁有；宿主機磁碟儲存原始擁有者資訊不變。

設定 API

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false   # 啟用 User Namespaces
  containers:
  - name: app
    image: fedora:42
    securityContext:
      runAsUser: 0   # 容器內以 root 執行，但宿主機無特權

無需修改容器映像，介面自 Alpha 階段起保持一致。

Capability Namespacing

設定 hostUsers: false 後，Linux Capabilities 同樣命名空間化：CAP_NET_ADMIN 僅授予容器內部網路資源的管理權，不影響宿主機網路。這使得需要特權的工作負載能在有限範圍內執行，顯著降低橫向移動（lateral movement）風險。

版本演進

版本	狀態	關鍵里程碑
v1.25	Alpha	初始支援
v1.30	Beta	擴展有狀態 Pod 支援
v1.33	Beta	預設啟用（可選退出）
v1.36	GA	穩定 API，生產就緒

原始來源：Kubernetes Blog – User Namespaces GA、KEP-127

Kubernetes v1.36 SELinux 卷軸標籤 GA：v1.37 的潛在破壞性變更

Kubernetes Blog · 2026-04-22

Kubernetes v1.36 將 SELinuxMount feature gate 升至 GA，此功能改變了在 SELinux 系統上的卷軸（volume）設定方式，大幅提升速度，但預計在 v1.37 預設開啟後將影響現有工作負載。

舊行為與問題

舊有的 SELinux 卷軸標籤方式是遞迴地在 Pod 啟動時 chcon（change context）卷軸內的所有檔案。對包含大量小檔案的卷軸（如程式碼庫、日誌目錄），此操作可造成數秒乃至數分鐘的啟動延遲，且每次 Pod 重啟都需重複執行。

SELinuxMount 的改進

SELinuxMount 功能利用 Linux 的 mount option 機制，在掛載時直接指定 SELinux context，而不是事後遞迴修改檔案。掛載選項形如 -o context="system_u:object_r:container_file_t:s0:c1,c2"，速度為 O(1)，與 volume 內容量無關。

破壞性變更風險

在 v1.37 中，SELinuxMount 預計轉為預設開啟。受影響的場景包括：使用自訂 SELinux policy 且依賴舊有 relabel 行為的工作負載；同一 volume 被多個 Pod 以不同 SELinux context 存取（新機制下可能造成 mount 衝突）；以及在非 SELinux 系統上無影響。建議在 v1.37 升級前在測試環境驗證 Pod 的 SELinux 設定。

原始來源：Kubernetes Blog – SELinux Volume Label Changes

Docker Sandboxes MicroVM 架構：AI Agent 隔離執行的設計選擇

Docker Blog · 2026-04-16

Docker Sandboxes 是 Docker 為 AI Agent 提供的隔離執行環境。在四分之一以上的生產程式碼由 AI 生成的背景下，Docker 選擇以 MicroVM 作為基礎隔離層，而非傳統容器的 namespace/cgroup 機制。

為何不用標準容器隔離

標準容器（Linux namespaces + cgroups）共享宿主機核心，攻擊面包含所有核心 syscall。AI Agent 執行任意（potentially malicious）程式碼時，核心漏洞可導致宿主機逃逸。MicroVM 運行獨立的 guest 核心，hypervisor 作為額外的隔離層。

MicroVM 技術選型

Docker Sandboxes 採用類 Firecracker 的 MicroVM 技術：毫秒級啟動時間（cold start <150ms）；最小化 VMM（Virtual Machine Monitor）攻擊面，去除傳統虛擬機的 BIOS、USB 控制器等遺留裝置；每個 Sandbox 擁有獨立的 guest kernel，即使 guest 核心被利用也不影響宿主機。

與容器生態的整合

從使用者視角，Docker Sandboxes 保持與標準容器相同的 API 介面（Docker CLI、Docker Compose），底層 MicroVM 透明化。映像格式維持 OCI 標準，現有工具鏈無需修改。

原始來源：Docker Blog – Why MicroVMs: The Architecture Behind Docker Sandboxes

End of article