CNCF 警告：僅靠 Kubernetes 不足以保障 LLM 工作負載的安全性

作者 ｜ Craig Risi

譯者 ｜ 張衛濱

云原生計算基金會 (CNCF) 發布的 一篇博客文章 指出，企業在 Kubernetes 上部署大語言模型 (LLM) 時存在一個關鍵的安全缺口，那就是盡管 Kubernetes 擅長編排和隔離工作負載，但它本身無法理解或控制 AI 系統的行為，由此形成了一類完全不同且更為復雜的威脅模型。

文章認為，LLM 引入了一類新的風險，因為它們處理的是不受信任的輸入，并且能夠動態決定行動方式，這與傳統應用不同。在典型部署中，例如，通過 API 或聊天界面暴露一個 LLM，Kubernetes 可以保證 Pod 運行正常、資源狀態穩定，但它無法感知提示詞是否是惡意的、敏感數據是否泄露，或模型是否以不安全方式與內部系統交互。這會導致一種糟糕的局面，那就是，基礎設施表面健康，而底層風險卻未被發現。

CNCF 強調，基于 LLM 的系統必須被視為可編程、可決策的實體，而不僅僅是計算工作負載。當組織把 LLM 置于內部工具、日志、API 或憑據之前時，實際上是引入了一個可被提示詞輸入影響的新抽象層。這會打開一系列風險入口，例如，提示詞注入、意外數據暴露以及對已連接工具的濫用，而這些威脅并非傳統 Kubernetes 安全控制最初所要解決的問題。

這種轉變反映了云原生系統更廣泛的演進：Kubernetes 正越來越多地被用于運行 AI 和生成式工作負載。隨著采用規模的增長，這個平臺正在從最初管理無狀態微服務的定位，被擴展到編排數據密集型、智能體驅動和推理密集型系統。然而，安全模型尚未完全跟上這些新場景。

雖然 Kubernetes 為調度、隔離和資源管理提供了強有力的基礎能力，但它缺乏對 AI 系統施加應用層或語義層控制的內置機制。比如，它無法判斷一個提示詞是否應被執行、一個響應是否泄露敏感信息，或某個 LLM 是否應訪問特定工具或 API。

這種局限凸顯了在基礎設施之外增加額外控制層的必要性。傳統 Kubernetes 安全實踐，如 RBAC、網絡策略和容器隔離，依然是必要的，但單獨使用它們還不夠。組織還必須引入 AI 特定的控制，包括提示詞校驗、輸出過濾、工具訪問限制以及應用層策略執行。

博客指出，當前正在出現對“AI 感知型平臺工程”的需求，即把安全同時嵌入基礎設施層和應用層。這包括引入諸如 OWASP Top 10 for LLMs 之類框架、落實策略即代碼（policy-as-code），并建立約束模型與數據和外部系統交互方式的護欄機制。

行業討論正越來越多地將其定義為：從傳統威脅模型轉變為行為與上下文感知的安全模型。關注點不再只是保護基礎設施本身，而是控制智能系統在其中的行為。隨著 LLM 演進為可執行動作的自治或 Agentic 系統，這些問題會變得更加重要。

CNCF 的分析對那些正在 Kubernetes 上快速采用 AI 的組織發出了警示：運行健康不等于安全。一個系統即便完全符合 Kubernetes 的最佳實踐，也仍可能通過其 AI 層暴露出明顯的風險。

主要技術與安全廠商正在收斂到相似的原則。行業指南 越來越多地建議采用多層安全模型，結合運行時監控、human-in-the-loop 控制，以及圍繞 AI 系統可執行動作的嚴格策略約束。一個一致觀點是，LLM 絕不能被當作權威決策者，而必須在有邊界的上下文中運行，并具備明確的護欄、持續驗證和可審計性。

隨著 LLM 采用加速，行業正被迫重新思考關于信任邊界、工作負載隔離和應用行為的長期假設。由此形成的結果是一個新的安全范式：Kubernetes 仍是基礎層，但必須疊加 AI 特定的治理、可觀測性與控制機制，才能確保智能系統的安全可靠部署。

CNCF Warns Kubernetes Alone Is Not Enough to Secure LLM Workloads(https://www.infoq.com/news/2026/04/kubernetes-secure-workloads/)

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。