Vault KMS Beta Puts Kubernetes Encryption Keys Back in Your Hands

The Key Problem Nobody Wants to Talk About

Kubernetes can encrypt data at rest. It has been able to do that for a while. The real question is: where do the keys live? If the same cluster that stores your secrets also guards the keys that encrypt them, you've built a very convenient box for an attacker to open. HashiCorp's Rich DuBose and Steve Almy put it bluntly: the trust boundary is too narrow.

This is the gap Vault's new beta aims to close. On July 10, HashiCorp released a public beta of Vault as a Kubernetes KMS provider. The plugin, vault-kube-kms, is compatible with KMS v2. It lets your API server hand off envelope encryption duties to Vault Enterprise, so the keys protecting etcd data live outside the cluster entirely.

Why This Matters for Your Sailing Operations

Think of your Kubernetes cluster like a racing yacht. The hull, the sails, the rigging—that's your infrastructure. But the navigation charts and the race strategy? Those are your secrets. You wouldn't leave your charts in the same locker as the spare winch handles, would you? No. You'd lock them in a safe that the crew can't open on a whim.

That's the shift here. Kubernetes handles the heavy lifting of encrypting and decrypting data—the constant back-and-forth that keeps your applications moving. Vault holds the master keys, the ones that matter. If someone steals the etcd database, they get ciphertext and encrypted DEKs. Without Vault, that data is gibberish.

How the Envelope Encryption Dance Works

The plugin keeps the standard envelope encryption separation. Kubernetes generates a Data Encryption Key (DEK) for each resource, uses it to encrypt the data, and writes the result to etcd. That part hasn't changed. What's new is that the DEK seed is wrapped by a Key Encryption Key (KEK) stored in Vault. The transit engine in Vault performs the encryption operations. The encrypted DEK and the encrypted data sit together in etcd, but they're useless without access to Vault.

This division of labor is what regulated teams actually want. Kubernetes handles the volume of encryption calls—it's really good at that. Vault handles key lifecycle, rotation, policy enforcement, and audit. You get centralized key management with RBAC, rotation workflows that let you decrypt existing data during rotation, and monitoring of key usage, latency, and errors through Vault audit logs and plugin metrics. No application code changes required.

Who's This For?

HashiCorp sees this fitting into a few specific scenarios. Enterprise Kubernetes platforms like Red Hat OpenShift are an obvious target. Multi-cluster production environments where you don't want keys scattered across every cluster. Regulated environments that demand separation of duties between who operates the platform and who controls the keys. And zero-trust projects where you're trying to shrink the blast radius of any single compromise.

But there's a broader trend here. HashiCorp frames this as part of the growing machine identity problem. Applications, containers, CI/CD pipelines, infrastructure automation, and now AI agents all need continuous access to sensitive resources without human intervention. That means protecting the trust root becomes even more critical. If a CI pipeline can decrypt your production secrets, that's a target. Moving the keys to a dedicated vault outside the cluster makes that target a lot harder to hit.

Not Exactly New Territory

If you've been around Kubernetes for a while, this might feel familiar. Managed platforms have offered similar integrations for years. Azure Key Vault has a KMS provider for AKS. Community projects like vault-kubernetes-kms have filled the gap for self-hosted clusters. Forum threads from a few years back show platform teams begging for an official Vault-based KMS provider.

The difference now is that teams already standardized on Vault Enterprise have a vendor-supported path. It's been tested against recent Kubernetes minor releases. That's a big deal for enterprises that don't want to run a community plugin in production without a support contract behind it.

What You Should Know Before Jumping In

This is a beta, so there are some caveats. First, it's Vault Enterprise only. If you're on the open-source edition, this won't work. Second, deployment requires modifying the Kubernetes EncryptionConfig and kube-apiserver configuration files. That rules out most fully managed control planes. You need access to the API server configuration, which means self-managed or hybrid setups.

Third, think about Vault's availability. The KMS provider sits directly on the data decryption path. If Vault goes down, your API server can't decrypt data. That's a hard dependency. You'll want to run Vault in a highly available configuration and have a solid incident response plan. The trade-off is that you're trading a cluster-level compromise for a Vault-level one, and Vault is designed to be the thing you protect with everything you've got.

The Road Ahead

HashiCorp calls this beta the first step toward centralized key management for Kubernetes encryption at scale. That's a fair description. It's not a magic bullet, but it's a meaningful move for teams that want to draw a clear line between the cluster and the keys that protect its data.

If you're running Kubernetes in production and you're already invested in Vault, this is worth a look. Spin it up in a test environment, poke at the rotation workflow, and see how the audit logs feel. If you're not using Vault yet, this might be the push you needed to start evaluating it. Either way, the direction is clear: keys should live where your security team says they live, not where the cluster happens to put them.

For sailing teams, the analogy holds. You wouldn't leave the keys to the boat shed in the cockpit. You'd keep them in a lockbox that only the skipper and the first mate can open. Vault is that lockbox for your Kubernetes secrets. The beta is a chance to see how it fits before you commit to the full voyage.