In the fast-paced world of Kubernetes, mobility and high-performance data access are often the top priorities. However, as we disaggregate storage from compute using protocols like NVMe® over TCP (NVMe/TCP), and data travels over a network, encryption becomes no longer an optional luxury but a security fundamental.
Lightbits provides a powerful, high-speed way to secure your data without sacrificing the high-performance benefits of NVMe.
What is Encryption “On the Wire”?
Encryption on the wire (or Encryption in Transit) ensures that data is scrambled into an unreadable format before it leaves the source and is only decrypted once it reaches its destination.
In a Kubernetes (or RHOCP) with Lightbits software-defined storage implementation, this means protecting the data blocks as they move from your Worker Node (the “Host”) to the Lightbits cluster. This prevents “man-in-the-middle” attacks in which someone on the same network could potentially sniff TCP packets to reconstruct your sensitive database records.
Cluster-Level Security: Encryption at Rest
While securing on the wire protects data in motion, you can also utilize cluster-level software encryption for your data stored on drives (encryption at rest). This ensures that if any physical drive is removed from the Lightbits cluster, the data on it remains encrypted and cannot be read as plain text.
How it Works: AES-XTS-256
Lightbits uses industry-standard AES-XTS-256 to secure your data. To provide maximum security with manageable overhead, the system uses a two-tier key hierarchy:
- Data Encryption Key (DEK): Each volume has a dedicated DEK to encrypt its data.
- Key Encryption Key (KEK): A separate cluster-level KEK encrypts all the DEKs.
This architecture reduces the attack surface and allows for frequent rotation of the KEK without the massive performance hit of re-encrypting all stored data. These keys are protected using the servers’ Trusted Platform Modules (TPMs) or via software encryption.
Requirements and Activation
This feature is built for high-integrity environments but requires specific planning:
- Version: Requires installing a Lightbits cluster with software version 3.12.1 or higher.
- Activation: It can only be enabled if the newly installed cluster has no volumes or snapshots.
- Permanence: Once activated, cluster encryption cannot be disabled.
For detailed implementation, you can refer to the lbcli enable cluster-encryption command and the Lightbits REST API documentation.
How Lightbits Handles Encryption via CSI
The Lightbits Container Storage Interface (CSI) driver simplifies this by allowing you to define your security requirements directly in your Kubernetes manifests. There are two primary ways to approach this:
1. Host-Side Encryption (The “Wire” Focus)
With host-side encryption, the encryption happens on the Kubernetes worker node itself. Before the data is even handed off to the network stack for transmission to Lightbits block storage, it is encrypted.
- How it works: The CSI driver uses a Linux kernel-level encryption module (like dm-crypt).
- The Key: A Kubernetes Secret holds the encryption passphrase.
- The Benefit: Total end-to-end security. Even the storage administrators at the backend cannot see plaintext data, as it arrives at the Lightbits cluster already encrypted.
2. Management Path Security (TLS)
Beyond the data itself, the “Control Plane” (where Kubernetes tells Lightbits to “create a volume”) is secured using GRPC over TLS (GRPCS). This ensures that even the commands to manage your storage are encrypted and authenticated using JWT tokens.
Step-by-Step: Implementing Encrypted Storage
First, we store the passphrase used to lock/unlock the volumes.
YAML
2. Define the StorageClass
Next, you create a StorageClass. This tells the Lightbits CSI driver, “Every time a developer asks for this type of storage, make sure it’s encrypted using the secret we just made.”
YAML
3. Claim your Secure Volume
Now, any user can create a PersistentVolumeClaim (PVC) referencing that StorageClass. The magic happens behind the scenes: when the Pod starts, the CSI driver fetches the secret, sets up the encrypted tunnel, and mounts the volume.
The Performance Trade-off
“Doesn’t encryption slow things down?” Everyone asks this.
Because Lightbits leverages NVMe/TCP, it’s already built for extreme efficiency. When using modern CPUs (such as those with AES-NI instructions), the overhead for encryption on the wire is remarkably low—often in the low single digits.
Pro Tip: If you use host-side encryption, remember that backend data reduction (like compression on the Lightbits cluster) will be less effective. Why? Because encrypted data appears like “random noise” to compression algorithms, it’s nearly impossible to shrink.
Summary
Encryption on the wire with Lightbits and CSI provides a “set and forget” security model for Kubernetes. By offloading the complexity to the CSI driver and Kubernetes Secrets, you can ensure that your data is safe from the moment it leaves the application until it lands on the flash drives. For more information about this and other benefits Lightbits can provide your k8s or OCP environment, reach out to us.