Kubernetes 1.27：KMS V2 进入 Beta 阶段

随着 Kubernetes 1.27 的发布，我们（SIG Auth）正在将 Key Management Service (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 中，新的 DEK 仅在服务器启动时以及 KMS 插件通知 API Server KEK 已轮换时才会生成。

时序图

加密请求

解密请求

状态请求

生成数据加密密钥 (DEK)

性能改进

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

我们进行了一项测试，创建了 12k 个 Secret，并测量了 API Server 加密这些资源所花费的时间。使用的指标是 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 的双周会议，会议每隔一周的星期三举行。

致谢

此功能是多个不同公司的贡献者共同努力的成果。我们要向所有为此付出时间和精力的人表示衷心感谢。

• ←上一篇
• 下一篇→