<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Hi Jeff<br></div> The recent commit (548547b2e) with subject "transport: fix default behavior for SSL authorization" changes the behaviour of GlusterFS SSL in a way that causes to break the Manila usecase.<br><br></div> I am willing to change on the Manila side, but before I do, i wanted to quickly put my thoughts on the above change you made and ask some Qs.<br><br></div><b>Before the </b>548547b2e<b> patch</b>:<br><br></div>1) To enable glusterfs in SSL mode, I used to enable client.ssl and server.ssl options<br></div><div>This ensured that no clients (tenants in openstack lingo) with right certificate can access/mount the gluster volume, because default behaviour was AUTH_REJECT<br><br></div>2) As part of Manila allow acces to share API - i used to enable ssl.auth-allow <CN>, this made the tenant with the right certificate mount the volume and others couldn't<br><br></div>3) As part of Manila deny access to share API - I used to remove (reset) ssl.auth-allow, this ensured that the tenant couldn't mount, even if he has the right certificate, <b>at the same time ensuring that GlusterFS volume is SSLenabled (bcos of client and server .ssl being on)</b><br><br></div><b>After the </b><b> </b>548547b2e<b> patch</b>:<br><br></div>1) Refer to #1 above. This isn't true anymore, because not having the ssl.auth-allow means anyone with the certificate can access, because default behaviour changed to AUTH_DONT_CARE (iiuc)<br><br></div>2) Refer to #2 above. This remains same<br><br></div>3) Refer to #3 above. Now removing ssl.auth-allow doesn't work anymore, because removing it means the tenants can still connect (if they try to) and deny access is broken - <b>thus my Manila native driver is broken</b>. <br><br></div><div>Q1) So, given the behaviour, is there a way to keep the volume SSL enabled and yet deny access to clients ? (which was earlier possible via ssl.auth-allow's old behaviour)<br></div><div><br></div>Now, if i want to comply with the new behaviour, as part of deny access ...<br><br> 3a) I need to remove all the 3 options (ssl.auth-allow, client.ssl, server.ssl) and add a auth.reject * (because we don't have ssl.auth-reject option support) to ensure the volume cannot be mounted by tenants/clients, tho' local clients (trusted ones) should be able to connect. This effectively means I disable SSL and use IP based auth.reject *, but havign SSL based volume was the requirement to begin with, so disablign SSL seems like compromising security here.<br><br></div><div> -- or --<br><br></div><div> 3b) I can also do as ... remove ssl.auth-allow, and disable one of client/server.ssl option, but then trusted clients (incl quotad etc) also won't be able to connect<br><br></div><div> -- or --<br></div><div><br></div><div> 3c) As part of deny access i keep client/server.ssl on & change ssl.auth-allow <CN> where CN=some randomly generated UUID and hope no one has the cert with that UUID as CN, this won't work for trusted clients too<br><br></div><div>--or --<br><br></div><div> 3d) As part of deny access, i keep client/server.ssl on & ensure that ssl.auth-allow is a list of CNs where CN1 = gluster server's CN, CN2 = randomly generated UUID. Now local trusted clients should be able to connect, so server administration isn't broken and external clients cannot connect. This effectively means whenever i modify ssl.auth-allow from my Manila driver, i ensure that keep CN1 as-is and add/remove CN2 based on allow/deny access behaviour needed.<br><br></div><div> -- or --<br><br></div><div> 3e) Have support for ssl.auth-reject option in GlusterFS. As part of deny access remove ssl.auth-allow, keep client.ssl, server.ssl options, & do ssl.auth-reject *, but this will break trusted clients again! But this is in contrast to the auth.reject * behaviour where trusted clients are able to connect. Because git commit<b> </b><b> </b>548547b2e aimed to make ssl's auth-allow behaviour consistent with non-ssl behaviour, here too when we add ssl.auth-reject support, we should figure a way to allow trusted clients to be able to connect as long as client/server.ssl on is present.<br><br></div><div>Looking at the options above ...<br><br>1) #3e seems logical to me, but isn't implemented yet. <br><br>2) #3d has the addnl overhead of maintaining the list of CNs as part of ssl.auth-allow get/set, which isn't ideal (compared to #3e) , but given the status quo , seems to be the only way forward. <br><br></div><div>3) #3a can be done too, but is defintely not clean way, and is more of a workaround than solution<br><br></div><div>On a side note:<br> Option #3d also means Manila code does a get first , appends either random UUID or
correct CN (depending on deny/allow access) and then sets it. This also means the Manila code knows what
the server CN is and potentially can create a SSL cert with that CN and
since we trust the client CA, it can connect to server as server itself,
but I believe we can safely assume that Manila servcies run inside
openstack nodes which are part of the deployement hence safe enuf not to be hacked this way :). <br></div><div><br>Thoughts ?<br><br>thanx,<br></div><div>deepak<br><br></div><div><br></div></div>