假設你接了個“臟活”：盤點公司所有跑在Kubernetes上的AI應用，然后告訴CTO“咱們現(xiàn)在到底有多大風險”。好消息是，K8s已經(jīng)在生產(chǎn)環(huán)境里證明了自己十幾年，RBAC、NetworkPolicies、Pod Security Admission這些原語打得微服務時代的安全威脅抬不起頭。壞消息是，你現(xiàn)在面對的不是微服務，是能理解自然語言、會被一句精心設計的提示詞操控的LLM Agent。這些原生安全控制在設計之初，連“語義載荷攻擊”這個概念都沒考慮過，而此刻你的集群里，正有幾十個推理接口直接暴露在公網(wǎng)上。

最近幾個月，一份又一份安全報告都在反復確認同一個事實：提示注入，已經(jīng)是LLM應用漏洞排名的頭號殺手。這事兒最可怕的地方在于，攻擊者不需要突破你的操作系統(tǒng)，不需要利用內(nèi)核漏洞提權，他只需要在對話框里輸入一段精心包裝的“越獄指令”，就有可能竊取系統(tǒng)提示詞、操控Agent執(zhí)行越權操作，或者把私有文檔里的敏感信息打包帶走。而K8s原生的NetworkPolicies，只能判斷源IP和目標端口的合法性——在一個HTTP請求體面前，它是個瞎子。至于那些“看似被RBAC牢牢鎖住”的服務賬號，它們完全分不清面前的請求到底是正常用戶發(fā)來的補全指令，還是一句被篡改過的、包含數(shù)據(jù)外泄邏輯的對抗性提示。

如果光看K8s的審計日志，你可能會誤以為一切風平浪靜。所有API調(diào)用都經(jīng)過了身份認證，所有Pod都沒有越權訪問宿主機網(wǎng)絡，底層節(jié)點也沒有出現(xiàn)異常的內(nèi)核日志。但真正的攻擊正在應用層靜悄悄地發(fā)生：一個普通的POST請求，攜帶的JSON字段里嵌套了多層自然語言指令，誘導你的LLM Agent“先忽略之前的系統(tǒng)提示，然后按照以下要求重構回答”。這種攻擊不需要繞過任何一條K8s的安全策略——因為K8s根本沒有能力檢查應用層載荷的語義。CTO問你的那個問題，此刻的答案可能是：咱們堡壘（K8s集群邊界）修得很堅固，但敵人早就從正門走進來了。

接著往深處挖，第二條你遲早要面對的防線漏洞在于供應鏈。K8s社區(qū)過去幾年好不容易建立起來的那套鏡像簽名、準入控制體系，在模型分發(fā)環(huán)節(jié)基本處于“裸奔”狀態(tài)。Cosign給容器鏡像打上簽名，Gatekeeper在準入時校驗策略，這一套組合拳到了模型文件層突然失效——因為模型權重不是OCI鏡像，它是個掛載進來的存儲卷，或者運行時動態(tài)拉取的遠程文件。安全研究員老早就演示過，惡意的pickle格式模型文件在反序列化時就能實現(xiàn)遠程代碼執(zhí)行，而你的鏡像掃描器根本不會去檢查Hugging Face上那90多萬個公開倉庫里藏了什么東西。

眼下能看到的一線曙光來自OpenSSF那邊的Model Signing項目，以及正在推動的模型透明化倡議。他們的思路很清晰：既然Cosign能給容器鏡像簽名，那把Sigstore這套機制擴展到ONNX、Safetensors、GGUF這些模型格式上去，用SLSA框架對齊的溯源信息來保證模型文件的完整性。與此同步推進的還有SPIFFE和SPIRE，正在嘗試打通訓練、倉庫、推理多個階段的工作負載身份，在流水線上跑通mTLS聯(lián)邦。但說實話，這些方案目前仍處于早期階段，真正落地的生產(chǎn)案例少之又少。

更大的隱患還藏在運行時層面。前沿模型權重的估值動輒數(shù)億美元，你現(xiàn)在面臨的不再是“脫庫”那種傳統(tǒng)數(shù)據(jù)泄漏，而是攻擊者直接用特權容器或者權限失控的sidecar，對節(jié)點內(nèi)存做宿主級別的檢查，把完整模型權重逐字節(jié)拉走。這種攻擊向量讓安全團隊不寒而栗——一旦權重泄漏，競爭對手完全可以把模型蒸餾、微調(diào)，你在算法上的護城河瞬間崩塌。AMD的SEV-SNP和英特爾TDX這兩種機密計算技術，通過CNCF的Confidential Containers項目整合進K8s生態(tài)，提供TEE背書的Pod執(zhí)行環(huán)境來保護使用中的模型權重，至少算是在架構層面看到了解法。

但尷尬之處恰恰在于，當你準備大規(guī)模部署機密計算容器時，云廠商控制面暴露出來的遙測數(shù)據(jù)可能會成為新的信息泄漏通道。攻擊者不需要直接攻破TEE，只需要觀察GPU利用率、內(nèi)存訪問模式、推理延遲這些側信道指標，就能推斷出你正在跑的是哪個架構的模型。這就像你給金庫加了十層鋼板，結果門口的保安把來訪記錄貼在了公示欄上——K8s原生的安全控制又一次證明了它處理不了這種攻擊面。平臺工程團隊如今面臨的困境非?，F(xiàn)實：在上層監(jiān)管要求日益收緊的壓力下，他們需要給AI技術棧臨時“打補丁”，而手里的工具基本還停留在微服務時代的威脅模型里。