6 Authentication #
Ensuring that clients need to authenticate before accessing ressources on SUSE Enterprise Storage is important to the security of the system. Allowing anonymous usage or weak authentication schemes should be avoided.
6.1 Enabling strong 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
30.1項 「認証アーキテクチャ」.
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 20.2.1項 「Cephユーザアカウントの作成」.
6.2 Ensuring secure storage of keys #
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.
6.3 Account setup #
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.