Leo

你所依賴的每個准入 Webhook 都有逃脫機制。這並非什麼醜聞，只是 Kubernetes 設計使然。CNCF 於 7 月 30 日發表的一篇文章提出解決方案：將簽章與證明檢查從 API 伺服器移到容器執行階段本身，透過 Node Resource Interface 外掛實現。

簡而言之，Supply Chain NRI Plugin 在執行階段（CRI-O 或 containerd）攔截 CreateContainer 事件，從執行階段註記中取得影像參照與摘要，從 OCI 登錄檔取得證明，再依據每一個命名空間的政策進行驗證。該外掛檢查三種成品類型：SLSA 來源證明、VEX 文件與 VSA。若驗證失敗，容器便不會啟動。此鉤子在建立時觸發，而非在拉取影像時，因此即使影像已在節點上停留數小時，仍會在實際執行前接受檢查。

為什麼准入機制無法涵蓋全部

你已經知道這些失敗情境。CNCF 文章列出四種：直接由 kubelet 管理的靜態 Pod 完全跳過准入機制（鏡像 Pod 可能失敗，但容器仍會執行）；任何擁有直接 kubelet 存取權的使用者，都會繞過 API 伺服器；命名空間選擇器設定錯誤，會悄無聲息地豁免整個命名空間；以及准入 Webhook 發生故障時，會被迫在叢集鎖定或靜默繞過之間做選擇。

Kyverno、OPA Gatekeeper 與 Sigstore Policy Controller 都位於 API 層，因此都繼承這些逃脫機制。問題出在層級，而非這些專案。將檢查移到執行階段之下，就能封閉漏洞：無論容器是透過何種途徑排程，都必須經過執行階段。

注意事項

執行階段層級的驗證並非零成本。你現在必須依賴每個節點上外掛的健康狀態，以及在每次 CreateContainer 呼叫時，外掛具備連線至 OCI 登錄檔的憑證與網路路徑。若設定為失敗開放，合規性檢查將淪為形式；若設定為失敗關閉，登錄檔的短暫中斷就會造成全叢集啟動停擺。文章並未說明當登錄檔無法連線時，外掛會如何處理，或是政策更新如何在執行中的節點上推送。在啟用此功能前，你需要先釐清這兩點。

結論：信任邊界已朝正確方向移動，且這四種繞過路徑確實存在。請自行準備當登錄檔遇到問題時的應變手冊。