Kubernetes 1.27: KMS V2 进入 Beta 阶段

作者： Anish Ramasekar, Mo Khan, and Rita Zhang (Microsoft)

译者： Xin Li (DaoCloud)

在 Kubernetes 1.27 中，我们（SIG Auth）将密钥管理服务（KMS）v2 API 带入 Beta 阶段。

KMS 是什么？

保护 Kubernetes 集群时首先要考虑的事情之一是加密静态的 etcd 数据。 KMS 为供应商提供了一个接口，以便利用存储在外部密钥服务中的密钥来执行此加密。

KMS v1 自 1.10 版以来一直是 Kubernetes 的一项功能特性，该特性从 v1.12 版开始处于 Beta 阶段。KMS v2 在 v1.25 中作为 Alpha 特性引入。

v2beta1 有什么新内容？

KMS 加密驱动使用信封加密方式来加密 etcd 中的数据，使用数据加密密钥（DEK）对数据进行加密。 DEK 使用在远程 KMS 中存储和管理的密钥加密密钥（KEK）进行加密。 使用 KMS v1，每次加密都会生成一个新的 DEK。 使用 KMS v2，只有在服务器启动时且 KMS 插件通知 API 服务器发生 KEK 轮换时才会生成新的 DEK。

时序图

加密请求

解密请求

状态请求

生成数据加密密钥（DKE）

性能改进

在 KMS v2 中，我们对 KMS 加密提供程序的性能进行了重大改进。对于 KMS v1， 每次加密都会生成一个新的 DEK。这意味着对于每个写入请求，API 服务器都会调用 KMS 插件以使用远程 KEK 加密 DEK。为避免每个读取请求都会调用 KMS 插件， API 服务器必须缓存 DEK。当 API 服务器重新启动时， 它必须根据缓存大小为 etcd 存储中的每个 DEK 调用 KMS 插件来填充缓存。 这对 API 服务器来说是一个很大的开销。使用 KMS v2，API 服务器在启动时生成一个 DEK 并将其缓存。 API 服务器还调用 KMS 插件以使用远程 KEK 加密 DEK。这是启动时和 KEK 轮换时的一次性调用。 在此之后，API 服务器使用缓存的 DEK 来加密资源。这样做减少了对 KMS 插件的调用次数， 并改善了 API 服务器请求的整体延迟。

我们进行了一项创建 12,000 个 Secret 的测试，并检测了 API 服务器加密资源所花费的时间。使用的指标是 apiserver_storage_transformation_duration_seconds。 对于 KMS v1，测试在具有 2 个节点的托管 Kubernetes v1.25 集群上运行。 测试期间集群上没有额外的负载。对于 KMS v2， 测试是在具有以下集群配置的 Kubernetes CI 环境中运行的

结果表明，KMS v2 加密驱动比 KMS v1 快三个数量级。

下一步计划

对于 Kubernetes v1.28，我们预计该功能仍处于测试阶段。在即将发布的版本中，我们将致力于：

• 修改加密程序以消除对 VM 状态存储的限制。
• 针对密钥轮换，修改 Kubernetes REST API 以实现更强大的特性。
• 处理无法解密的资源，更多细节参考：KEP

你可以通过阅读使用 KMS 驱动进行数据加密， 还可以关注 KEP 来跟踪即将发布的 Kubernetes 版本进度。

行动号召

在这篇博文中，我们介绍了 Kubernetes v1.27 中对 KMS 加密驱动所做的改进。 我们还讨论了新的 KMS v2 API 及其工作原理。我们很想听听你对此功能的反馈， 特别是，我们希望 Kubernetes KMS 插件实现者在构建与这个新 API 的集成过程中得到反馈。 请通过 Kubernetes Slack 上的 #sig-auth-kms-dev 频道与我们联系。

如何参与

如果你有兴趣参与此功能的开发、分享反馈或参与任何其他正在进行的 SIG Auth 项目， 请联系 Kubernetes Slack 上的 [#sig-auth](https://kubernetes.slack.com/archives /C0EN96KUY) 频道。

也欢迎你加入每两周举行一次的 SIG Auth 会议， 每隔一个星期三举行一次。

致谢

此功能是由来自几家不同公司的贡献者推动的，我们非常感谢所有贡献时间和精力帮助实现这一目标的人。

• ←上一页
下一页→