<div dir="ltr">Hi Deepak,<div><br></div><div>I am little confused about what you are trying to accomplish here. If I am understanding your use case properly, you want to ensure that a client may only mount a gluster volume if and only if it presents a key or secret that attests to the client's identity, which the gluster server can use to verify that client's identity. That's exactly what gluster MTLS is doing since the gluster server performs chain-of-trust validation on the client's leaf certificate.</div><div><br></div><div>Of course this will necessarily force encryption of the I/O path since its TLS. I don't understand why I/O path encryption is something you want to avoid -- seems like an essential part of basic network security that you get for "free" with the authentication. It is true that if you want the key-based authentication of a gluster client, you will need gluster MTLS. You could treat encryption as the "cost" of getting authentication if you will.<br></div><div><br></div><div>Now I am personally pretty negative on X.509 and chain-of-trust in general, since the trust model has been proven to not scale and is frequently broken by malicious and incompetent CAs. I also think its a completely inappropriate security model for something like gluster where all endpoints are known and controlled by a single entity, forcing a massive amount of unnecessary complexity with certificate management with no real added security. I have thought about making a feature request that gluster support a simple public-key encryption that's implemented like SSH. But all that said, MTLS is a well-tested, well known security protocol and the gluster team built it on top of openssl so it does get the security job done in an acceptable way. The fact that the I/O path is encrypted is not the thing that bothers me about the implementation though.</div><div><br></div><div><br></div><div>Joe </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 18, 2017 at 11:57 AM, Deepak Naidu <span dir="ltr"><<a href="mailto:dnaidu@nvidia.com" target="_blank">dnaidu@nvidia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Joseph for info.<br>
<span class=""><br>
>>In addition, gluster uses MTLS (each endpoint validate's the other's chain-of-trust), so you get authentication as well.<br>
<br>
</span>Does it only do authentication of mounts. I am not interested at this moment on IO path encryption only looking for authentication.<br>
<span class=""><br>
>>you can set the auth.allow and auth.reject options to whitelist and blacklist clients based on their source IPs.<br>
<br>
</span>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.<br>
<br>
<br>
<br>
--<br>
Deepak<br>
<div><div class="h5"><br>
> On Mar 18, 2017, at 9:14 AM, Joseph Lorenzini <<a href="mailto:jaloren@gmail.com">jaloren@gmail.com</a>> wrote:<br>
><br>
><br>
> Hi Deepak,<br>
><br>
> Here's the TLDR<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Here's the longer explanation on the TLS piece.<br>
><br>
> 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.<br>
><br>
><br>
</div></div>------------------------------<wbr>------------------------------<wbr>-----------------------<br>
This email message is for the sole use of the intended recipient(s) and may contain<br>
confidential information. Any unauthorized review, use, disclosure or distribution<br>
is prohibited. If you are not the intended recipient, please contact the sender by<br>
reply email and destroy all copies of the original message.<br>
------------------------------<wbr>------------------------------<wbr>-----------------------<br>
</blockquote></div><br></div>