Rob Pankow 
Kubernetes environments handling regulated data, financial records, patient health information, or sovereign-cloud workloads must encrypt persistent volumes in a way that satisfies compliance auditors, not just operators. The common starting point, encrypting data inside the application, leaves the volume itself unencrypted on disk. Host-level disk encryption protects against physical theft but does not cover data flowing over the network path between compute nodes and shared storage. Storage-layer encryption closes both gaps: the storage system encrypts each volume before persisting any bytes, and a Vault KMS instance controls the encryption keys independently of the application and the compute infrastructure.
This post covers how storage-layer encryption works for Kubernetes persistent volumes, how Vault KMS integrates as the key provider, and what compliance requirements this approach satisfies that application-level or node-level methods do not.
Why Encryption Approaches Matter for Kubernetes Persistent Volumes
Kubernetes persistent volumes are different from traditional server disks. A persistent volume claim provisioned by a CSI driver can be served from a remote storage system over a network, most commonly NFS, iSCSI, or NVMe/TCP. The pod running on node A writes to a PVC whose backing store is physically located in a separate storage cluster. This multi-hop architecture raises a critical question: at which point in that path is the data encrypted, and who manages the keys?
Four encryption approaches exist for Kubernetes stateful workloads, each with a distinct boundary:
Application-level encryption: the application encrypts data before writing it to the volume. The volume on disk contains ciphertext, but the encryption logic is coupled to the application code. Changing encryption keys requires application-level re-encryption. Compliance teams frequently reject this model because it places the encryption implementation burden on application developers rather than infrastructure operators, creating inconsistency across services.
Kubernetes node encryption (dm-crypt / LUKS): a device-mapper layer on the Kubernetes node encrypts data before it reaches the PVC mount path. The weakness is that keys are managed per node, and rotating keys across a cluster requires coordinated node-level operations. This approach also does not encrypt data that has already left the node on its way to a remote storage system, leaving the network path unprotected.
Host full-disk encryption: the physical disks in the storage cluster are encrypted at rest. This protects against hardware theft but does not protect data in transit between the compute node and the storage cluster, nor does it satisfy auditors who require key management to be separate from the storage infrastructure.
Storage-layer encryption: the storage system encrypts each volume’s data before persisting it and fetches keys on demand from an external KMS such as HashiCorp Vault. Every byte written to a persistent volume is encrypted at the storage layer, regardless of what the application does or which node the pod runs on. Keys are never stored in the storage system: they are retrieved from Vault at volume mount time and held in memory only for the duration of the mount.
Encryption Method Comparison for Kubernetes Workloads
The table below compares these four approaches on the dimensions that matter most for compliance and day-to-day operations:
| Encryption method | Where keys live | Application changes required | Covers network path | Compliance fit |
|---|---|---|---|---|
| Application-level | App secrets / Vault (app-managed) | Yes | Depends on TLS | Partial (PCI possible, SOC 2 incomplete) |
| Kubernetes node (dm-crypt / LUKS) | Node secrets | None | No | Partial (rest-at-node only) |
| Host full-disk encryption | Storage host OS | None | No | Partial (physical disk only) |
| Storage-layer + Vault KMS | HashiCorp Vault or OpenBao (external) | None | Yes | Strong (PCI DSS, SOC 2, sovereign cloud) |
Table 1: Encryption method comparison for Kubernetes persistent volumes.
Storage-layer encryption with an external KMS satisfies the strongest compliance requirements because the encryption boundary is at the storage system itself. No data leaves the storage system unencrypted, the keys are managed by a separate system under strict access control, and neither the Kubernetes node nor the application can decrypt data without a valid key response from Vault.
Encrypting Kubernetes persistent volumes for PCI DSS or SOC 2 compliance? simplyblock’s NVMe/TCP block storage encrypts volumes at the storage layer with Vault KMS integration, so no application changes are needed and no plaintext data traverses the network path. Talk to a storage architect
How Vault KMS Integration Works for Kubernetes Storage Encryption
HashiCorp Vault (and its open-source equivalent OpenBao) are the supported key management backends for simplyblock. The integration requires mTLS to be enabled on the simplyblock deployment first: cert-manager must be installed with a working ClusterIssuer or Issuer, and mTLS is activated via the Helm values tls.enabled: true and tls.mutual_enabled: true. Once mTLS is active, the simplyblock operator automatically creates a ClusterIssuer named simplyblock-certificate-authority-issuer, which serves as the internal CA for all component certificates.
The Vault KMS integration works through the following sequence:
Authentication setup: A cert-manager Certificate resource references the simplyblock-certificate-authority-issuer CA and requests a certificate with the Vault service DNS SANs. Vault’s cert auth method is configured to accept client certificates signed by this CA, with a DNS SAN constraint of simplyblock-webappapi. This establishes mutual TLS: simplyblock’s control plane presents its client certificate, and Vault verifies it against the registered CA. No static API tokens or service account credentials are required.
Vault configuration: Two secret engines are enabled under the simplyblock/ path: the transit engine (for key wrapping and unwrapping operations) and the kv engine (for encrypted metadata storage). A policy grants the simplyblock component read/write access to both paths. The Vault endpoint is registered on the StorageCluster resource via spec.hashicorpVaultSettings.base_url.
Volume provisioning: When a new encrypted persistent volume is created, the storage system requests a data encryption key (DEK) from Vault’s Transit engine. Vault wraps the DEK using the named key (envelope encryption) and returns the wrapped DEK. The storage system stores the wrapped DEK in the KV engine alongside the volume metadata, never the plaintext key. Encryption must be specified at volume creation time: existing volumes cannot be retroactively encrypted.
Volume mount: When a pod mounts the volume, the storage system retrieves the wrapped DEK from the KV engine and sends it to Vault’s Transit engine for unwrapping. Vault verifies the mTLS client certificate, unwraps the DEK, and returns the plaintext DEK. The storage system uses the DEK to decrypt I/O for the duration of the mount. The DEK is held in memory only and is never written to disk in plaintext.
Key rotation: Rotating encryption keys in Vault is independent of the application and requires no pod restarts. The storage system re-wraps existing DEKs on the next mount cycle. Applications see no interruption.
The diagram below shows the key flow from a pod write through to the Vault KMS:
simplyblock: NVMe/TCP Volumes with Storage-Layer Encryption
simplyblock provisions Kubernetes persistent volumes over NVMe/TCP using a standard CSI driver. Each logical volume is a thin-provisioned block device served from a disaggregated storage cluster. Storage-layer encryption integrates with Vault so that every block device is encrypted before data is written to the underlying NVMe media.
Key characteristics of this approach:
No application changes: encryption is transparent to the pod. The application writes to a standard block device; the storage system handles all encryption and decryption operations without the application being aware they exist.
Per-volume keys: each logical volume has its own DEK, wrapped by a Vault key. Compromising one volume’s wrapped DEK does not expose data on any other volume.
Certificate-based mutual TLS auth: simplyblock authenticates to Vault using mTLS, not static API tokens or Kubernetes service accounts. The simplyblock operator’s internal CA (simplyblock-certificate-authority-issuer) issues a client certificate for the simplyblock-webappapi component. Vault’s cert auth method validates this certificate against the registered CA with a DNS SAN constraint, so only the legitimate simplyblock control plane can request key operations. Both HashiCorp Vault and OpenBao (the open-source equivalent) are supported backends.
Disaggregated architecture: because the storage cluster is separate from the compute nodes, the Kubernetes scheduler can place pods on any node without storage constraints tied to specific hosts. There is no hyperconverged local disk that needs per-node encryption management. The encryption policy is enforced uniformly at the storage layer, across every volume, regardless of which node the workload runs on.
NVMe/TCP fabric: data written from a Kubernetes node to the storage cluster travels over a standard Ethernet network. It is encrypted at the storage layer before being persisted, so there is no window during which plaintext data exists on the network segment between a write acknowledgment and the physical storage write.
Compliance Requirements Met at the Storage Layer
Several compliance frameworks have specific requirements for persistent volume encryption that storage-layer encryption satisfies more completely than application-level or node-level approaches.
PCI DSS requirement 3.5 requires that primary account numbers are protected wherever stored. Storage-layer encryption covers the full storage path for any volume holding payment data. No account number is ever written to disk in plaintext, regardless of whether the application itself uses TLS or field-level encryption.
SOC 2 Trust Service Criteria CC6.1 requires that data at rest is protected by encryption. Auditors increasingly require evidence that encryption is implemented at the infrastructure layer (not just the application layer) and that key management operates under separate administrative control. Vault KMS satisfies the separate administrative control requirement directly: the team that manages Vault is distinct from the team that manages the storage cluster.
Sovereign cloud and data residency: deployments in regulated jurisdictions (Germany, France, Switzerland, US FedRAMP) often require that encryption keys are managed within the jurisdiction and that no plaintext data crosses a geographic boundary. Vault’s multi-datacenter deployment model, combined with storage-layer encryption on disaggregated NVMe/TCP volumes, allows teams to place both the storage cluster and the Vault instance within the required geographic boundary. Kubernetes compute nodes can run in different availability zones; only ciphertext moves across any boundary between storage and compute.
HIPAA Security Rule (45 CFR §164.312(a)(2)(iv)): the addressable encryption requirement for data at rest is satisfied at the infrastructure level, removing the burden from individual application teams. Each application team does not need to implement its own encryption; it inherits the storage-layer guarantee automatically.
Questions and Answers
What is the difference between Kubernetes PVC encryption and application-level encryption?
Kubernetes PVC encryption at the storage layer encrypts the entire block device at the storage system before any data is persisted. Application-level encryption encrypts specific data fields inside the application before writing to the volume. Storage-layer encryption covers all data written to the PVC, regardless of the application’s behavior, and requires no application code changes. Application-level encryption requires each development team to implement and maintain encryption logic independently, which creates inconsistency across services.
How does Vault KMS work with Kubernetes persistent volumes?
When a new encrypted volume is provisioned, the simplyblock storage system requests a data encryption key (DEK) from Vault’s Transit secrets engine. Vault returns a wrapped DEK using envelope encryption. The wrapped DEK is stored in Vault’s KV engine alongside the volume metadata. On each mount, the storage system retrieves the wrapped DEK and asks Vault to unwrap it. Vault authenticates simplyblock via mutual TLS: the simplyblock control plane presents a client certificate issued by the operator’s internal CA, and Vault validates it against the registered cert auth method. The plaintext DEK exists only in memory for the duration of the mount and is cleared on unmount.
Does simplyblock support encryption for NVMe/TCP volumes?
Yes. simplyblock encrypts each logical NVMe/TCP persistent volume at the storage layer, with per-volume keys wrapped by a Vault or OpenBao KMS instance. Encryption is transparent to the pod and requires no application changes. Authentication to Vault uses mutual TLS: the simplyblock operator’s internal CA issues a client certificate for the simplyblock control plane, and Vault validates it via cert auth. mTLS must be enabled on the simplyblock deployment (via cert-manager) before the Vault integration can be activated. Encryption is set at volume creation time and cannot be added to existing volumes retroactively.
Which compliance frameworks require Kubernetes storage encryption?
PCI DSS (requirement 3.5), SOC 2 Trust Service Criteria (CC6.1), HIPAA Security Rule (45 CFR §164.312), and sovereign-cloud frameworks for regulated EU and US government jurisdictions all have requirements that storage-layer encryption satisfies. The key differentiator for compliance auditors is that keys are managed under separate administrative control in Vault, not by the storage system or by the application.
Does encryption affect NVMe storage performance in Kubernetes?
simplyblock implements encryption using AES-XTS, a variable-length block cipher well suited to storage workloads, via SPDK’s crypto bdev layer. AES-XTS benefits from hardware acceleration on current server CPUs, keeping encryption overhead below measurement noise in standard production benchmark runs. Applications writing to encrypted volumes observe the same throughput and latency characteristics as unencrypted volumes, because the cryptographic operations are handled at the storage layer rather than in the application’s CPU path.
