[Gluster-devel] Glusterfs SSL capability

Jeff Darcy jdarcy at redhat.com
Sun May 19 12:15:11 UTC 2013


On 05/19/2013 04:25 AM, Nux! wrote:
> What would happen if one peer is SSL enabled (i.e. has all 
> the bits in place) and one is not (i.e. has a missing key); would the 
> transfer/process go back to non-SSL or just die with some errors?

Pretty sure it would die, with some sort of protocol-error message on
the SSL side.

> Any chance the SSL feature could be managed through glusterd? Just as 
> glusterd is responsible for vol files across the deployment and so on, 
> it should also be able to generate and maintain key/ca files.

There's a security angle to that.  We explicitly don't want to take
responsibility for securing keys etc. in transit, especially while the
glusterd communication itself is unencrypted.  That might be a future
enhancement, but only after some of the other pieces are in place.

> Any way to turn on just multi-threading, without SSL?

Yes, though again not from the CLI.  You have to add something like this
to the protocol/client or protocol/server translators in your volfile
(or use --xlator-option from the glusterfs/glusterfsd command line)

	option transport.socket.own-thread on

> Yes, it could sure have its use cases, such as securing traffic going 
> through some "public" VLANs (the case with many "cloud" deployments).

FWIW, that's how I've used it myself.  For several months, I had my own
GlusterFS setup "in the cloud" using SSL and at-rest encryption from
home/work/etc.  It was very light usage, being just myself, but I know
others have used it more heavily.





More information about the Gluster-devel mailing list