Kubernetes 1.27: KMS V2 進入 Beta 階段

隨著 Kubernetes 1.27 的釋出，我們（SIG Auth）將金鑰管理服務（KMS）v2 API 推進到 Beta 階段。

什麼是 KMS？

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

KMS v1 自 Kubernetes 1.10 版本以來一直是其一個特性，並在 v1.12 版本中進入 Beta 階段。KMS v2 在 v1.25 版本中作為 Alpha 特性引入。

v2beta1 中有什麼新內容？

KMS 加密提供程式使用信封加密方案來加密 etcd 中的資料。資料使用資料加密金鑰（DEK）進行加密。DEK 則使用儲存在遠端 KMS 中並由其管理的金鑰加密金鑰（KEK）進行加密。在 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 伺服器請求的整體延遲。

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

結果表明，KMS v2 加密提供程式比 KMS v1 加密提供程式快三個數量級。

接下來是什麼？

對於 Kubernetes v1.28，我們預計該功能將保持在 Beta 階段。在未來的版本中，我們希望研究：

• 密碼學上的變更，以消除對虛擬機器狀態儲存的限制。
• 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 會議，會議在每隔一個週三舉行。

致謝

這個功能是由來自多家不同公司的貢獻者共同努力推動的。我們衷心感謝每一位貢獻了時間和精力使其成為可能的人。

• ←上一篇
• 下一篇→