HashiCorp 发布 Vault Kubernetes 密钥管理功能的公开测试版

HashiCorp 已发布 Vault Kubernetes 密钥管理功能的公开测试版 "。该版本允许 Kubernetes 集群将 Vault Enterprise 作为其静态数据加密的 KMS 提供程序。 该版本于 7 月 10 日发布，随附了一个 兼容 KMS v2 的插件 vault-kube-kms " 。它允许 Kubernetes API 服务器将信封加密任务卸载至 Vault，从而保护存储在 etcd 中的 Kubernetes 密钥和其他 API 资源，并将守护这些数据的密钥移出集群。 问题并不在于 Kubernetes 能否对静态数据进行加密（它确实可以），而在于支撑该加密功能的密钥存储在何处。在 HashiCorp 的博客中，Rich DuBose 和 Steve Almy 指出，如果存储敏感数据的环境同时也控制着用于保护这些数据的密钥，那么“信任边界仍然过于狭窄”。这使得平台团队不得不面对一些棘手的问题：密钥加密密钥存储在哪里、谁可以访问它们、如何轮换以及如何对其使用情况进行审计。 该插件保持了标准信封加密的分离机制。Kubernetes 仍然会生成并使用数据加密密钥 (DEK) 来加密敏感资源数据，然后将其写入 etcd，从而保持 API 服务器所期望的吞吐量。DEK 种子由存储在 Vault 中的密钥加密密钥（KEK）来保护，其中 传输密钥引擎 "负责执行加密操作。加密后的数据和加密后的 DEK 共同存储在 etcd 中。如果没有正确配置的 Vault 可以访问，那么这些数据将无法被解密。 这种职责分工正是受监管团队所能获得的实际好处：Kubernetes 负责处理大量加密和解密调用，而 Vault 则负责密钥生命周期管理、轮换、策略执行和审计。HashiCorp 的 文档 "中介绍了集中式密钥管理和基于角色的访问控制（RBAC）、在轮换过程中仍能解密现有数据的轮换工作流，以及通过 Vault 审计日志和插件指标对密钥使用情况、延迟和错误的可视化监控。这些都不需要修改应用程序代码。 HashiCorp 指出，该功能的主要部署场景包括 Red Hat OpenShift " 等企业级 Kubernetes 平台、多集群生产环境、需要职责分离的受监管环境以及零信任项目。该公司将密钥管理看成是一个日益突出的机器身份问题：应用程序、容器、CI/CD管道、基础设施自动化和 AI 代理都需要在无需人工干预的情况下持续地访问敏感资源，这使得单独保护信任根变得愈发重要。 这项功能并非完全是一个全新的领域。托管平台早就已经提供了类似的集成方案，例如 面向 AKS 的 Azure Key Vault KMS "；而像 vault-kubernetes-kms " 这样的社区项目则填补了自托管集群的空白。 HashiCorp Discuss 论坛上几年前的讨论帖 "显示，平台团队曾多次呼吁官方推出基于 Vault 的 Kubernetes KMS 提供程序。这里的区别在于，对于已经采用 Vault Enterprise 作为标准方案的团队，现在有了一条由供应商提供支持的途径，而且这条路径已经在近期发布的 Kubernetes 小版本中经过了测试。 对于任何评估该测试版的人来说，有几点限制值得注意一下。该功能仅适用于 Vault Enterprise，而且部署时需要修改 Kubernetes EncryptionConfig 和 kube-apiserver 配置文件，这排除了大多数全托管控制平面。团队还需仔细考虑 Vault 的可用性，因为 KMS 提供程序位于集群数据解密路径上。 HashiCorp 将此测试版描述为实现大规模 Kubernetes 加密集中化密钥管理的第一步，并邀请平台工程和安全团队进行评估并提供反馈。 原文链接： https://www.infoq.com/news/2026/08/vault-kubernetes-key-management/ "