本文发表时间已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已失效。

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 数据,但在几个关键方面存在不足:

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

KMS v2 增强功能试图解决所有这些不足,尽管并非所有计划的功能都在最初的 Alpha 版本中实现。以下是 Kubernetes v1.25 中带来的改进:

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

时序图

加密请求

Sequence diagram for KMSv2 Encrypt

解密请求

Sequence diagram for KMSv2 Decrypt

下一步是什么?

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

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

如何参与

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

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

致谢

此功能是来自多家不同公司的贡献者共同努力的结果。我们衷心感谢所有为此付出时间精力的人。