Kubernetes 1.37將Pod Certificates與Cluster Trust Bundles升為Stable，強化工作負載身分與憑證管理；同時Manifest-based Admission Control進入Beta，提升准入政策對API竄改的抗性。本文聚焦其安全價值、部署前提與管理者應對方向。
Kubernetes 1.37正式發布後，最受關注的安全更新是Pod Certificates與Cluster Trust Bundles同步升為Stable。這代表工作負載身分驗證不再只依賴Service Account JWT，而是可透過Kubernetes取得X.509憑證，讓Pod以更適合企業零信任架構的方式完成身分驗證。
相較於過去常見的Bearer Token模型，這次更新把重點放在憑證式身分與自動輪替機制。Pod Certificates可由Kubelet負責私密金鑰與憑證生命週期，並可用於TLS與mTLS驗證，降低憑證外洩後長期被濫用的風險。
同一版本中，Manifest-based Admission Control也升為Beta。此機制可從本機靜態檔案載入Admission Webhook與CEL policy，讓安全政策在API server啟動時即生效，且不依賴etcd，也無法透過Kubernetes API直接修改。
Kubernetes過去的工作負載身分設計，核心仍圍繞Service Account JWT。這種Bearer Token的最大問題在於一旦被竊取，攻擊者便可能直接冒用工作負載身分，且其濫用門檻相對低。從防禦角度來看，這種風險不是來自演算法本身，而是來自權杖可攜、可複製、可重放的特性。
Pod Certificates改以X.509憑證與非對稱密碼機制處理身分驗證，安全層次明顯不同。私密金鑰可由Kubelet管理，憑證則可自動輪替，讓憑證生命週期管理更接近實務上可控的安全模型。對需要內部服務互驗的場景而言，mTLS可同時驗證雙方身分，降低單向Token授權過於鬆散的問題。
Cluster Trust Bundles的價值則在於補強信任錨點管理。當工作負載改以憑證互認時，信任鏈與憑證來源的管理就變得關鍵。此機制可讓叢集內部對信任根的描述更集中，減少各服務自行維護憑證信任設定所帶來的碎片化與設定偏差。
但這項能力並非完全開箱即用。Kubernetes核心目前尚未提供Pod Certificates signer，因此管理者仍需另外部署Signer Controller，負責簽發與更新憑證，並維護Cluster Trust Bundles中的信任錨點資訊。換言之，Stable不等於免維運，而是代表API與行為已足夠成熟，仍需要周邊控制器與流程配合。
Manifest-based Admission Control升級為Beta，也是一項值得重視的防護強化。傳統上，Admission控制常仰賴叢集內元件與API資源管理，一旦攻擊者取得較高API權限，便可能嘗試調整政策或移除限制。改由本機靜態檔案載入後，政策不經由etcd保存，且無法透過Kubernetes API修改，可顯著降低政策被線上竄改的面積。
這種設計特別適合高敏感度環境，因為准入邏輯本身就是叢集安全邊界的一部分。將關鍵政策從可被API操控的資料平面中抽離，等於把部分安全控制往更封閉的啟動階段前移，能在管理權限被濫用時提供額外保護。
這次更新影響最大的，是已經在Kubernetes上承載重要內部服務、微服務通訊與機密工作負載的環境。凡是依賴Service Account JWT作為主要工作負載身分依據的叢集，都應重新評估是否要逐步導入Pod Certificates，以降低權杖外洩後的橫向移動風險。
對服務間通訊要求較高的系統，例如需要TLS或mTLS的應用，Pod Certificates可提供更一致的憑證式驗證基礎。這對大型叢集、跨命名空間服務互認、或需要更細粒度信任管理的場景特別有利。
然而，若叢集沒有部署Signer Controller，或缺乏憑證輪替與信任錨點管理流程，導入效果就會受限。也就是說，受影響的不只是應用層，而是整體叢集治理能力，包括憑證發放、更新、撤銷與信任鏈維護。
Manifest-based Admission Control則主要影響需要強化政策防竄改能力的管理者。對於高安全要求環境、受法規約束的基礎設施、或擁有多管理角色的叢集而言，這類以靜態檔案啟動的准入機制可作為更保守的政策承載方式。
管理者首先應盤點目前工作負載身分的使用方式，確認哪些服務仍完全依賴Service Account JWT，哪些服務已具備憑證式驗證需求。若現階段已有內部mTLS或TLS驗證計畫，應優先評估Pod Certificates的導入路徑。
其次，需補齊Signer Controller與信任錨點管理流程。Pod Certificates雖已升為Stable，但實際安全性仍取決於簽發、輪替與信任套件更新是否一致且可觀測。若缺乏對憑證生命週期的監控，新的驗證模式反而可能形成營運風險。
第三，建議將Manifest-based Admission Control納入高敏感度叢集的政策設計。特別是在不希望准入政策被API層直接修改的情境下，可將關鍵政策移出etcd管理範圍，以降低遭內部權限濫用時的政策失效風險。
第四，應將憑證輪替與政策檔案變更納入變更管理與稽核流程。當安全控制從動態API資源轉為本機靜態檔案後，版本控管、部署驗證與回復機制就變得更重要。