Kubernetes 1.37 正式上線：X.509 Pod 憑證與叢集信任套件成為穩定功能
Kubernetes 近期釋出 1.37 版，將 Pod 憑證（Pod Certificates） 與 叢集信任套件（Cluster Trust Bundles） 同步升級為 Stable（穩定）。此舉為長期以服務帳號 JWT（JSON Web Token）作為工作負載身分驗證的模型，提供了以 X.509 憑證 為基礎的全新驗證機制，並支援自動輪替，降低憑證外洩後的冒用風險。
背景與技術細節
過去 Kubernetes 內建的工作負載身分認證，主要仰賴 服務帳號 JWT。JWT 為持有者權杖（Bearer Token），一旦被竊取，攻擊者即可冒用該工作負載的所有權限。為了解決此類弱點，1.37 版引入 X.509 憑證，採用非對稱密碼（公私鑰）機制，可直接用於 TLS（傳輸層安全）與 雙向 TLS（mTLS） 身分驗證，讓通訊雙端皆能驗證對方的真實身分。
憑證的產生與管理仍由 憑證簽發控制器（Signer Controller） 負責，管理者需自行部署此控制器，以簽發與更新 Pod 憑證，並維護 叢集信任套件 中的信任錨點（Trust Anchor）資訊。Kubelet 會在節點上安全保存私密金鑰，並在 Pod 啟動時將相應的憑證注入容器，完成完整的生命週期管理。
安全與運維的雙重提升
- 憑證自動輪替：Kubernetes 會在憑證即將過期前自動觸發更新，避免因手動失誤導致服務中斷。
- 降低憑證外洩衝擊：X.509 憑證的私密金鑰僅存於節點本機，且只能由 Kubelet 讀取，較 JWT 更難被遠端竊取。
- 支援 mTLS：在服務間通訊（Service‑to‑Service）加入雙向驗證，可防止惡意 Pod 偽裝合法服務。
同時，1.37 版將 Manifest 式准入控制（Manifest‑based Admission Control） 升為 Beta，允許管理者以本機靜態檔案載入准入 Webhook 與 CEL（Common Expression Language）政策。這類政策在 API 伺服器啟動時即生效，且不依賴 etcd，減少具備 API 權限的使用者竄改准入規則的可能性。
未來展望與讀者建議
Pod 憑證與叢集信任套件的穩定化，預示著 Kubernetes 正在向「零信任」架構靠攏。企業在導入 1.37 後，應盡快部署 Signer Controller，並檢視現有的服務帳號使用情形，評估是否可以逐步替換為 X.509 憑證。配合 Manifest 式准入控制，可在基礎設施層面建立更嚴謹的安全防線。
對於仍在使用舊版 Kubernetes 的組織，建議提前規劃升級路線，並在測試環境驗證憑證簽發、輪替與 mTLS 流程，以免在正式上線時遭遇意外中斷。隨著憑證管理工具的成熟，未來有望看到原生的憑證簽發器直接整合於核心，進一步簡化操作流程。
結語：Kubernetes 1.37 的安全升級不僅是技術層面的改進，更是雲原生環境中「身份即信任」的關鍵一步。掌握這項新功能，將讓企業在多租戶與微服務架構下，獲得更堅實的防護基礎。