<div dir="ltr"><div><br></div><div>Hi Deepak,</div><div><br></div><div>Here&#39;s the TLDR</div><div><br></div><div>If you don&#39;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&#39;s also always iptables rules if you don&#39;t want to do that.</div><div><br></div><div>Note this only address a client&#39;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&#39;s a separate and much more complicated issue. I can elaborate on that more if you want. <br></div><div><br></div><div>Here&#39;s the longer explanation on the TLS piece. </div><div><br></div><div>So there are a couple different security layers here. TLS will in fact encrypt the I/O path -- that&#39;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&#39;s the other&#39;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&#39;s certificate. This provides an inflexible but reasonably strong form of authorization.</div><div><br></div><div><br></div></div>