> > > and since we trust the client CA > > > > Can you elaborate on that? Are you using a non-zero certificate depth? If > > so, why? Even without any change in ssl-allow behavior, trusting arbitrary > > clients as CAs seems like a security hole big enough to drive a container > > ship through. > Even for non-zero depth case, The mutual trust between tenants and server > will be pre-setup by the admin, which means > the CA of the client will be trusted on the server side, so any certificate > generated with server CN signed by the same CA will be trusted by the > server. It depends on how stringent the CA certs are protected on the client > side. In general i was wondering if it made sense to expose the trusted > client's CNs to the untrusted client ? Its something that used internal to > the gluster server and should remain concealed i feel. In the normal/default case, there would be no way for a client to generate a certificate that would get past the server's authentication to where ssl-allow even matters. With a cert depth of zero, the only certs that can connect are stored in a file on the server and only root on the server can add any. No information on or available to the client changes that - not the server's key, not the client's own .ca file, and so on. The only way the "CA of the client" becomes relevant is with a cert depth greater than one. That would mean that the server trusts the client not only to connect but to sign certs that will allow others to connect. The classic scenario would be a cloud provider which trusts a corporate tenant to sign certificates for its own employees. That's a valid use case, but it does create a potential for a tenant to connect with any CN they want. One way of looking at it is that a non-zero cert depth makes all certs in the server's .ca file equivalent - i.e. able to impersonate or affect each other at will. (Note that this doesn't happen with a cert depth of zero because that doesn't allow anyone but the server to assign CNs). Therefore, tenants must be isolated from one another by using different .ca files, which are already supported on a per-volume basis. If a tenant X's cert is not in the .ca file for a volume owned by tenant Y, then it cannot connect to that volume or create certs that would enable anyone else to do so, even as X retains full ability to generate new certs usable on its own volumes and to discriminate among them with ssl-allow. There are ways that we could allow tenants to co-exist in the same .ca file with a non-zero cert depth, but the complexity piles up quickly and so does the potential for new security issues. We're certainly not going to replicate Keystone's entire identity model within GlusterFS, not least because our own identity model has to accommodate non-OpenStack users as well. What does Manila need to do that (a) doesn't force us into one identity model and (b) can't be done with facilities that already exist? _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
