As with any other system it is important that you practice proper security hygiene for you SUSE Enterprise Storage installation. This includes monitoring a suitable channel for security notices (https://www.suse.com/security/cve/) and incorporate this in your security tracking.

It is mandatory that you install updates in a timely manner. If available, you can use threat intelligence to guide you in your update strategy, but the sooner you install updates the better. Most organizations do not get hacked via 0-day exploits but through long known security issues. If you keep your cluster current you improve the security posture dramatically.

Installing updates in a SUSE Enterprise Storage context means that you keep the base operating system and the SUSE Enterprise Storage images up to date. For the base operating system you can either use basic command line tools like zypper or use SUSE Manager to conveniently manage a large fleet of machines. Refer to Book “Administration and Operations Guide”, Chapter 13 “Operational tasks”, Section 13.7 “Updating Ceph” on how to keep the SUSE Enterprise Storage images up to date.

Ensuring that the base system is hardened is helping to provide a proper base for further hardening measures more specific to SUSE Enterprise Storage. SUSE published a hardening guide for SUSE Linux Enterprise Server at https://documentation.suse.com/de-de/sles/15-SP1/html/SLES-all/book-hardening.html. As SUSE Enterprise Storage is based on SUSE Linux Enterprise Server this contains tips that you can incorporate in your security strategy. For example, we recommend that you ensure that the systems that host SUSE Enterprise Storage are physically secure and that the boot process is protected is important to have a solid base for futher hardenings.

We also recommend that you do not add any other workloads on the machines that you use for you SUSE Enterprise Storage cluster. Not only can this negatively impact the performance of your SUSE Enterprise Storage cluster, but you also introduce additional risk to your data. If an attacker is able to exploit a vulnerability in the unrelated workload, they may be able to use this access to compromise your SUSE Enterprise Storage cluster.

If you have a virtualized environment and can easily provision machines, we recommend using one machine for each role. Especially the Ceph Monitor should be stand-alone as they have access to all the key material and running other services on them increases their risk profile.

Without visibility into you systems it is tough to ensure that they run in a secure state. You have to either monitor the SUSE Enterprise Storage cluster itself or hook it into your existing monitoring framework to ensure that you are aware of changes in the cluster. This mainly helps with availability, but is also important for other security goals. For example, you need to notice if someone is trying to brute force credentials on the machines by collecting and analyzing the logs showing this behavior.

You should at least include /var/log/ceph/cephadm.log into your log analysis setup to make sure you notice changes on your SUSE Enterprise Storage cluster.

Enforce strong authentication whenever possible: cephx works by having a secret key shared between the client and the service. This way both sides can prove to each other that they are who they claim to be. cephx is the default authentication scheme and should not be replaced by weaker methods.

cephx is enabled by default for communication in the cluster itself (auth_cluster_required) and for the communication between the client and the cluster (auth_service_required). You can check this by running the following:

cephuser@adm > for option_name in auth_cluster_required auth_service_required auth_client_required ; do
        echo -n "$option_name: "
        ceph config get mon $option_name
      done
    auth_cluster_required: cephx
    auth_service_required: cephx
    auth_client_required: cephx, none

You can also enable auth_client_required to force the SUSE Enterprise Storage cluster to authenticate towards clients to prevent malicious actors from impersonating services. This is done by setting auth_client_required to cephx only with the ceph config set global auth_client_required cephx command.

cephx is only concerned with authentication. It does not ensure that the data is encrypted when sent to the cluster (in transport) or when stored in the cluster (at rest). When chosing a way for clients to access the cluster, select a access method that ensures the confidentiality in transport (for example, use HTTPS when using RADOS). For more details about cephx, see Book “Administration and Operations Guide”, Chapter 30 “Authentication with cephx”, Section 30.1 “Authentication architecture”.

You can enforce message signing to harden the authentication protocol. With the ceph config set global cephx_require_signatures true command, you can force that signatures are used on all messages between the client and the cluster and in between the daemons in the cluster.If you run into issue with clients not being able to properly sign their messages you can enable it only for use within the cluster with the ceph config set global cephx_cluster_require_signatures command.

Strong authentication also requires proper key handling from the creation to the destruction of keys. Each client should receive a separate key which shouldn't be reused, at least not for clients with different security properties. With that you can then give the least amount of privileges to each account that is necessary, therefor limiting the risk. Creating users is covered in Book “Administration and Operations Guide”, Chapter 20 “RADOS Block Device”, Section 20.2.1 “Creating a Ceph user account”.

Keys must be stored with safe permissions on the client machine to prevent credential leakage. In most cases this means that only the user and root is able to read the key material. If you have a setup where you need to provide broader access you need to think through the security implications that accidential or malicious leaks of the key material has in your environment.

By default, key material is stored in a safe way on SUSE Enterprise Storage and you need to make sure that you do the same when transferring key material to clients. This means that you use secure transport mechanisms (HTTPs, SSH) to transfer the key and set strict permissions of files storing key material. Depending on your security requirements the use of vault services or hardware security modules might be appropriate.

Also consider your backup scheme to ensure that keys are secure during the whole life cycle. The backup of keys must meet the same security standards as the other systems that store a key dufing its lifetime.

In the initial configuration, you have administrative accounts that hold all the power. Depending on your regulatory and other requirements, you need to split up these accounts into several accounts that hold different privileges. This allows to assign the least amount of privilege needed to fulfill a task.

You should create a process that regularly reviews the privileges users have and adjust them if necessary. Especially for highly privileged accounts, we recommend this happens on a regular basis and every time a user that could have modified these settings is removed from the settings. For example, if someone changes role and is not the administrator for SUSE Enterprise Storage anymore.

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.

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.

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:

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.