[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