摘要
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 平台、多集群生产环境、需要职责分离的受监管环境以及零信任项目。