HashiCorp has launched a public beta allowing Kubernetes clusters to offload their encryption keys to Vault Enterprise, moving the cryptographic material that protects sensitive data outside the cluster itself. The company announced the Vault Kubernetes key management feature on July 10, shipping a KMS v2-compatible plugin named vault-kube-kms that lets the Kubernetes API server delegate envelope encryption operations to Vault. The release addresses a persistent concern for platform teams: even when Kubernetes encrypts data stored in its etcd database, the keys protecting that data often live in the same environment they're supposed to secure.
The plugin maintains Kubernetes' standard envelope encryption architecture but shifts where the most sensitive keys are stored. Kubernetes continues generating and using data encryption keys to encrypt resource data before writing it to etcd, preserving the throughput the API server requires. The data encryption key seed is then protected by key encryption keys held in Vault, where the transit secrets engine handles cryptographic operations. Both the encrypted data and the encrypted data encryption key are stored together in etcd, but without a reachable and properly configured Vault instance, decryption becomes impossible. No changes to application code are required for the integration to work.
Writing on the HashiCorp blog, Rich DuBose and Steve Almy argue that when "the same environment that stores sensitive data also controls the keys used to protect it," the result is a trust boundary that "remains too narrow." The report identifies the practical benefit as a division of labor: Kubernetes handles high-volume encryption and decryption calls, while Vault owns key lifecycle management, rotation procedures, policy enforcement, and audit functions. HashiCorp's documentation highlights centralized key management with role-based access control, rotation workflows that preserve the ability to decrypt existing data, and visibility into key usage, latency, and errors through Vault audit logs and plugin metrics.
The capability fills a gap that managed platforms and community projects have addressed for years—Azure Key Vault KMS for AKS and the community vault-kubernetes-kms project have provided similar integrations—but HashiCorp frames the need as increasingly urgent because key management has become a machine identity problem. Applications, containers, CI/CD pipelines, infrastructure automation, and AI agents all require continuous access to sensitive resources without human oversight, placing greater pressure on an independently protected root of trust. The company points to enterprise Kubernetes platforms like Red Hat OpenShift, multi-cluster production environments, regulated sectors requiring separation of duties, and zero trust programs as the primary use cases. HashiCorp Discuss threads stretching back several years show platform teams repeatedly requesting an official Vault-backed Kubernetes KMS provider, and this release offers a vendor-supported option for organizations already standardized on Vault Enterprise.
The beta carries notable constraints for teams evaluating adoption. It requires Vault Enterprise and the ability to modify both the Kubernetes EncryptionConfig and the kube-apiserver manifest, which excludes most fully managed control planes. Teams also need to plan for Vault availability, since the KMS provider sits directly on the path for decrypting cluster data. HashiCorp describes the beta as an initial step toward centralized key management for Kubernetes encryption at scale and is inviting platform engineering and security teams to test it and share feedback.