To access the Ceph cluster, an actor/user/application invokes the Ceph client to contact the cluster's monitor node. Usually, a Ceph cluster has more than one monitor, and a Ceph client can connect to any monitor node to initiate the authentication process. This multimonitor architecture of Ceph removes a single point of failure situation during the authentication process.

To use Cephx, an administrator, that is, client.admin, must create a user account on the Ceph cluster. To create a user account, the client.admin user invokes the ceph auth get-or-create key command. The Ceph authentication subsystem generates a username and a secret key, stores this information on the Ceph monitor, and returns the user's secret key to the client.admin user that has invoked the user creation command. The Ceph sys-admin should share this username and secret key with the Ceph client that wants to use the Ceph storage service in a secure manner. The following diagram visualizes this entire process:

In the last recipe, we learned the process of user creation and how a user's secret keys are stored across all the cluster nodes. We will now examine how users are authenticated by Ceph and allowed access to cluster nodes.

In order to access the Ceph cluster, the client first contacts the Ceph monitor node and passes only its username. The Cephx protocol works in such a way that both parties are able to prove to each other that they have a copy of the key without actually revealing it. This is the reason that a client only sends its username, but not its secret key.

The session key for the user is generated by the monitor is encrypted with the secret key associated with that user. The encrypted session key is transmitted by the monitor back to the client. The client then decrypts the payload with its key to retrieve the session key. This session key remains valid for that user for the current session.

Using the session key, the client requests for a ticket from the Ceph monitor. The Ceph monitor verifies the session key and then generates a ticket, encrypted with the user's secret key, and transmits this to the user. The client decrypts the ticket and uses it to sign requests to OSDs and metadata servers throughout the cluster.

The ongoing communications between the Ceph nodes and the client are authenticated by the Cephx protocol. Each message sent between the Ceph nodes and the client, post the initial authentication, is signed using a ticket that the metadata nodes, OSDs, and monitors verify with their shared secret key. Cephx tickets do expire, so an attacker cannot use an expired ticket or session key to gain access to the Ceph cluster. The following diagram illustrates the entire authentication process that has been explained here: