这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
Kubernetes 1.25：KMS V2 改进
随着 Kubernetes v1.25 发布，SIG Auth 为密钥管理服务（Key Management Service，KMS）API
引入了新的 v2alpha1 版本。我们正在推进多项改进，
很高兴能由此开启全新、更完善的 KMS 之路！
KMS 是什么？
保障 Kubernetes 集群安全时，首先要考虑的事项之一就是对持久化的 API 数据进行静态加密。 KMS 提供一种接口，允许驱动使用存储在外部密钥服务中的密钥执行加密。
使用 KMS v1 进行静态加密从 Kubernetes v1.10 起就是一项特性， 自 v1.12 起处于 Beta 阶段。
v2alpha1 中有什么新内容？
最初的 v1 实现虽然成功帮助 Kubernetes 用户加密了 etcd 数据， 但仍在几个关键方面有所不足：
- 性能： 启动集群时会串行获取并解密所有资源，以填充
kube-apiserver缓存。使用 KMS 插件时，由于会向远程保险库发送大量请求， 启动过程可能变得缓慢。此外，集群中加密资源较多时， 还可能触发外部密钥服务的 API 速率限制。
- 密钥轮换： 使用 KMS v1 时，轮换密钥加密密钥（Key Encryption Key，KEK） 需手工完成，过程容易出错。此外，也难以判断集群当前正在使用哪些加密密钥。
- 健康检查与状态： 在 KMS v2 API 出现之前，
kube-apiserver只能以代理方式发起加密、解密调用，以此判断 KMS 插件是否健康。 使用云服务时，这些操作通常会产生实际费用。 无论费用高低，这些操作本身都无法全面反映服务的健康状况。
- 可观测性： 在缺少跟踪 ID 之类标识时，
很难将
kube-apiserver、KMS 与 KMS 插件各自日志中的事件关联起来。
KMS v2 增强特性旨在解决上述所有不足，但并非所有计划中的特性 都会在初始 Alpha 版本中实现。Kubernetes v1.25 带来的改进如下：
- 支持使用密钥层次结构（key hierarchy）的 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 会议。 会议于隔周的周三举行。
致谢
此特性由来自多家公司的贡献者共同努力实现。 我们衷心感谢每一位为此付出时间和精力、帮助实现该特性的人。