Kubernetes 1.27：KMS V2 移至 Beta 版

在 Kubernetes 1.27 中，我們 (SIG Auth) 正在將金鑰管理服務 (KMS) v2 API 移至 Beta 版。

什麼是 KMS？

保護 Kubernetes 叢集時首先要考慮的事項之一，是對靜態 etcd 資料進行加密。KMS 為供應商提供了一個介面，可以利用儲存在外部金鑰服務中的金鑰來執行此加密。

自 1.10 版本以來，KMS v1 一直是 Kubernetes 的一項功能，截至 v1.12 版本，目前處於 Beta 版。KMS v2 在 v1.25 中以 Alpha 版形式推出。

v2beta1 中的新功能？

KMS 加密供應商使用信封加密方案來加密 etcd 中的資料。資料使用資料加密金鑰 (DEK) 進行加密。DEK 使用金鑰加密金鑰 (KEK) 進行加密，KEK 儲存並管理在遠端 KMS 中。使用 KMS v1，每次加密都會產生新的 DEK。使用 KMS v2，只有在伺服器啟動時以及 KMS 外掛程式通知 API 伺服器發生 KEK 輪換時，才會產生新的 DEK。

順序圖

加密請求

解密請求

狀態請求

產生資料加密金鑰 (DEK)

效能提升

使用 KMS v2，我們對 KMS 加密供應商的效能進行了顯著的提升。在 KMS v1 的情況下，每次加密都會產生新的 DEK。這表示對於每個寫入請求，API 伺服器都會呼叫 KMS 外掛程式，以使用遠端 KEK 加密 DEK。API 伺服器還必須快取 DEK，以避免為每個讀取請求呼叫 KMS 外掛程式。當 API 伺服器重新啟動時，它必須根據快取大小，為 etcd 儲存區中的每個 DEK 呼叫 KMS 外掛程式來填充快取。這對 API 伺服器來說是一個顯著的開銷。使用 KMS v2，API 伺服器會在啟動時產生一個 DEK 並快取它。API 伺服器也會呼叫 KMS 外掛程式，以使用遠端 KEK 加密 DEK。這是啟動時和 KEK 輪換時的一次性呼叫。然後，API 伺服器使用快取的 DEK 來加密資源。這減少了對 KMS 外掛程式的呼叫次數，並提高了 API 伺服器請求的整體延遲。

我們進行了一項測試，建立了 1.2 萬個密碼，並測量了 API 伺服器加密資源所花費的時間。使用的指標是apiserver_storage_transformation_duration_seconds。對於 KMS v1，測試在具有 2 個節點的託管 Kubernetes v1.25 叢集上執行。測試期間叢集上沒有額外負載。對於 KMS v2，測試在 Kubernetes CI 環境中執行，並使用以下叢集配置。

結果顯示，KMS v2 加密供應商比 KMS v1 加密供應商快三個數量級。

下一步是什麼？

對於 Kubernetes v1.28，我們預計此功能將保持在 Beta 版。在即將發布的版本中，我們希望研究

• 移除 VM 狀態儲存限制的加密變更。
• Kubernetes REST API 變更，以實現更健全的金鑰輪換方案。
• 處理無法解密的資源。有關詳細資訊，請參閱 KEP。

您可以閱讀使用 KMS 供應商進行資料加密，以了解有關 KMS v2 的更多資訊。您也可以關注 KEP，以追蹤即將發布的 Kubernetes 版本中的進度。

行動呼籲

在本部落格文章中，我們介紹了 Kubernetes v1.27 中 KMS 加密供應商的改進。我們也討論了新的 KMS v2 API 及其運作方式。我們很樂意聽到您對此功能的意見回饋。特別是，我們希望從 Kubernetes KMS 外掛程式實作者那裡獲得回饋，因為他們正在經歷建構與此新 API 整合的過程。請透過 Kubernetes Slack 上的 #sig-auth-kms-dev 頻道與我們聯繫。

如何參與

如果您有興趣參與此功能的開發、分享回饋或參與任何其他正在進行的 SIG Auth 專案，請透過 Kubernetes Slack 上的 #sig-auth 頻道與我們聯繫。

也歡迎您參加每週兩次的 SIG Auth 會議，每隔週三舉行。

致謝

此功能是由多家不同公司的貢獻者共同努力推動的成果。我們衷心感謝每位貢獻時間和精力來協助實現此目標的人。

• ←上一篇
下一篇→