本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.25: KMS V2 改进

作者：Anish Ramasekar、Rita Zhang、Mo Khan、Xander Grzywinski (Microsoft) | 2022 年 9 月 9 日，星期五

在 Kubernetes v1.25 中，SIG Auth 引入了密钥管理服务（KMS）API 的新版本 v2alpha1。我们正在进行大量改进，很高兴能够开启通往全新和改进版 KMS 的道路！

什么是 KMS？

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

自 Kubernetes v1.10 版本以来，使用 KMS v1 进行静态加密一直是其一项功能，并且从 v1.12 版本开始，目前处于 Beta 阶段。

虽然最初的 v1 实现在帮助 Kubernetes 用户加密 etcd 数据方面取得了成功，但它在几个关键方面确实存在不足：

性能： 启动集群时，所有资源都会被串行获取和解密，以填充 kube-apiserver 的缓存。使用 KMS 插件时，由于向远程保管库发出了大量请求，这可能会导致启动时间变慢。此外，根据集群中加密资源的数量，还有可能触及外部密钥服务的 API 速率限制。
密钥轮换： 使用 KMS v1，密钥加密密钥（Key-Encrypting Key）的轮换是一个手动且容易出错的过程。很难确定集群上正在使用哪些加密密钥。
健康检查与状态： 在 KMS v2 API 之前，kube-apiserver 被迫进行加密和解密调用作为代理，以确定 KMS 插件是否健康。对于云服务，这些操作通常会产生实际的费用。无论成本如何，这些操作本身并不能提供服务健康状况的整体视图。
可观测性： 如果没有某种跟踪 ID，就很难将 kube-apiserver、KMS 和 KMS 插件的各种日志中发现的事件关联起来。

KMS v2 增强功能试图解决所有这些缺点，尽管并非所有计划中的功能都在最初的 Alpha 版本中实现。以下是 Kubernetes v1.25 中引入的改进：

支持使用密钥层次结构的 KMS 插件，以减少向远程保管库发出的网络请求。要了解更多信息，请查看KMS 插件如何利用密钥层次结构的设计细节。
现在会跟踪额外的元数据，以允许 KMS 插件与 kube-apiserver 通信其当前正在使用的密钥，从而无需重启 API 服务器即可进行轮换。存储在 etcd 中的数据遵循更标准的 proto 格式，以允许外部工具观察其状态。要了解更多信息，请查看元数据的详细信息。
专用的状态 API 用于与 API 服务器通信 KMS 插件的健康状况。要了解更多信息，请查看状态 API 的详细信息。
为了提高可观测性，v2 API 的 EncryptRequest 和 DecryptRequest 中包含了一个新的 UID 字段。该 UID 是为每个信封操作生成的。要了解更多信息，请查看可观测性的详细信息。

对于 Kubernetes v1.26，我们预计会发布另一个 Alpha 版本。目前，该 Alpha API 已准备好供 KMS 插件作者使用。我们希望在下一个版本中包含一个参考插件实现，届时您将能够试用该功能。

您可以通过阅读使用 KMS 提供程序进行数据加密来了解有关 KMS v2 的更多信息。您还可以关注 KEP，以跟踪未来 Kubernetes 版本的进展。

如果您有兴趣参与此功能的开发或希望分享反馈，请通过 Kubernetes Slack 上的 #sig-auth-kms-dev 频道与我们联系。

也欢迎您参加每两周一次的 SIG Auth 会议，会议在每隔一个周三举行。

此功能是由来自多家公司的贡献者共同努力推动的。我们衷心感谢所有为实现这一目标而贡献时间和精力的人。