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.
