Kubernetes命名空間提供邏輯分區而非運行時隔離，這在多租戶和AI工作負載中構成安全風險。僅依賴命名空間不足以抵御攻擊，真正的隔離需強化運行時和輕量級虛擬化。

譯自：Beyond Namespaces: Why Kubernetes Needs Real Workload Isolation[1]

作者：Lewis Denham-Parry

Kubernetes 命名空間是平臺工程師工具包中最熟悉的工具之一。在 The New Stack 發表的一篇文章[2]中，命名空間被視為實現容器隔離的分步指南，這種觀點反映了許多團隊目前使用它們的方式。

然而，“隔離”這個詞在這種框架下承擔了過多的含義。命名空間提供了邏輯上的分離，但它們無法強制執行那種強化的邊界[3]，能夠阻止工作負載在運行時相互干擾。

這種區別不僅僅是語義上的——它關乎架構。在當今多租戶集群、AI驅動工作負載和GPU共享的世界中，這種區別決定了你的集群能否抵御入侵，還是像紙牌屋一樣崩潰。

命名空間是分區，而非隔離

命名空間為開發者和運維人員提供了一種優雅的抽象：它們允許多個團隊或租戶共享一個集群，而不會相互踩踏資源。它們強制執行配額，啟用基于角色的訪問控制（RBAC），并允許更清晰地劃定策略范圍。這對于減少管理混亂是無價的。

但命名空間并未改變所有運行在同一節點上的容器共享同一個內核這一基本事實。一個命名空間中受損的容器仍然有可能攻擊內核，利用共享設備或窺探GPU內存，因為內核本身就是共享表面。

Amber Wolf 關于命名空間邊界的文章[4]通過真實世界的例子強調了這一點。當租戶管理員被賦予完整的命名空間控制權時，他們通常仍保留影響整個集群的途徑。紅隊經驗表明，命名空間邊界在壓力下無法堅守。它們是策略結構，而非安全屏障。

這種區別之所以重要，是因為我們經常談論命名空間和隔離，仿佛它們可以互換。它們不能。命名空間提供了分區。隔離是指對工作負載進行嚴格約束，即使其中一個受到損害，也無法跨越邊界。

僅憑命名空間不足以實現多租戶安全

命名空間的局限性在現代攻擊模式中表現得尤為突出。容器逃逸和內核級漏洞說明了這個問題：

• ? GPU 逃逸： Wiz 記錄了 NVIDIA 漏洞[5]，允許攻擊者通過利用鉤子和環境變量處理來逃逸容器邊界。命名空間對此無能為力，因為攻擊是針對共享內核狀態執行的。
• ? 權限提升： 一旦進入內核，攻擊者就可以提升權限，損害相鄰的工作負載并在節點間橫向移動。
• ? 爆炸半徑： 在僅依賴命名空間的模型中，一個受損的 Pod 可能會引發級聯故障，影響節點上的每個工作負載。在受監管行業或 SaaS 多租戶環境中，這是不可接受的。

將命名空間視為強化邊界的安全模型依賴于一個危險的誤解：即邏輯分離等同于運行時隔離。一旦容器突破到內核，一切都將失控。

歷史對比：虛擬機與容器

值得記住的是，虛擬化在幾十年前就解決了這個問題。虛擬機（VM）通過為每個工作負載提供自己的內核來強制執行硬邊界。一個虛擬機不能輕易地干擾另一個。容器為了速度、密度和敏捷性而放棄了這一點——這些權衡在當時是合理的。

但時代變了。輕量級虛擬化和基于管理程序的運行時已經縮小了曾經使虛擬機吸引力下降的性能差距。半虛擬化和 Type-1 管理程序[6]現在提供了接近原生的性能，同時恢復了命名空間所缺乏的強大隔離特性。

蘋果最近通過其新的 Container Framework 驗證了這種方法[7]，該框架在虛擬機支持的邊界內運行容器。Kata Containers、Firecracker 以及 Edera 等較新的強化運行時項目，都將同樣的原則帶到了 Kubernetes。教訓很清楚：我們不再需要在速度和安全之間做出選擇。

為什么命名空間無法作為安全邊界

要了解為什么命名空間不等于隔離，我們需要深入研究 Linux 內核本身。

• ? 命名空間 隱藏進程ID、文件系統和網絡接口等資源。它們改變了容器所看到的內容。
• ? Cgroups 控制容器可以消耗多少CPU或內存。它們規定了容器的使用量。
• ? Seccomp 和 AppArmor 限制系統調用或強制執行配置文件，但它們仍然在共享內核內部運行。

