Kubernetes storage encryption protects PersistentVolume data at rest using LUKS/dm-crypt on block devices, CSI-level encryption hooks, or KMS-backed key management integrated with Kubernetes Secrets. While Kubernetes natively encrypts etcd contents (including Secrets), it does not encrypt volume data at rest by default — that responsibility falls on the storage layer, the CSI driver, or the application itself.
Compliance frameworks that govern financial data (PCI-DSS), health records (HIPAA), and cloud security audits (SOC 2) uniformly require encryption of data at rest. For Kubernetes stateful workloads, this means volumes containing database files, message queue logs, and application state must be encrypted before data reaches physical media. The storage platform or CSI driver is the most operationally efficient place to implement this — encryption configured once in a StorageClass applies consistently to every PVC provisioned from it.
How Kubernetes Storage Encryption Works
Kubernetes itself handles Secret encryption at rest in etcd through the EncryptionConfiguration API resource, which protects Kubernetes Secret objects but has no effect on PersistentVolume data stored on block devices. Volume encryption requires action at a different layer.
The most common implementation for block volumes is LUKS (Linux Unified Key Setup) with dm-crypt. The CSI driver provisions a raw block device and applies a LUKS header before presenting the volume to the pod. The encryption key is fetched from a key management service — either a Kubernetes Secret, an external KMS (AWS KMS, HashiCorp Vault, Azure Key Vault), or a hardware security module. The pod writes to what appears to be a normal block device; encryption and decryption happen transparently in the kernel dm-crypt layer.
StorageClass parameters are the standard Kubernetes mechanism for specifying that volumes provisioned from a given class should be encrypted. A StorageClass with encrypted: "true" and a reference to a KMS key ID instructs the CSI driver to apply LUKS encryption on every volume it creates from that class.
Encryption Approaches Compared
| Approach | Where encryption happens | Key management | Performance impact | Kubernetes integration |
|---|---|---|---|---|
| CSI driver encryption (LUKS) | Block device layer, in kernel dm-crypt | Kubernetes Secret or external KMS | 5–15% throughput overhead typical | StorageClass parameter, transparent to pods |
| Filesystem encryption (fscrypt) | Filesystem layer, per-directory | Kernel keyring, less KMS-friendly | Similar to dm-crypt | Requires node configuration, not CSI-standard |
| Application-level encryption | Inside the application process | Application manages keys | Depends on algorithm and CPU | No storage layer involvement |
CSI driver encryption is preferred for Kubernetes environments because it is transparent to applications, configurable per StorageClass, and integrates with external KMS systems for audit logging and key rotation.
🚀 Storage encryption without application changes Simplyblock supports volume encryption via StorageClass parameters — enable LUKS encryption with KMS key management for every PVC, transparently to your workloads. 👉 Persistent storage for Kubernetes with enterprise security features
Key Management for Kubernetes Storage Encryption
Key management is where volume encryption becomes operationally complex. Storing encryption keys in Kubernetes Secrets is simple but creates a circular dependency: if etcd Secret encryption is not enabled, the key protecting the volume is itself unencrypted. For compliance purposes, externalized KMS is the recommended approach.
External KMS systems — HashiCorp Vault, AWS KMS, Azure Key Vault, Google Cloud KMS — provide centralized key storage, audit logging of key usage, and support for automated key rotation. Kubernetes Secrets for storage credentials can store references to KMS keys rather than raw key material, reducing the risk of key exposure through Kubernetes RBAC misconfiguration.
Key rotation is a compliance requirement under PCI-DSS and HIPAA for encryption keys protecting cardholder or patient data. CSI drivers that support key rotation re-encrypt volumes with new keys without requiring volume deletion and recreation. This capability should be validated as part of CSI driver selection when compliance is a requirement.
Compliance Considerations for Encrypted Kubernetes Volumes
PCI-DSS requires encryption of cardholder data at rest with strong cryptography and key management controls. HIPAA requires that electronic protected health information stored on systems be protected through access controls and, for portable or shared media, encryption. SOC 2 Type II audits evaluate whether encryption controls are consistently applied and can be demonstrated through audit logs.
For Kubernetes storage, auditors typically want to confirm: that volumes containing sensitive data are encrypted in the StorageClass configuration, that key management is externalized and auditable, that key rotation has been performed and documented, and that encryption applies to all volumes including snapshots and clones. The CSI driver must support encrypted snapshots — a snapshot of an encrypted volume should itself be encrypted with the same or a successor key.
How Simplyblock Implements Kubernetes Storage Encryption
Simplyblock supports volume encryption via StorageClass parameters, using LUKS dm-crypt to encrypt block volumes at rest before data reaches physical NVMe media. Encryption is handled within the storage data path: the application pod communicates with the volume over NVMe/TCP or NVMe/RoCE, and encryption happens at the storage node before writes persist to drive. This ensures that data is encrypted at rest regardless of whether the NVMe drive is removed from the server.
Key management integrates with external KMS systems through the CSI driver, enabling audit-logged key access and rotation without application changes. Encryption policy is set in the StorageClass and applies uniformly to every PVC provisioned from it — there is no per-PVC configuration step that could be accidentally omitted. Snapshots and clones inherit the encryption state of the source volume, satisfying the compliance requirement that data protection persists through storage operations.
For teams targeting storage QoS alongside encryption, simplyblock applies both in the same data path: QoS policies and encryption operate as independent layers without requiring separate volume classes for encrypted vs. unencrypted workloads.
Related Terms
These glossary entries cover the components and Kubernetes concepts that interact with storage encryption.
- StorageClass
- Kubernetes Secrets for Storage Credentials
- CSI Driver
- What Is Storage Quality of Service
- PersistentVolumeClaim
Questions and Answers
How does Kubernetes encrypt PersistentVolume data?
Kubernetes itself does not encrypt PersistentVolume data at rest by default. Volume encryption is implemented by the CSI driver or storage platform. The most common approach is LUKS/dm-crypt: the CSI driver applies a LUKS header to a raw block device during provisioning, fetches an encryption key from a Kubernetes Secret or external KMS, and presents the decrypted volume to the pod. All writes pass through dm-crypt in the kernel before reaching physical media, and all reads are decrypted transparently. This approach is configured once in a StorageClass and applies to every PVC provisioned from that class.
What is the difference between volume encryption and Kubernetes Secret encryption?
Kubernetes Secret encryption (configured via EncryptionConfiguration in the API server) protects the contents of Secret objects stored in etcd — things like passwords, tokens, and certificates. It has no effect on PersistentVolume data. Volume encryption (LUKS/dm-crypt via the CSI driver) protects the actual block data stored on disk for database files, message logs, and application state. Both are needed for a complete compliance posture: Secret encryption protects credentials at rest; volume encryption protects the application data those credentials guard access to.
How do I enable storage encryption in a CSI driver?
Enable encryption by setting the appropriate parameters in your StorageClass definition. The exact parameter names vary by CSI driver. A typical approach sets encrypted: "true" and references a KMS key via a driver-specific parameter. The CSI driver reads these parameters at volume creation time and applies LUKS encryption before presenting the volume to the pod. Verify that the CSI driver’s external-provisioner sidecar has the necessary permissions to access the KMS service, and confirm that snapshots created from encrypted volumes are also encrypted by testing the snapshot and restore flow before relying on it for compliance.
Does encryption affect storage performance in Kubernetes?
LUKS/dm-crypt encryption adds CPU overhead for AES operations on every read and write. On modern server CPUs with AES-NI hardware acceleration, this overhead is typically 5–15% in throughput and adds minimal latency compared to the network and storage path costs. For most Kubernetes stateful workloads — databases, message queues, log storage — the performance impact of dm-crypt is not the binding constraint. The exception is extremely CPU-constrained nodes running very high I/O workloads; in those cases, profiling actual throughput with and without encryption before enabling it in production is advisable.