對於許多剛接觸 Kubernetes (K8s) 的工程師來說，我們習慣於將敏感資訊存放在 Kubernetes Secrets 中。但你可能沒意識到，預設情況下，這些 Secret 在後端資料庫 etcd 中是以明文儲存的。雖然 K8s 支援 Encryption at Rest（靜態加密），讓資料在寫入磁碟前先加密，但這裡存在一個核心的安全漏洞：加密金鑰 (Key) 存放在哪裡？
如果加密資料的環境與存放金鑰的環境是同一個，這在安全定義上稱為信任邊界過窄。簡單來說，如果攻擊者拿到了叢集控制權，他不僅能拿到加密後的資料，還能直接在同一台伺服器上找到解密金鑰，這讓加密變得毫無意義。
為了解決這個問題，HashiCorp 推出了 Vault Kubernetes Key Management 的公開測試版。這是一個讓 K8s 能夠將金鑰管理委託給 Vault Enterprise 的插件，旨在將金鑰的控制權移出叢集外部，建立獨立的信任根。
理解信封加密機制
要理解這個插件如何運作，必須先認識信封加密 (Envelope Encryption) 的概念。這是一種為了兼顧效能與安全性而設計的兩層加密法。
第一層是資料加密金鑰 (Data Encryption Key, DEK)。K8s API Server 會生成 DEK 來對實際的 Secret 資料進行加密。因為 DEK 處理的是大量的高頻率讀寫，直接在本地處理可以確保 API Server 的吞吐量不會因為網路延遲而下降。
第二層是金鑰加密金鑰 (Key Encryption Key, KEK)。這才是真正的核心金鑰。DEK 在使用完後，會被 KEK 加密，然後將加密後的 DEK 與加密後的資料一起儲存在 etcd 中。而這把 KEK 則被嚴格地存放於外部的 Vault 中。
在這種架構下，當 K8s 需要解密資料時，它必須將加密後的 DEK 送往 Vault，由 Vault 的 Transit Secrets Engine（一個專門處理加密運算的引擎）進行解密並回傳 DEK，K8s 才能最終還原資料。如果 Vault 無法連通或權限不足，即便拿到了 etcd 的所有資料也無法解密。
為什麼這對企業級環境至關重要
對於受監管行業或追求零信任 (Zero Trust) 架構的團隊，這種職責分離 (Separation of Duties) 是合規性的基本要求。
首先是集中化管理與審計。當金鑰放在 Vault 中，安全團隊可以透過單一介面管理所有叢集的金鑰，並透過 Vault 的稽核日誌 (Audit Logs) 清楚知道誰在什麼時候請求解密了哪一筆資料，而不需要去翻找分散在各個叢集的日誌。
其次是金鑰輪替 (Key Rotation)。手動輪替 K8s 金鑰風險極高且繁瑣，而 Vault 提供了自動化的輪替工作流，且能確保舊資料在輪替後依然能被正確解密。
最後是身分認證的演進。現代基礎設施中，存取敏感資源的不再僅是人類，更多是 AI Agent、CI/CD 流水線或自動化腳本。將金鑰管理轉化為機器身分管理問題，能讓系統在無需人工干預的情況下，安全地獲取暫時性權限。
實作限制與部署考量
雖然這個方案解決了安全性問題，但在導入前有幾個工程實務上的限制需要注意。
首先是部署權限。使用此插件需要修改 Kubernetes 的 EncryptionConfig 以及 kube-apiserver 的啟動參數。這意味著如果你使用的是完全託管的雲端 K8s 服務（如某些限制較多的 Managed Control Plane），你可能沒有權限修改這些底層配置，導致無法安裝。
其次是可用性風險。由於解密路徑上增加了對 Vault 的依賴，Vault 變成了整個叢集的單點失效風險 (Single Point of Failure)。如果 Vault 宕機，API Server 將無法讀取任何加密的 Secret，可能導致整個叢集內的應用程式無法啟動或崩潰。因此，部署 Vault 時必須確保其高可用性 (HA) 配置。
最後是版本限制。目前此功能僅限於 Vault Enterprise 版本，並非開源版可用。
總結來說，Vault Kubernetes Key Management 將 K8s 從單純的資料儲存者，提升為安全架構的一部分，將金鑰生命週期管理與資料儲存徹底分離，為大規模生產環境提供了更強的防禦能力。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。