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 会议，会议在每隔一个周三举行。

致谢

这个功能是由来自多家不同公司的贡献者共同努力推动的。我们衷心感谢每一位贡献了时间和精力使其成为可能的人。

• ←上一篇
• 下一篇→