Kubernetes命名空間提供邏輯分區(qū)而非運(yùn)行時(shí)隔離，這在多租戶和AI工作負(fù)載中構(gòu)成安全風(fēng)險(xiǎn)。僅依賴命名空間不足以抵御攻擊，真正的隔離需強(qiáng)化運(yùn)行時(shí)和輕量級虛擬化。

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

作者：Lewis Denham-Parry

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

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

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

命名空間是分區(qū)，而非隔離

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

但命名空間并未改變所有運(yùn)行在同一節(jié)點(diǎn)上的容器共享同一個內(nèi)核這一基本事實(shí)。一個命名空間中受損的容器仍然有可能攻擊內(nèi)核，利用共享設(shè)備或窺探GPU內(nèi)存，因?yàn)閮?nèi)核本身就是共享表面。

Amber Wolf 關(guān)于命名空間邊界的文章[4]通過真實(shí)世界的例子強(qiáng)調(diào)了這一點(diǎn)。當(dāng)租戶管理員被賦予完整的命名空間控制權(quán)時(shí)，他們通常仍保留影響整個集群的途徑。紅隊(duì)經(jīng)驗(yàn)表明，命名空間邊界在壓力下無法堅(jiān)守。它們是策略結(jié)構(gòu)，而非安全屏障。

這種區(qū)別之所以重要，是因?yàn)槲覀兘?jīng)常談?wù)撁臻g和隔離，仿佛它們可以互換。它們不能。命名空間提供了分區(qū)。隔離是指對工作負(fù)載進(jìn)行嚴(yán)格約束，即使其中一個受到損害，也無法跨越邊界。

僅憑命名空間不足以實(shí)現(xiàn)多租戶安全

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

• ? GPU 逃逸： Wiz 記錄了 NVIDIA 漏洞[5]，允許攻擊者通過利用鉤子和環(huán)境變量處理來逃逸容器邊界。命名空間對此無能為力，因?yàn)楣羰轻槍蚕韮?nèi)核狀態(tài)執(zhí)行的。
• ? 權(quán)限提升： 一旦進(jìn)入內(nèi)核，攻擊者就可以提升權(quán)限，損害相鄰的工作負(fù)載并在節(jié)點(diǎn)間橫向移動。
• ? 爆炸半徑： 在僅依賴命名空間的模型中，一個受損的 Pod 可能會引發(fā)級聯(lián)故障，影響節(jié)點(diǎn)上的每個工作負(fù)載。在受監(jiān)管行業(yè)或 SaaS 多租戶環(huán)境中，這是不可接受的。

將命名空間視為強(qiáng)化邊界的安全模型依賴于一個危險(xiǎn)的誤解：即邏輯分離等同于運(yùn)行時(shí)隔離。一旦容器突破到內(nèi)核，一切都將失控。

歷史對比：虛擬機(jī)與容器

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

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

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

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

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

• ? 命名空間 隱藏進(jìn)程ID、文件系統(tǒng)和網(wǎng)絡(luò)接口等資源。它們改變了容器所看到的內(nèi)容。
• ? Cgroups 控制容器可以消耗多少CPU或內(nèi)存。它們規(guī)定了容器的使用量。
• ? Seccomp 和 AppArmor 限制系統(tǒng)調(diào)用或強(qiáng)制執(zhí)行配置文件，但它們?nèi)匀辉诠蚕韮?nèi)核內(nèi)部運(yùn)行。

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

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

? 每個容器（或 Pod）都在具有自己內(nèi)核的輕量級虛擬機(jī)中運(yùn)行。

? 沒有共享內(nèi)核狀態(tài)意味著一個虛擬機(jī)中的逃逸漏洞不會暴露主機(jī)或其他租戶。

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

這就是分區(qū)與保護(hù)之間的區(qū)別。

案例研究：CVE-2025-23266

考慮 CVE-2025-23266[8]，一個三行 NVIDIA 容器逃逸漏洞，允許攻擊者實(shí)現(xiàn)主機(jī)級入侵。該漏洞之所以有效，是因?yàn)樘貦?quán)鉤子在共享內(nèi)核上下文中執(zhí)行。一個惡意容器可以通過 LD_PRELOAD 注入一個庫并立即逃逸。

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

強(qiáng)化運(yùn)行時(shí)的興起

這就是強(qiáng)化運(yùn)行時(shí)發(fā)揮作用的地方。強(qiáng)化運(yùn)行時(shí)通過以下方式顛覆了傳統(tǒng)模型：

1. 強(qiáng)制真正的執(zhí)行隔離 – 具有獨(dú)立內(nèi)核的沙盒區(qū)域，沒有對對等容器或設(shè)備的隱式訪問。

2. 最小化攻擊面 – 剝奪不必要的權(quán)限，阻止無范圍的系統(tǒng)調(diào)用并消除主機(jī)可見性。

3. 實(shí)時(shí)遏制威脅 – 在出現(xiàn)異常時(shí)切斷網(wǎng)絡(luò)訪問或暫停執(zhí)行。

結(jié)果是，整類攻擊——權(quán)限提升、橫向移動、內(nèi)核逃逸——在結(jié)構(gòu)上變得不可能，而不僅僅是更難檢測。

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

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

當(dāng)命名空間是唯一的控制手段時(shí)，AI 工作負(fù)載仍然容易受到困擾傳統(tǒng)容器環(huán)境的相同類別的逃逸和權(quán)限提升攻擊。具有真正隔離邊界的強(qiáng)化運(yùn)行時(shí)是大規(guī)模防御這些風(fēng)險(xiǎn)的唯一方法。

關(guān)于隔離的更清晰對話

那么這給我們帶來了什么啟示？命名空間至關(guān)重要：它們組織集群，強(qiáng)制執(zhí)行策略，并使多團(tuán)隊(duì)操作易于管理。但它們不應(yīng)與隔離混淆。如果 Kubernetes 是開發(fā)者、基礎(chǔ)設(shè)施工程師和安全團(tuán)隊(duì)之間的契約，那么命名空間就是管理?xiàng)l款。然而，真正的隔離是在運(yùn)行時(shí)強(qiáng)制執(zhí)行的。

作為一個行業(yè)，我們需要停止混淆這兩者。邏輯分離不同于運(yùn)行時(shí)保護(hù)。前者減少混亂；后者防止違規(guī)。

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

分區(qū)與保護(hù)

為了構(gòu)建安全、有彈性的基礎(chǔ)設(shè)施，我們需要重新審視這個問題。命名空間很有價(jià)值，但它們不提供隔離。真正的隔離需要運(yùn)行時(shí)而非僅在控制平面運(yùn)行的架構(gòu)邊界。

下次有人說命名空間提供了隔離時(shí)，請記住這一點(diǎn)：分區(qū)不是保護(hù)。如果你的工作負(fù)載很重要——如果合規(guī)性、多租戶或AI安全面臨風(fēng)險(xiǎn)——那么僅憑命名空間是不夠的。

業(yè)界必須超越隔離的幻覺，擁抱真正強(qiáng)制執(zhí)行隔離的運(yùn)行時(shí)環(huán)境。

引用鏈接

[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]強(qiáng)化的邊界: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]驗(yàn)證了這種方法: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