Kubernetes 1.27：KMS V2 进入 Beta 阶段

在 Kubernetes 1.27 中，我们（SIG Auth）正在将密钥管理服务 (KMS) v2 API 移至 beta 版本。

什么是 KMS？

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

KMS v1 自 1.10 版本以来一直是 Kubernetes 的一个功能，并且截至 v1.12 版本目前处于 beta 阶段。KMS v2 作为 alpha 版本在 v1.25 中引入。

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 服务器重新启动时，它必须通过根据缓存大小调用 KMS 插件以获取 etcd 存储中的每个 DEK 来填充缓存。这对于 API 服务器来说是一个巨大的开销。在 KMS v2 中，API 服务器在启动时生成一个 DEK 并将其缓存。API 服务器还会调用 KMS 插件以使用远程 KEK 加密 DEK。这是启动时和 KEK 轮换时的一次性调用。然后，API 服务器使用缓存的 DEK 来加密资源。这减少了对 KMS 插件的调用次数，并提高了 API 服务器请求的整体延迟。

我们进行了一项测试，该测试创建了 12k 个秘密，并测量了 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 会议。

致谢

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

• ←上一篇
下一篇→