HashiCorp Ships Public Beta of Vault Kubernetes Key Management

HashiCorp has shipped a public beta of Vault Kubernetes key management. The offering is a KMS v2-compatible plugin that lets the Kubernetes API server hand off envelope encryption to Vault Enterprise instead of keeping that path fully inside the cluster. The change targets the key encryption keys that protect etcd data, moving them into a trust domain governed separately from the cluster itself.

At the product level, the plugin sits on the Kubernetes KMS v2 interface and routes envelope encryption work to Vault Enterprise. The API server still encrypts secrets and other sensitive objects for etcd storage, but the keys that wrap those data encryption keys live in Vault rather than in the cluster control plane. That split puts key material under Vault policies, auth methods, and operational controls instead of under the same administrative boundary as the Kubernetes nodes and etcd members.

For platform and security engineers, the beta addresses a long-standing tension: etcd holds the cluster’s most sensitive state, yet the keys that protect it often share fate with the cluster. If the control plane is compromised, KEKs co-located there are easier to reach. Delegating that layer to Vault Enterprise gives teams a clearer separation between cluster operators and key custodians, and it aligns Kubernetes secret encryption with the same Vault workflows many already use for application secrets and certificates.

In market terms, this is HashiCorp deepening Vault’s role as an external KMS for Kubernetes rather than only as a secrets store apps call at runtime. KMS v2 support matters because that is the modern encryption-provider path on the API server; a plugin that speaks it is how external systems plug into envelope encryption without custom control-plane forks. The Enterprise dependency also frames the product for organizations already standardized on Vault for compliance and key lifecycle, not as a free-tier bolt-on.

What to watch next is how the public beta behaves under real upgrade, failover, and multi-cluster key-rotation scenarios, and whether HashiCorp tightens the path from beta to general availability for production clusters. Builders evaluating it should map Vault auth and policy for the API server identity, confirm that KEK governance actually sits outside the cluster admin domain, and treat etcd encryption configuration as a first-class recovery and disaster-recovery concern—not only a checkbox on secret encryption at rest.