[Gluster-devel] GlusterFS SSL behaviour change breaks openstack Manila GlusterFS Native driver

[Jeff Darcy]

> > > 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?