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.
