IBM HashiCorp has released a Vault Enterprise plug-in that integrates with Kubernetes as an external KMS using the KMSv2 protocol introduced in Kubernetes 1.29. Unlike the legacy KMS model that required Vault to handle every encryption/decryption request, KMSv2 uses Data Encryption Key (DEK) seeds: Kubernetes encrypts data locally in memory, sends the DEK to Vault to be wrapped in a master Key Encryption Key (KEK), and caches the seed at startup for local decryption. This dramatically reduces network traffic and Vault load, especially during cluster reboots. The plug-in centralizes key authority in Vault, offering cleaner security separation. Current limitations include Vault Enterprise-only support (no open source Vault), incompatibility with most managed control planes due to required changes to EncryptionConfig and kube-apiserver manifests, and caution advised about placing the KMS provider directly in the decryption path.
Questions this post answers
What is the difference between KMSv1 and KMSv2 in Kubernetes for external key management?
In the legacy KMSv1 model, Kubernetes called the external key vault for every individual encryption and decryption request, creating severe bottlenecks during cluster reboots when thousands of requests hit the key server simultaneously. KMSv2, introduced in Kubernetes 1.29, uses DEK seeds: the API server encrypts data locally in memory, sends the DEK to Vault to be wrapped in a master KEK, caches the seed at startup, and only calls Vault during boots and periodic key rotations. Teams migrating Kubernetes secrets infrastructure track breaking changes like this on daily.dev before they hit production.
What are the limitations of the HashiCorp Vault Kubernetes KMS plug-in beta?
The beta plug-in only works with Vault Enterprise, not open source Vault. It is also incompatible with most fully managed Kubernetes control planes because it requires modifications to the EncryptionConfig and kube-apiserver manifest, which managed providers typically do not allow. Additionally, placing the KMS provider directly in the decryption path of cluster data warrants careful architectural consideration. Architects evaluating Vault for Kubernetes secrets keep up with caveats like these on daily.dev.