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.
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
