The following describes cephx auth extension(s). Note that there is no implementation yet, and your comments are welcome. * Introduction The cephx authentication and authorization is a system in which the ceph principals and ceph clients are able to create secure sessions to [other] ceph principals while validating the identity of their peers. In this auth process, the auth authority (served by the ceph mons) keeps a shared secret database that allows it to provide tickets to access the different services. It is a multi-phase process that was inspired by the kerberos design: when authenticating, the authenticating entities (“clients” although can also be different ceph principals such as osd, mds, etc.) first establish their identities with the mons by leveraging a shared secret mechanism (while the mons are able to affirm their own identity), and are provided with a ticket to access the services that they request access to. The services are able to validate the tickets. This allows them to affirm the client identity, and also to get information about the clients’ permissions, such as what resources they’re allowed to access. There is a mechanism that allows the different principals to have separate secret keys, and a shared rotating key (with other principals of the same type), so that clients can use the same ticket when accessing all similar principals. The issue at hand stems from the fact that the ceph mons that act as the auth authority need to keep the auth information about all the clients in the system. The mons keep this information in their Paxos state. This can potentially be a performance issue, a scalability problem, and moreover, it can complicate certain operational designs. For example, in order for a system to allow multiple different clients to access rbd images, it needs to have admin permissions to create new cephx clients. * Initial Idea The high-level proposal is to allow cephx clients to be able to generate keys and self-signed tickets that would allow access to a subset of their own resources (by a sub-client). Generation of these tickets will not require admin privileges as they will not require the creation of new ceph clients. The tickets will include authorization information (such as what resources the sub-client is allowed to use), and the secret key (sub-key). The tickets will be encrypted using the client secret key. The sub-client will be provided with the new key that was generated by the client, and with the ticket. At this point the sub-client will be able to initiate a regular cephx authentication process, with one modification: the ticket will be sent with its auth request(s). The mon will unpack the ticket, validate it, and use the sub-key for the rest of its auth process with the sub-client. The mon will check that the ticket provided by the sub-client gives permission to resources in a level that the client is allowed to use. * Sub-Key Revocation (discussion) As it is, the proposal does not provide a solution for sub-key/ticket revocation. Revoking the original client key will effectively remove the sub-key, however, it will also revoke all the other sub-keys that this client created which can be a problem. One solution is to set an expiration timestamp on the tickets, so that the mons would not allow the authentication after that timestamp. The idea can be extended by having the mons keep a blacklist of the revoked sub-keys (until their expiration), so that immediate revocation would be possible. The thinking is that sub-key revocation is not a frequent operation, so that such a blacklist would not be a problem to maintain. The bigger issue with this solution is that it requires the original client to keep creating sub-keys in order for the sub-client to be able to continue and access the system. This might work for certain use cases, but not for all. * Extension to initial proposal The sub-client has a key to access an (potentially external) entity that provides it with the sub-key (+ticket). These are generated dynamically and can expire. The sub-client needs to fetch a new sub-key once the old one expires. The entity that distributes the sub-key has access to the client key, and can keep a database of all the existing sub-clients. It can map between the sub-client and its owning client, and can revoke sub-client keys if needed. In a ceph internal implementation, the ceph manager could serve as the ticket granting service. In this case, the sub-client will be set with a non-expiring sub-key (tgt) that will allow it to access the ceph manager with specific caps for generating temporary tickets for accessing the client resources. The sub-client will go through the mon authentication process, will get a ticket to access the manager, will authenticate against the manager, and will request a new sub-ticket. The manager could validate that the sub-client is valid. The sub-client tgt could include a validation authority information, that would give the manager the ability to potentially access external key management services for the validation process (e.g., check that tgt wasn’t revoked). A different implementation can rely on an external key management system that would be able to generate the temporary sub-key for accessing the resources. The client will be configured with the required key to access the external system. Any thoughts? Yehuda _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
