We're currently working on an authentication module for ceph. This will allow us both keeping the cluster secured internally, as no bad servers will be able to join the cluster, and both externally. E.g., only permitted clients will be able to do certain specified operations. This is just a rough description of what we consider right now, but here it is:
The following are the basic requirements: * Robust, scalable, keeps up with the cluster's consistency. * Identify the different cluster modules (e.g., mon, mds and osd) and allow only the permitted entities to participate in the cluster * Identify the clients, and set up a mechanism to authenticate them. Establish a session between the client and the cluster * The created session will allow the client to communicate with the different cluster entities * It will be possible to sign (and possibly encrypt) all protocol operations 1. Implementation Considerations We need to remember that when dealing with the cluster we can't just add a server that doesn't conform with the basic cluster requirements which are robustness and scalability. So when considering a 3rd party that we could integrate in, we need to keep that in mind. I would like to hear if anyone has an idea on what other tools we can use instead of "let's just do it all ourselves". 2. General Like in other network protocols, the basic idea is that when the client first connects to the cluster it establishes a 'session'. In order for the client to authenticate that session, it first specifies the types of the different authentications mechanisms it supports. The server will respond with the selected authentication methods, and with the beginning of the authentication sequence. For a shared secret authentication the server will respond with the challenge for the authentication. The client, will respond with its own challenge, and some computed key that was generated from the secret, the client challenge and the server challenge. A secret session-key will also be calculated by both parties. Once authenticated the client's validity, the server responds with some ticket that will allow the client to communicate with the different entities. The ticket will consist of the client's id and some signature that will validate its authenticity. The monitor will probably be the natural entity to handle the session creation requests, though it might be better to create a new service that will be responsible for all authentication issues. Another issue that we discussed was whether we need to propagate the session state to the whole cluster. For example, when a client authenticates with mon1, do we actually need all the monitors to know about this authentication (that is, while the authentication sequence goes on)? If mon1 goes down while the authentication takes place, do we need the monitor that takes its place to continue on with the authentication sequnce? probably not. We can just issue some do-it-again response to the client. After authentication is completed, we will need to keep the knowledge of that session and of the calculated session-key, so that messages signing could be used. Once the client has a ticket, it is valid and can be used for all its operations. One caveat is that there's no simple way to revoke such a ticket, beside using some timestamp on it. The ticket should hold information like the user id, the ticket signature, and authorization info (e.g., which osd pools it can use). 3. Authentication Mechanisms These are the different authentication mechanisms that we actually consider right now. * Kerberos Pros: * This is probably the way to go (if done right). Kerberos has been adopted by major network protocols (e.g., nfs, cifs). * Each entity will be able to authenticate itself, and we'll be able to define trust relationships between the different entities. Kerberos helps us with the fact that we have different entities that we need to validate. Cons: * Complicates deployment * Need to embed a kerberos server within the cluster that will not be a single point of failure. Needs to be scalable and robust. * Kernel client support will probably require userspace upcall which complicates things * Shared secret Pros: * Easier to implement, much easier to deploy Cons: * Security issues * Can't delegate permissions between entities. E.g., the client can give another entity a permission to act on behalf of it. It seems that for the sake of simplicity will start with a shared-secret implementation, but will probably later on add kerberos capabilities. I'd love to hear any comment, idea or request that you might have as we're about to start implementing this stuff. Thanks, Yehuda ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ceph-devel mailing list Ceph-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ceph-devel
