6 Authentication #

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 Abschnitt 30.1, „Authentifizierungsarchitektur“.

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 Abschnitt 20.2.1, „Erstellen eines Ceph-Benutzerkontos“.

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.