Gluster users - Mar 2017 - Secured mount in GlusterFS using keys

Hi Deepak,

Here's the TLDR

If you don't want the I/O path to be encrypted but you want to control
access to a gluster volume, you can set the auth.allow and auth.reject
options to whitelist and blacklist clients based on their source IPs.
There's also always iptables rules if you don't want to do that.

Note this only address a client's (i.e system where multiple unix users can
exist) to mount a gluster volume. This does not address access by different
unix users on that mounted gluster volume -- that's a separate and much
more complicated issue. I can elaborate on that more if you want.

Here's the longer explanation on the TLS piece.

So there are a couple different security layers here. TLS will in fact
encrypt the I/O path -- that's one of its key selling points which is to
ensure confidentiality of the data sent between the gluster server and
gluster client. In addition, gluster uses MTLS (each endpoint validate's
the other's chain-of-trust), so you get authentication as well.
Additionally, if you set the auth.ssl-allow option on the gluster volume,
you can specify whether authenticated TLS client is permitted to access the
volume based on the common name in the client's certificate. This provides
an inflexible but reasonably strong form of authorization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170318/2f15f3d9/attachment.html>

Thanks Joseph for info. 
>>In addition, gluster uses MTLS (each endpoint validate's the
other's chain-of-trust), so you get authentication as well.
Does it only do authentication of mounts. I am not interested at this moment on
IO path encryption only looking for authentication.
>>you can set the auth.allow and auth.reject options to whitelist and
blacklist clients based on their source IPs.
I have used this but unfortunately I don't see ipbased / hostbased ACL as
matured method, unless GlusterFS supports Kerberos completely. The reason I am
looking for key or secret based secured mounts is, there will be entire subnet
granted to the service & more elegant way is to allow only the client on
that subnet to gluster mount would be if they use keys/secret as the client
might next cycle/reboot get different IP. I can find workaround related to IP
but this seems really weird that gluster only uses SSL to encrypt IO traffic but
not use the same for authenticated mount.



--
Deepak
> On Mar 18, 2017, at 9:14 AM, Joseph Lorenzini <jaloren at gmail.com>
wrote:
> 
> 
> Hi Deepak,
> 
> Here's the TLDR
> 
> If you don't want the I/O path to be encrypted but you want to control
access to a gluster volume, you can set the auth.allow and auth.reject options
to whitelist and blacklist clients based on their source IPs. There's also
always iptables rules if you don't want to do that.
> 
> Note this only address a client's (i.e system where multiple unix users
can exist) to mount a gluster volume. This does not address access by different
unix users on that mounted gluster volume -- that's a separate and much more
complicated issue. I can elaborate on that more if you want.
> 
> Here's the longer explanation on the TLS piece. 
> 
> So there are a couple different security layers here. TLS will in fact
encrypt the I/O path -- that's one of its key selling points which is to
ensure confidentiality of the data sent between the gluster server and gluster
client. In addition, gluster uses MTLS (each endpoint validate's the
other's chain-of-trust), so you get authentication as well. Additionally, if
you set the auth.ssl-allow option on the gluster volume, you can specify whether
authenticated TLS client is permitted to access the volume based on the common
name in the client's certificate. This provides an inflexible but reasonably
strong form of authorization.
> 
> 
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------