Vault Kubernetes KMS enters public beta, aiming at the etcd key sprawl

What HashiCorp actually shipped

HashiCorp announced a public beta of Vault Kubernetes key management on July 10, 2026. The delivery vehicle is a KMS v2 compatible plugin named vault-kube-kms that lets the Kubernetes API server hand its envelope encryption work to Vault Enterprise. Secrets and other API resources on their way to etcd get encrypted through Vault. The per-cluster envelope key that used to live wherever the ops team first put it stops being the trust anchor.

Per the HashiCorp post, the plugin implements the Kubernetes KMS v2 interface and forwards cryptographic operations to Vault Enterprise. Kubernetes still generates the data encryption keys (DEKs) that wrap the secret payloads themselves. Vault's transit secrets engine holds the key encryption keys (KEKs) that wrap the DEK seed. Standard envelope shape, familiar split of duties.

Why this matters upstream of a pipeline

Every CI/CD story that ends in a bad week starts with "the credential was in an env var somewhere". The moment your deploy pushes secrets, image pull tokens or service account credentials into a Kubernetes namespace, they land in etcd. By default etcd stores that payload as cleartext on disk. Cluster operators who have been paying attention already turned on encryption-at-rest through a KMS provider. A large tail of clusters has not, or did it with a locally generated key that is now the second most sensitive artifact in the environment after the etcd disks.

Wiring the API server into Vault does not close a hole that a well-set-up KMS provider does not already close. What it does is collapse two custody trails into one. If your pipeline already reaches into Vault for build credentials, the same policy engine, audit stream and rotation runbook now cover the etcd envelope key. That is one fewer place a rotation gets forgotten between quarters.

How you turn it on

The plugin sits behind Kubernetes' existing EncryptionConfiguration. Per the HashiCorp post, deploying it means editing that file and the kube-apiserver manifest to point at the plugin's socket. Nothing about the API server side of the contract is new. That is precisely why "KMS v2 compatible" is the load-bearing phrase in the release, not the plugin's own configuration surface.

The shape looks like this (all values are placeholders, not verbatim from the release):

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          apiVersion: v2
          name: vault-kube-kms
          endpoint: unix:///var/run/kms/<plugin-socket>
          timeout: <duration>
      - identity: {}

The Vault side does what Vault does for any transit workflow: a policy on a transit key, an auth method the plugin uses to reach it, and a rotation schedule.

Where it can still bite you

Two operational gotchas are worth writing down before you plan a migration.

First, the API server has no fast fallback if the KMS plugin is unreachable. This is a property of Kubernetes' KMS provider design, not of Vault specifically. A Vault outage during a control plane restart is a control plane outage. The failure mode matches every cloud KMS provider in the same slot, and it is worth capacity planning for.

Second, adopting a KMS plugin does not re-encrypt existing rows in etcd on its own. That is a separate, well-documented operation: rewrite every secret so the new provider ends up on the wrapping path. Plan the maintenance window, because rotating the Vault-side KEK later has the same requirement.

How other KMS providers sit in the same slot

The Kubernetes KMS interface is the plumbing every major cloud already implements. AWS KMS, Google Cloud KMS and Azure Key Vault all fit into the same provider slot the Vault plugin now targets. The trade-off is boring but real. A cloud KMS provider gives you the shortest network path from the API server to the key, at the cost of one more identity boundary to reason about. A Vault-backed plugin puts the etcd envelope key in the same audit and policy plane as everything else you already manage in Vault, at the cost of running Vault Enterprise on the reliability path of the API server.

Public beta means the plugin is not cleared for production yet. For teams already standardized on Vault, the honest read is that it removes an argument, not a workload.