這些機制都無法阻止一個受損的容器攻擊內核或利用漏洞影響其他租戶。充其量，它們限制了可見性和資源使用。它們不提供現代工作負載所需的加密或硬件支持的保證。

對比一下管理程序級別的隔離：

? 每個容器（或 Pod）都在具有自己內核的輕量級虛擬機中運行。

? 沒有共享內核狀態意味著一個虛擬機中的逃逸漏洞不會暴露主機或其他租戶。

? GPU 和設備訪問可以虛擬化，從而消除工作負載之間的側信道泄露。

這就是分區與保護之間的區別。

案例研究：CVE-2025-23266

考慮 CVE-2025-23266[8]，一個三行 NVIDIA 容器逃逸漏洞，允許攻擊者實現主機級入侵。該漏洞之所以有效，是因為特權鉤子在共享內核上下文中執行。一個惡意容器可以通過 LD_PRELOAD 注入一個庫并立即逃逸。

僅憑命名空間，這次攻擊就成功了。如果采用管理程序級別的隔離，它將被限制住。惡意庫永遠不會觸及主機內核——它只會影響到被隔離的客戶機。這個例子突顯了為什么命名空間不能成為最后一道防線。

強化運行時的興起

這就是強化運行時發揮作用的地方。強化運行時通過以下方式顛覆了傳統模型：

1. 強制真正的執行隔離 – 具有獨立內核的沙盒區域，沒有對對等容器或設備的隱式訪問。

2. 最小化攻擊面 – 剝奪不必要的權限，阻止無范圍的系統調用并消除主機可見性。

3. 實時遏制威脅 – 在出現異常時切斷網絡訪問或暫停執行。

結果是，整類攻擊——權限提升、橫向移動、內核逃逸——在結構上變得不可能，而不僅僅是更難檢測。

為什么這對于AI和GPU工作負載很重要

AI 使解決這個問題變得更加緊迫。AI 代理不僅分析數據，它們還執行代碼，持有憑證并與內部系統交互。與此同時，GPU 在多個租戶和工作負載之間共享，通常帶有暴露的驅動程序和內存接口。側信道泄露在這里并非理論，它已在實踐中得到證實。

當命名空間是唯一的控制手段時，AI 工作負載仍然容易受到困擾傳統容器環境的相同類別的逃逸和權限提升攻擊。具有真正隔離邊界的強化運行時是大規模防御這些風險的唯一方法。

關于隔離的更清晰對話

那么這給我們帶來了什么啟示？命名空間至關重要：它們組織集群，強制執行策略，并使多團隊操作易于管理。但它們不應與隔離混淆。如果 Kubernetes 是開發者、基礎設施工程師和安全團隊之間的契約，那么命名空間就是管理條款。然而，真正的隔離是在運行時強制執行的。

作為一個行業，我們需要停止混淆這兩者。邏輯分離不同于運行時保護。前者減少混亂；后者防止違規。

好消息是，我們無需放棄 Kubernetes 或容器就能實現這一點。輕量級虛擬化、強化運行時和基于管理程序的容器已經存在，并且它們與 Kubernetes API 無縫集成。技術已經成熟。所需要的是清晰的認識以及改變我們對隔離看法的意愿。

分區與保護

為了構建安全、有彈性的基礎設施，我們需要重新審視這個問題。命名空間很有價值，但它們不提供隔離。真正的隔離需要運行時而非僅在控制平面運行的架構邊界。

下次有人說命名空間提供了隔離時，請記住這一點：分區不是保護。如果你的工作負載很重要——如果合規性、多租戶或AI安全面臨風險——那么僅憑命名空間是不夠的。

業界必須超越隔離的幻覺，擁抱真正強制執行隔離的運行時環境。

引用鏈接

[1] Beyond Namespaces: Why Kubernetes Needs Real Workload Isolation:https://thenewstack.io/beyond-namespaces-why-kubernetes-needs-real-workload-isolation/
[2]一篇文章:https://thenewstack.io/namespaces-a-step-by-step-guide-to-kubernetes-isolation/
[3]強化的邊界:https://thenewstack.io/hardened-containers-arent-enough-the-runtime-security-gap/
[4]命名空間邊界的文章:https://blog.amberwolf.com/blog/2025/september/kubernetes_namespace_boundaries/
[5]記錄了 NVIDIA 漏洞:https://edera.dev/stories/the-principle-of-isolation
[6]半虛擬化和 Type-1 管理程序:https://edera.dev/stories/what-the-f-ck-is-paravirtualization
[7]驗證了這種方法:https://thenewstack.io/what-you-need-to-know-about-apples-new-container-framework/
[8]CVE-2025-23266:https://edera.dev/stories/how-edera-eliminates-cve-2025-23266-container-escapes