Cluster-Level Encryption

You can utilize cluster-level software encryption for your data stored on drives (encryption at rest), such that if any drive is removed from the cluster, the data on it remains encrypted on the drive and cannot be read as plain text. The data is encrypted using AES-XTS-256. The keys are protected using the servers’ Trusted Platform Modules (TPMs), or using software encryption.

This feature requires installing a cluster with 3.12.1 or higher and can only be enabled if the newly installed cluster has no volumes or snapshots. The feature cannot be disabled once activated. For more information on how to enable and use the feature, see lbcli enable cluster-encryption and the REST API documentation.

The data is encrypted with a Data Encryption Key (DEK), which is in turn encrypted with a Key Encryption Key (KEK). In this way, the cluster can reduce the surface of attack by having a dedicated DEK per volume and a separate cluster-level KEK that encrypts all of the DEKs. The KEK can be rotated frequently without the need to re-encrypt all of the data.

Cluster-Level Encryption Preconditions

• Enable the cluster-encryption feature flag.
• If you plan to use the TPM, you will need to validate that TPM v2.0 is enabled on all servers of the cluster.
• There are no volumes or snapshots on the cluster.
• If you have IP tables or any firewall rules between the servers in the cluster, you will need to allow port 4007 between the servers of the cluster for the encryption feature to work properly.

xxxxxxxxxx

iptables --append INPUT --protocol tcp --dport 4007 --jump ACCEPT

• If you are using firewalld, add the port as follows (note that you will need to restart the firewalld service when finished).

xxxxxxxxxx

firewall-cmd --zone=public --add-port=4007/tcp --permanent

Viewing Cluster-Level Encryption Information

In order to view cluster-level encryption information, you can use the lbcli get clusterinfo (2.2 and above) API.

xxxxxxxxxx

lbcli get clusterinfo -o json

You can also see the same information using:

xxxxxxxxxx

lbcli get cluster -o json

The output you get has a lot of information regarding the cluster. In the encryptionState section, you will see the following (the example below is with encryption enabled and after a few KEK rotations):

xxxxxxxxxx

"encryptionStatus": {

    "encryptionState": "Enabled",

    "kekGeneration": "5",

    "kekUpdateDate": "2025-03-12T12:42:53.420771630Z",

    "previousKekGenerations": ["4"],

    "rotationState": "NoRotation",

  }

EncryptionState

Indicates the encryption state of the cluster-level encryption:

• Disabled
• Enabling(in the process of enabling encryption - this can take from several seconds to up to a few minutes).
• Enabled

previousKekGenerations

Note that this does not always have to be consecutive with the current generation. For example, the current generation could be five and the previous generation could be three. In most cases, it will be consecutive. In addition, with the process of KEK rotation, you might see two previous generations.

rotationState

Indicates the stage of the cluster root key rotation process:

• NoRotationNo rotation is in progress. This is the idle state most of the time.
• DistributingKEKThis is the first stage of cluster root key rotation, where the new KEK is distributed between the cluster components (usually a short process).
• EncryptyingDEKsThe new KEK is already in place and the cluster is in the process of re-encrypting all of the existing DEKs in the cluster. This can take time depending on the number of volumes/snapshots in the cluster.

Disabling Encryption

Once cluster-level encryption has been activated, it cannot be disabled. Doing so would result in a scenario where some data remains encrypted while other data does not. This feature will be available in a future release.

Limitations

1. Encryption cannot be disabled after being enabled.
2. Encryption can only be enabled on clusters with no data (no volumes or snapshots).
3. It is recommended to do a fresh install of v3.12 and above, before enabling encryption.
4. Encryption should not be enabled when the cluster is not fully upgraded to one of the supported versions
5. Encryption will not work properly on clusters configured to use NVRAM journaling.
6. Encryption is currently not supported for systems running ipv6.