Encryption

IBM Fusion Data Foundation allows encryption of the stored data (data at rest) by using the common Linux Unified Key Setup (LUKS2). Two levels of granularity are possible.

  • OSD level: an entire storage device is encrypted
  • PV level: a specific persistent volume (used by an application) is encrypted individually

For an OSD level encryption, the keys that are used for the encryption process can be stored either internally or externally.

  • Internal key management is done within the Red Hat OpenShift cluster. For this purpose, the key is stored as a name-value-pair inside the Red Hat OpenShift etcd database.
  • External key management can be provided by a 3rd-party keystore, such as HashiCorp vault.

An external key management solution is preferred because it ensures a clear separation between the keys and the protected data.

For a PV-level encryption, external key management is mandatory. In this case, it is not possible to store keys internally inside the etcd database. The PV level encryption allows scoping the encryption process to specific persistent volumes used by an application. This allows an instance to protect one application (or tenant) from another. IBM Fusion Data Foundation has solved the separation between the persistent volumes, by creating a set of storage classes for each PV/tenant and assigning keys specifically to a storage class.

Note:
  • Currently, only RBD block storage is supported for PV level encryption. Support for the other storage classes will be available in a future release.
  • When storing keys internally, it is important to secure and backup the etcd database correctly!
Figure 1. Encrypting storage
The content of this image is explained in the surrounding text.