HashiCorp has released the public beta of Vault Kubernetes key management, which lets Kubernetes clusters use Vault Enterprise as their KMS provider for encryption at rest.
Announced on the 10th of July, the release ships a KMS v2-compatible plugin called vault-kube-kms. It allows the Kubernetes API server to offload envelope encryption to Vault, protecting Kubernetes Secrets and other API resources stored in etcd, and moving the keys that guard that data outside the cluster.
The issue is not whether Kubernetes can encrypt data at rest; it can, but where the keys behind that encryption live. Writing on the HashiCorp blog, Rich DuBose and Steve Almy argue that if the same environment that stores sensitive data also controls the keys used to protect it, "the trust boundary remains too narrow". That leaves platform teams answering awkward questions about where key encryption keys are stored, who can reach them, how they are rotated, and how their usage is audited.
The plugin keeps the standard envelope encryption split. Kubernetes still generates and uses data encryption keys (DEKs) to encrypt sensitive resource data before it is written to etcd, preserving the throughput the API server expects. The DEK seed is protected by key encryption keys (KEKs) held in Vault, where the transit secrets engine performs the cryptographic operations. The encrypted data and the encrypted DEK are stored in etcd together. Without a reachable, correctly configured Vault, that data cannot be decrypted.
That split of duties is the practical benefit for regulated teams: Kubernetes handles high-volume encrypt and decrypt calls, while Vault owns key lifecycle, rotation, policy enforcement, and audit. HashiCorp's documentation lists centralised key management and RBAC, rotation workflows that retain the ability to decrypt existing data, and visibility into key usage, latency, and errors through Vault audit logs and plugin metrics. No application code changes are required.
HashiCorp points to enterprise Kubernetes platforms such as Red Hat OpenShift, multi-cluster production estates, regulated environments requiring separation of duties, and zero trust programmes as the main deployment scenarios. The company frames key management as increasingly a machine identity problem: applications, containers, CI/CD pipelines, infrastructure automation, and AI agents all need continuous access to sensitive resources without human intervention, which puts more weight on an independently protected root of trust.
The capability is not entirely new territory. Managed platforms have offered similar integrations for some time, including Azure Key Vault KMS for AKS, and community projects such as vault-kubernetes-kms have filled the gap for self-managed clusters. HashiCorp Discuss threads going back several years show platform teams repeatedly asking for an official Vault-backed Kubernetes KMS provider. The difference here is a vendor-supported path for teams already standardised on Vault Enterprise, with tested support across recent Kubernetes minor releases.
There are constraints worth noting for anyone evaluating the beta. It is Vault Enterprise only, and deployment requires the ability to modify the Kubernetes EncryptionConfig and the kube-apiserver manifest, which rules out most fully managed control planes. Teams also need to think through Vault availability, since the KMS provider sits on the path for decrypting cluster data.
HashiCorp describes the beta as a first step toward centralised key management for Kubernetes encryption at scale, and is inviting platform engineering and security teams to evaluate it and provide feedback.