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.