Applies to SUSE Enterprise Storage 7.1

7 Confidentiality #

Confidentiality is a common requirement. There are diffent ways of ensuring data stays confidential at different times of its lifecycle.

7.1 Data at rest #

The data stored in OSDs is not encrypted by default. If you have high confidentiality requirements, we recommend that you encrypt the storage that you provide SUSE Enterprise Storage for use. This protects the data if a disk is stolen or when you decommission disk drives.

The easiest way to do this is to enable disk encryption directly when you install the system. The SUSE installer allows you to create encrypted partitions.

Alternatively you can use cryptsetup to encrypt individual partitions: cryptsetup LuksFormat --key-size 256 /dev/sda1 allows you to create an encrypted partition that you can open with cryptsetup luksOpen /dev/sda1 osd_data. The resulting osd_data device can then be given to SUSE Enterprise Storage to store data that will be transparently encrypted.

This only protects data if the disk is offline. To protect data at rest when the system is running you can use client-side encryption.

For RADOS Block Device, you can encrypt the block device at the client (such as, cryptsetup).
For CephFS you can you file level encryption (such as, EncFS).
For RADOS, you need to encrypt the data in the application before storing it via the REST interface.

With this the data is encrypted on the client and is never available in cleartext on SUSE Enterprise Storage. This also protects in case the transport protocol is either not encrypted or an attacker manages to circumvent the transport encryption.

7.2 Data in flight #

When creating services on you SUSE Enterprise Storage cluster you should enable encryption if possible. For example, RADOS can communicate via HTTP or HTTPs. Configure it to use HTTPs and use certificates that can be checked by the client.

If possible, do not use self signed certificates. Either use certificates signed by trusted authorities or create your own PKI to issue trusted certificates. Using self signed certificates is better than using plaintext protocols, but it can still allow attackers to get between the communicating nodes.

To secure the communication within the SUSE Enterprise Storage cluster you have several options:

You can use a dedicated network that is not reachable externally. Depending on your security needs and regulatory requirements that can be acceptable.
You encrypt the links connecting the SUSE Enterprise Storage machines with an external mechanism, for example using IPsec to setup secure tunnels between the machines that takes care of encryption.
You use the encryption capabilities in msgr2.

On fresh SUSE Enterprise Storage installs msgr2 is available, which also allows for transport encryption for data. Unfortunately, many clients still do not support this, but Ceph clients using librbd starting with Nautilus can lready benefit from this.

The previous message protocol had no guarantee of data authenticity or data encryption. msgr2 uses port 3300, port 6789 is used for the old version. When you want to make sure that only msgr2 is used you can block 6789 to guarantee that the old protocol will not be used.

The default configuration allows SUSE Enterprise Storage to use CRC mode for msgr2. You can check this with:

cephuser@adm > for option_name in ms_cluster_mode ms_service_mode ms_client_mode; do
        echo -n "$option_name: "
        ceph config get mon $option_name
      done
    ms_cluster_mode: crc secure
    ms_service_mode: crc secure
    ms_client_mode: crc secure

Currently only clients build on librbd support secure mode, but the kernel client does not. You can set secure mode only for the cluster internal communication by setting the ms_cluster_mode option to secure. If you have a client landscape that allows you to enforce secure mode you can also set the ms_service_mode and ms_client_mode options to secure.

This might cause performance issues for your setup, so you need to test this first. If you run into performance issues you can enable secure mode only for select daemons, for example if the ms_cluster_mode option allows you to force secure mode for Ceph Monitor while keeping a different setting for other services.