[Gluster-devel] Glusterfs SSL capability

[Jeff Darcy]

On 05/16/2013 08:02 PM, Nux! wrote:
> v3.4 is supposedly SSL capable. Can anyone please detail a bit how this
> feature can be used exactly? There doesn't seem to be any documentation on
> it.

Odd.  The feature has been available since before 3.3, and I know we've gone 
around a few times on documenting it, but I can't find anything either.  :(  As 
the author of the feature, I guess I should explain.

There are two options that control SSL usage:

	gluster volume set myvol client.ssl on
	gluster volume set myvol server.ssl on

TBH I don't remember why there are two, but I think I had a good reason at the 
time.  Anyway, these options control whether the transport type is set to ssl 
instead of socket on the client and server respectively.  To make it actually 
*work* you need to generate OpenSSL certificates (openssl req -new -x509 ...) 
and put them into the right places yourself.

	/etc/ssl/glusterfs.pem
	The node's *own* certificate.

	/etc/ssl/glusterfs.key
	Key for the above.

	/etc/ssl/glusterfs.ca
	Concatenation of certificates we accept.

These locations can be changed in your volfiles or from the "glusterfs" command 
line (--xlator-option transport.socket...) but not from the "gluster" CLI. 
Note that there are several caveats.

(1) The peers' certificates themselves must be in glusterfs.ca; we don't 
support any kind of certificate signing or PKI.  It wouldn't be hard to do so, 
but there's no way currently without changing code (to make verify_depth 
greater than zero).

(2) We use SSL only for encryption and authentication, not authorization. 
While you do need an authenticated identity to connect, we don't really care 
what that identity is and once you've connected we don't use it for any further 
access-control checks (there is a patch to do so).

(3) SSL is only for the data connections (glusterfs<->glusterfsd) and is 
explicitly disabled for control connections (glusterd<->anything).

(4) Turning on SSL also turns on transport multi-threading (because otherwise 
performance would be awful as other work gets blocked behind encryption in a 
single polling thread).  This is usually a performance benefit even without 
SSL, and some people do turn it on just for that, but it's less fully tested 
and supported than the usual threading model.

All that said, I'd be glad to have more people using SSL, and to hear about 
their experiences (including bug reports).  Long term, I think secure 
connections are going to be an absolute requirement in a significant number (if 
not a majority) of deployments, so the more mileage we get on it sooner the better.