HashiCorp's Vault Now Guards Kubernetes Secrets at Rest

Kubernetes Can Encrypt, But Where Are the Keys?

Kubernetes has been able to encrypt data at rest for a while now. But there's a catch: the keys that protect that data are stored right alongside it, inside the cluster itself. That's a bit like locking your front door and leaving the key under the mat.

HashiCorp has just announced a public beta that changes the game for Vault Enterprise users. The new feature lets Kubernetes use Vault as a Key Management Service (KMS) provider for encrypting secrets and other API resources stored in etcd. It's a solution that's been brewing for months, and it's finally here.

Why Move Keys Out of the Cluster?

The problem isn't that Kubernetes can't encrypt data—it can. The real issue is where the keys live. If an attacker compromises the cluster, they might get both the data and the keys that protect it. That's what HashiCorp's Rich DuBose and Steve Almy call a "trust boundary that is still too narrow."

Platform teams have to juggle tough questions: Where are the key encryption keys (KEKs) stored? Who gets access? How do you rotate them? How do you audit their use? When keys live inside the cluster, those answers are murky at best.

How the Vault KMS Integration Works

The new plugin, vault-kube-kms, is compatible with KMS v2 and works by offloading envelope encryption to Vault. Here's the flow: Kubernetes still generates a Data Encryption Key (DEK) and uses it to encrypt secrets before writing them to etcd. That part hasn't changed, so the API server keeps its expected throughput. But instead of storing the DEK seed in the cluster, it's wrapped by a Key Encryption Key (KEK) stored in Vault. The encrypted DEK and the encrypted data go into etcd together.

If Vault isn't reachable, that data stays encrypted and unreadable. That's a crucial point for anyone considering this setup.

Separation of Duties: A Win for Compliance Teams

This division of labor is a blessing for regulated organizations. Kubernetes handles the high volume of encryption and decryption calls, while Vault takes over the heavy lifting of key lifecycle management, rotation, policy enforcement, and auditing. It's a clear split: the cluster does the grunt work, and Vault holds the keys.

HashiCorp's documentation highlights several benefits:

• Centralized key management with role-based access control (RBAC)
• Rotation workflows that don't disrupt existing data—old keys can still decrypt data during rotation
• Visual monitoring of key usage, latency, and errors via Vault audit logs and plugin metrics

And here's the kicker: none of this requires changes to application code. That's a huge relief for teams that are already running Vault Enterprise.

Where This Makes Sense

HashiCorp sees this as a natural fit for enterprise Kubernetes platforms like Red Hat OpenShift, multi-cluster production environments, and regulated spaces that demand separation of duties. It's also a step forward for zero-trust projects, where you want to minimize the blast radius of any single compromise.

The company frames key management as part of the broader machine identity problem. Applications, containers, CI/CD pipelines, infrastructure automation, and even AI agents all need to access sensitive resources continuously, without human intervention. That makes protecting the trust root more critical than ever.

Not a Brand-New Idea, But a Welcome One

Managed Kubernetes platforms have offered similar integrations for years. Azure Key Vault KMS for AKS is a prime example. Community projects like vault-kubernetes-kms have filled the gap for self-hosted clusters, but they were unofficial and often required significant maintenance.

Forums have been buzzing with requests for an official Vault-based KMS provider for years. Now, teams that already standardize on Vault Enterprise have a vendor-supported path that's been tested against recent Kubernetes releases. That's a big deal.

Limitations and Considerations

Before you jump in, here are a few things to keep in mind. This feature is exclusive to Vault Enterprise, so open-source users are out of luck. Deployment requires modifying the Kubernetes EncryptionConfig and kube-apiserver configuration files, which rules out most fully managed control planes. You'll need to think carefully about Vault's availability, since it sits directly in the data decryption path. If Vault goes down, your cluster can't decrypt data, which could be a problem for uptime.

What's Next

HashiCorp calls this beta the first step toward centralized key management for large-scale Kubernetes encryption. They're inviting platform engineering and security teams to kick the tires and share feedback. If you're already invested in Vault Enterprise, this is worth a look. It could simplify your compliance story and give you a cleaner separation between the data and the keys that protect it.