7 月 10 日，HashiCorp 发布 Vault Kubernetes 密钥管理功能公开测试版，让 Kubernetes 集群把静态数据加密的信任根整体移交给 Vault Enterprise——一个独立于集群之外的密钥管理边界。在 AI 代理、CI/CD 管道、容器工作负载都在疯狂申请机器身份密钥的当下，这可能是基础设施安全最该补上的一块拼图。
Kubernetes 并非不能加密静态数据——它一直能。问题在于：加密密钥和加密后的数据存放在同一个环境里。如果攻击者拿到了集群的访问权限，钥匙和数据都在他手里，加密形同虚设。
这就是 HashiCorp 在博客里说的「信任边界过于狭窄」。
Vault Kubernetes 密钥管理功能把这条边界重新划了一道：Kubernetes 负责加解密吞吐，Vault 负责密钥生命周期——轮换、策略、审计。数据加密密钥（DEK）仍由 K8s 生成，但保护 DEK 的密钥加密密钥（KEK）存放在 Vault 里，由传输密钥引擎执行加密操作。
没有正确配置的 Vault 访问权限，etcd 里的数据无法解密。加密与解密能力被拆到了两个独立实体中。
云厂商托管平台早就提供过类似集成，比如 AKS 的 Azure Key Vault KMS；社区里也有 vault-kubernetes-kms 这类自托管插件。但那些方案要么绑定特定云平台，要么缺乏官方支持——平台团队想要一个与云无关、有厂商背书的 KMS 提供程序。
云厂商托管集成（绑定平台）或社区插件（无官方支持）。自托管集群需求长期未被满足。
Vault Enterprise 原生能力，兼容 KMS v2，已适配近期 Kubernetes 小版本。厂商提供支持路径。
更关键的是，HashiCorp Discuss 论坛上几年前的讨论帖就显示平台团队多次呼吁这个能力。不是厂商拍脑袋做功能，是真实需求攒了足够久。
HashiCorp 在公告里点了一个容易被忽略的趋势：机器身份数量正在爆炸。应用程序、容器、CI/CD 管道、基础设施自动化——以及最新的加入者，AI 代理——都需要在无人工干预的情况下持续访问敏感资源。
人类身份可以从门禁卡管起，但机器身份呢？
每个 AI Agent 都是一个独立的机器身份，它要调 API、读数据库、写存储。如果这些密钥的信任根还和敏感数据放在同一个环境里，那 AI 代理的权限越大，风险敞口就越大。把信任根独立出来，是一切机器身份治理的前提。
每新增一类机器身份，就多一层密钥管理需求。Vault 的这次更新，本质上是为 AI 时代的基础设施安全补地板。
这个测试版不是万能药。它仅适用于 Vault Enterprise——免费版用户无缘使用；部署时需要修改 Kubernetes EncryptionConfig 和 kube-apiserver 配置文件，全托管控制平面基本排除在外。
还有一点需要清醒认识：KMS 提供程序位于集群数据解密路径上。Vault 的可用性直接影响集群的读写能力——在引入更强安全边界的同时，也引入了一个新的单点。团队需要认真评估 Vault 的高可用架构。
HashiCorp 自己也很坦诚：这是实现大规模 Kubernetes 加密集中化密钥管理的第一步，邀请平台工程与安全团队评估反馈。
当每个 AI 代理都成为一个需要持续取证的机器身份时，密钥管理就不再是运维问题，而是 AI 安全的地基。把信任根从数据环境里独立出来，是所有 AI 基础设施安全策略必须迈出的第一步。
Vault Enterprise 用户可查阅官方文档，了解 KMS v2 插件配置与部署要求。社区用户可关注后续开源版本规划。
HashiCorp 官方文档 → Vault K8s KMS 指南