Data security is an important consideration for any storage environment, especially when storage is shared across multiple hosts, applications, or tenants. Lightbits provides high-performance NVMe/TCP block storage and includes native encryption capabilities for protecting data within the Lightbits storage platform.
In addition to the built-in Lightbits encryption feature, some environments may prefer to use an external Key Management Server (KMS) as part of their own security architecture. This can be useful when an organization already has a centralized key management strategy, requires separation of duties between storage administration and key management, or wants encryption to be enforced at the host level before data is written to the storage system.
In this test, I validated an optional host-side encryption workflow using a Lightbits NVMe/TCP volume, Linux LUKS/dm-crypt, and a PyKMIP-based external KMS server. The purpose of this test was not to replace the native Lightbits encryption feature, but to demonstrate that Lightbits volumes can also be used with an external KMS-based encryption model when customers choose to manage encryption outside of the Lightbits cluster.
With this approach, the Lightbits cluster continues to provide the NVMe/TCP block volume, while encryption and decryption are performed on the client host. The encryption key is stored externally in the KMS and retrieved by the client when the encrypted volume needs to be unlocked.
Test Architecture
The test environment used three main components:
- Lightbits cluster
The Lightbits cluster provided the NVMe/TCP block volume. - LUKS/KMIP client host
The client host connected to the Lightbits volume over NVMe/TCP. It also ran the PyKMIP client logic and used Linux cryptsetup/dm-crypt to encrypt and unlock the device. - External KMS server
A PyKMIP server acted as the external KMS. It stored the AES-256 key encryption key, identified by a UUID, and served the key to the client over KMIP/TLS.
PyKMIP KMS with Lightbits Volume Architecture
What Was Tested
For this test, I connected a Lightbits volume to a Linux host using NVMe/TCP. Once the volume appeared as a local NVMe block device on the client, I configured it with LUKS2 encryption.
Instead of manually entering a passphrase, the encryption key was stored in the external PyKMIP KMS server. The client retrieved the key over KMIP/TLS and passed it to LUKS to format and unlock the Lightbits volume.
Here is an example of the unlocked volume:
[root@client ~]# cryptsetup status lightbitsvol
/dev/mapper/lightbitsvol is active.
type: LUKS2
cipher: aes-xts-plain64
keysize: 512 [bits]
key location: keyring
device: /dev/nvme12n1
sector size: 4096 [bytes]
offset: 32768 [512-byte units] (16777216 [bytes])
size: 97623488 [512-byte units] (49983225856 [bytes])
mode: read/write
After unlocking the encrypted device, it appeared as a dm-crypt mapper device on the host. I then created a filesystem on top of the encrypted device, mounted it, and successfully wrote and read test data from the mounted filesystem.
At a high level, the workflow looked like this:
Lightbits NVMe/TCP volume
↓
Linux client discovers and connects to the volume
↓
Client retrieves encryption key from external KMS
↓
LUKS/dm-crypt unlocks the block device
↓
Filesystem is created and mounted
↓
Applications read and write data normally
Why This Matters
This approach separates storage from key management.
The Lightbits cluster provides the block storage volume, but the encryption key is managed externally by the KMS. This means the storage system does not need to store or manage the key used to unlock the encrypted filesystem. The client must retrieve the correct key from the external KMS before the encrypted volume can be accessed.
When using host-side encryption with Lightbits volumes, it is also recommended to create the Lightbits volume as a non-compressed volume. Encrypted data is intentionally randomized, which means it typically does not compress well. As a result, enabling storage-side compression on encrypted data is unlikely to provide meaningful space savings and may add unnecessary processing overhead.
This model is useful for environments that require centralized key management, stronger separation of duties, or integration with existing security policies. It also allows organizations to maintain control over encryption keys independently from the underlying storage infrastructure.
Host-Side Encryption Model
In this test, encryption was performed on the client host using LUKS/dm-crypt. From the Lightbits cluster perspective, the volume is just a standard NVMe/TCP block device. The Lightbits system does not need to understand the filesystem, the encryption layer, or the KMS workflow.
The encryption and decryption happen on the client side:
Application
↓
Filesystem
↓
LUKS / dm-crypt
↓
Lightbits NVMe/TCP volume
↓
Lightbits cluster
This means data written to the Lightbits volume is already encrypted before it reaches the storage layer. When the client reads data back, dm-crypt decrypts it after retrieving the encrypted blocks from the Lightbits volume.
Role of the External KMS
The external KMS stores the encryption key and makes it available to authorized clients over KMIP/TLS. In this test, PyKMIP was used as the KMS implementation.
The key was identified by a UUID. The client used that UUID to retrieve the correct key from the KMS, then used the key to unlock the LUKS device.
This creates a clean separation:
| Component | Responsibility |
|---|---|
| Lightbits | Provides the NVMe/TCP block volume |
| Linux client | Connects to the volume and performs encryption/decryption |
| LUKS/dm-crypt | Provides the encryption layer |
| PyKMIP KMS | Stores and serves the encryption key |
| Filesystem | Runs on top of the unlocked encrypted device |
Validation Result
The test confirmed that a Lightbits NVMe/TCP volume can be used with host-side LUKS encryption while retrieving the encryption key from an external KMIP-compatible KMS.
After the Lightbits volume was unlocked through LUKS, the encrypted mapper device became available to the operating system. I was able to create an XFS filesystem, mount it, write a test file, sync the data, and read the file back successfully.
This validated the end-to-end workflow:
External KMS key retrieval → LUKS unlock → Filesystem mount → Read/write test
Key Takeaways
Using an external KMS with a Lightbits volume is possible through a host-side encryption model. Lightbits continues to provide high-performance NVMe/TCP block storage, while Linux LUKS/dm-crypt handles encryption on the client.
The external KMS provides centralized key management and keeps encryption keys separate from the storage platform. This can be valuable for organizations that need stronger security controls, operational separation, or alignment with enterprise key management practices.
In this PyKMIP test, the Lightbits volume behaved like any other NVMe block device from the client’s perspective. Once the volume was connected, the encryption workflow was handled entirely by the Linux client and the external KMS.
Conclusion
This test demonstrated a flexible encryption architecture using Lightbits for NVMe/TCP block storage, Linux LUKS/dm-crypt for host-side encryption, and PyKMIP as an external KMS.
Lightbits already provides native encryption capabilities within the storage platform. However, for customers who prefer to use their own external KMS or enforce encryption at the host layer, this test shows that a Lightbits volume can also support that model. In this configuration, the encryption key is managed outside of the Lightbits cluster, while the Lightbits volume continues to behave like a standard high-performance NVMe/TCP block device.
The result is an encrypted Lightbits-backed filesystem where data is protected before it reaches the storage layer, and key management remains under the control of the external KMS.