Re: [Gluster-users] Secured mount in GlusterFS using keys
Hi Joe, I know how the TLS works, but what is the MTLS in your email reference anything different from TLS in terms of config. -- Deepak On Mar 21, 2017, at 2:51 AM, Joseph Lorenzini mailto:jalo...@gmail.com>> wrote: Hi Deepak, The starting point would be that link you initially provided. In terms of help, could you elaborate more on what you are looking for? Do you need a high level primer on how to create a chain-of-trust with openssl? Certificate management? Or are you looking for more on how to properly provision the TLS certifcates in gluster? Joe On Sun, Mar 19, 2017 at 11:52 AM, Deepak Naidu mailto:dna...@nvidia.com>> wrote: Thanks Joe for your inputs. I guess comparing client -- glusterServer IO performance over MTLS and non-MTLS should give me some idea on the client/server IO overhead. Also any URL related to setup & configuring MTLS is appreciated. -- Deepak On Mar 19, 2017, at 7:00 AM, Joseph Lorenzini mailto:jalo...@gmail.com>> wrote: Hi Deepak, Sorta. I think it depends on what we mean by I/O path and performance. If we are referring to disk I/O for gluster servers, then no. If we are referring to the network I/O between a gluster client and server, than yes there will by definition be some additional overhead. That however is true of any security layer one chooses to pick for any application, especially a distributed system. In practice, security of any kind, whether its encryption, ACLs, or even iptables, will degrade the performance of an application. And since distributed systems by definition handle their state through network I/O, that means security + distributed system = network latency. There's a reason people say security is where performance goes to die. :) Now that all said, frequently the issue is not whether there will be network latency, but how much and does it matter? Moreover, what are the specific performance requirements for your gluster pool and have they been weighed against the costs of meeting those requirements? Additionally, how does meeting those performance requirements weigh against all your other requirements like for example having basic network security around a distributed system? I would be quite surprised if openssl MTLS would be any slower compared to some other key-based authentication scheme. Most of the cost of TLS is around the TLS handshake, which is a one-time hit when the gluster client mounts the volume. Since the client is maintaining a persistent TLS connection, most of the overhead is openssl code performing symmetric encryption, which openssl, despite all its warts, is really really good at doing really really fast (understand this all relative to an arbitrary baseline :). Bottom line: with modern hardware, the performance impact of MTLS should be negligible. IMHO, if the performance requirement can't tolerate MTLS, then its in practice preventing you from implementing any reasonable security scheme at all. In that case, you'd be better off just setting up an isolated network and skipping any type of authentication. I'd recommend setting up MTLS with gluster and run your performance tests against it. That will definitively answer your question of whether the performance is acceptable. The MTLS setup is not that hard and the gluster documentation is reasonable though could be improved (I need to submit some PRs against it). if you have any questions about setup and configuration, I am sure I can help. Joe On Sat, Mar 18, 2017 at 2:25 PM, Deepak Naidu mailto:dna...@nvidia.com>> wrote: Hi Joe, thanks for taking time for explaining. I am having basic set of requirements along with IO performance as key factor, my reply below should justify what I am trying to achieve. >>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. Yes, this is the exact use case for my requirements. >>That's exactly what gluster MTLS is doing since the gluster server performs >>chain-of-trust validation on the client's leaf certificate. That's good, but my confusion here is does this MTLS also encrypt's IO traffic like TLS. If yes, than it's not want I am looking for. The reason is the IO encryption/decryption is an extra overhead for my use case as performance of IO is also factor why we're are looking for GlusterFS, unless my understanding is incorrect that IO encryption has no overhead. >> 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. If I understand the term IO path encryption correctly, all the storage IO will go through extra latency of encryption & decryption which is not needed for my requirements as this produced extra IO latency which
Re: [Gluster-users] Secured mount in GlusterFS using keys
Hi Deepak, The starting point would be that link you initially provided. In terms of help, could you elaborate more on what you are looking for? Do you need a high level primer on how to create a chain-of-trust with openssl? Certificate management? Or are you looking for more on how to properly provision the TLS certifcates in gluster? Joe On Sun, Mar 19, 2017 at 11:52 AM, Deepak Naidu wrote: > Thanks Joe for your inputs. I guess comparing client -- glusterServer IO > performance over MTLS and non-MTLS should give me some idea on the > client/server IO overhead. > > Also any URL related to setup & configuring MTLS is appreciated. > > > > -- > Deepak > > On Mar 19, 2017, at 7:00 AM, Joseph Lorenzini wrote: > > Hi Deepak, > > Sorta. I think it depends on what we mean by I/O path and performance. > > If we are referring to disk I/O for gluster servers, then no. If we are > referring to the network I/O between a gluster client and server, than yes > there will by definition be some additional overhead. That however is true > of any security layer one chooses to pick for any application, especially a > distributed system. In practice, security of any kind, whether its > encryption, ACLs, or even iptables, will degrade the performance of an > application. And since distributed systems by definition handle their state > through network I/O, that means security + distributed system = network > latency. There's a reason people say security is where performance goes to > die. :) > > Now that all said, frequently the issue is not whether there will be > network latency, but how much and does it matter? Moreover, what are the > specific performance requirements for your gluster pool and have they been > weighed against the costs of meeting those requirements? Additionally, how > does meeting those performance requirements weigh against all your other > requirements like for example having basic network security around a > distributed system? > > I would be quite surprised if openssl MTLS would be any slower compared > to some other key-based authentication scheme. Most of the cost of TLS is > around the TLS handshake, which is a one-time hit when the gluster client > mounts the volume. Since the client is maintaining a persistent TLS > connection, most of the overhead is openssl code performing symmetric > encryption, which openssl, despite all its warts, is really really good at > doing really really fast (understand this all relative to an arbitrary > baseline :). Bottom line: with modern hardware, the performance impact of > MTLS should be negligible. IMHO, if the performance requirement can't > tolerate MTLS, then its in practice preventing you from implementing any > reasonable security scheme at all. In that case, you'd be better off just > setting up an isolated network and skipping any type of authentication. > > I'd recommend setting up MTLS with gluster and run your performance tests > against it. That will definitively answer your question of whether the > performance is acceptable. The MTLS setup is not that hard and the gluster > documentation is reasonable though could be improved (I need to submit some > PRs against it). if you have any questions about setup and configuration, I > am sure I can help. > > Joe > > On Sat, Mar 18, 2017 at 2:25 PM, Deepak Naidu wrote: > >> Hi Joe, thanks for taking time for explaining. I am having basic set of >> requirements along with IO performance as key factor, my reply below should >> justify what I am trying to achieve. >> >> >>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. >> >> Yes, this is the exact use case for my requirements. >> >> >> >> >>That's exactly what gluster MTLS is doing since the gluster server >> performs chain-of-trust validation on the client's leaf certificate. >> >> That's good, but my confusion here is does this MTLS also encrypt's IO >> traffic like TLS. If yes, than it's not want I am looking for. The reason >> is the IO encryption/decryption is an extra overhead for my use case as >> performance of IO is also factor why we're are looking for GlusterFS, >> unless my understanding is incorrect that IO encryption has no overhead. >> >> >> >> >> 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. >> >> If I understand the term IO path encryption correctly, all the storage IO >> will go through extra latency of encryption & decryption which is not >> needed for my requirements as this produced extra IO latency which is why I >> am trying to avoid IO path encryption & just need basic secret based >> authentication. >> >> >> >> >> -- >> Deepak >> >> > On Mar 18, 2017, at 10:46 AM, Joseph L
Re: [Gluster-users] Secured mount in GlusterFS using keys
Thanks Joe for your inputs. I guess comparing client -- glusterServer IO performance over MTLS and non-MTLS should give me some idea on the client/server IO overhead. Also any URL related to setup & configuring MTLS is appreciated. -- Deepak On Mar 19, 2017, at 7:00 AM, Joseph Lorenzini mailto:jalo...@gmail.com>> wrote: Hi Deepak, Sorta. I think it depends on what we mean by I/O path and performance. If we are referring to disk I/O for gluster servers, then no. If we are referring to the network I/O between a gluster client and server, than yes there will by definition be some additional overhead. That however is true of any security layer one chooses to pick for any application, especially a distributed system. In practice, security of any kind, whether its encryption, ACLs, or even iptables, will degrade the performance of an application. And since distributed systems by definition handle their state through network I/O, that means security + distributed system = network latency. There's a reason people say security is where performance goes to die. :) Now that all said, frequently the issue is not whether there will be network latency, but how much and does it matter? Moreover, what are the specific performance requirements for your gluster pool and have they been weighed against the costs of meeting those requirements? Additionally, how does meeting those performance requirements weigh against all your other requirements like for example having basic network security around a distributed system? I would be quite surprised if openssl MTLS would be any slower compared to some other key-based authentication scheme. Most of the cost of TLS is around the TLS handshake, which is a one-time hit when the gluster client mounts the volume. Since the client is maintaining a persistent TLS connection, most of the overhead is openssl code performing symmetric encryption, which openssl, despite all its warts, is really really good at doing really really fast (understand this all relative to an arbitrary baseline :). Bottom line: with modern hardware, the performance impact of MTLS should be negligible. IMHO, if the performance requirement can't tolerate MTLS, then its in practice preventing you from implementing any reasonable security scheme at all. In that case, you'd be better off just setting up an isolated network and skipping any type of authentication. I'd recommend setting up MTLS with gluster and run your performance tests against it. That will definitively answer your question of whether the performance is acceptable. The MTLS setup is not that hard and the gluster documentation is reasonable though could be improved (I need to submit some PRs against it). if you have any questions about setup and configuration, I am sure I can help. Joe On Sat, Mar 18, 2017 at 2:25 PM, Deepak Naidu mailto:dna...@nvidia.com>> wrote: Hi Joe, thanks for taking time for explaining. I am having basic set of requirements along with IO performance as key factor, my reply below should justify what I am trying to achieve. >>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. Yes, this is the exact use case for my requirements. >>That's exactly what gluster MTLS is doing since the gluster server performs >>chain-of-trust validation on the client's leaf certificate. That's good, but my confusion here is does this MTLS also encrypt's IO traffic like TLS. If yes, than it's not want I am looking for. The reason is the IO encryption/decryption is an extra overhead for my use case as performance of IO is also factor why we're are looking for GlusterFS, unless my understanding is incorrect that IO encryption has no overhead. >> 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. If I understand the term IO path encryption correctly, all the storage IO will go through extra latency of encryption & decryption which is not needed for my requirements as this produced extra IO latency which is why I am trying to avoid IO path encryption & just need basic secret based authentication. -- Deepak > On Mar 18, 2017, at 10:46 AM, Joseph Lorenzini > mailto:jalo...@gmail.com>> wrote: > > 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 c
Re: [Gluster-users] Secured mount in GlusterFS using keys
Hi Deepak, Sorta. I think it depends on what we mean by I/O path and performance. If we are referring to disk I/O for gluster servers, then no. If we are referring to the network I/O between a gluster client and server, than yes there will by definition be some additional overhead. That however is true of any security layer one chooses to pick for any application, especially a distributed system. In practice, security of any kind, whether its encryption, ACLs, or even iptables, will degrade the performance of an application. And since distributed systems by definition handle their state through network I/O, that means security + distributed system = network latency. There's a reason people say security is where performance goes to die. :) Now that all said, frequently the issue is not whether there will be network latency, but how much and does it matter? Moreover, what are the specific performance requirements for your gluster pool and have they been weighed against the costs of meeting those requirements? Additionally, how does meeting those performance requirements weigh against all your other requirements like for example having basic network security around a distributed system? I would be quite surprised if openssl MTLS would be any slower compared to some other key-based authentication scheme. Most of the cost of TLS is around the TLS handshake, which is a one-time hit when the gluster client mounts the volume. Since the client is maintaining a persistent TLS connection, most of the overhead is openssl code performing symmetric encryption, which openssl, despite all its warts, is really really good at doing really really fast (understand this all relative to an arbitrary baseline :). Bottom line: with modern hardware, the performance impact of MTLS should be negligible. IMHO, if the performance requirement can't tolerate MTLS, then its in practice preventing you from implementing any reasonable security scheme at all. In that case, you'd be better off just setting up an isolated network and skipping any type of authentication. I'd recommend setting up MTLS with gluster and run your performance tests against it. That will definitively answer your question of whether the performance is acceptable. The MTLS setup is not that hard and the gluster documentation is reasonable though could be improved (I need to submit some PRs against it). if you have any questions about setup and configuration, I am sure I can help. Joe On Sat, Mar 18, 2017 at 2:25 PM, Deepak Naidu wrote: > Hi Joe, thanks for taking time for explaining. I am having basic set of > requirements along with IO performance as key factor, my reply below should > justify what I am trying to achieve. > > >>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. > > Yes, this is the exact use case for my requirements. > > > > >>That's exactly what gluster MTLS is doing since the gluster server > performs chain-of-trust validation on the client's leaf certificate. > > That's good, but my confusion here is does this MTLS also encrypt's IO > traffic like TLS. If yes, than it's not want I am looking for. The reason > is the IO encryption/decryption is an extra overhead for my use case as > performance of IO is also factor why we're are looking for GlusterFS, > unless my understanding is incorrect that IO encryption has no overhead. > > > > >> 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. > > If I understand the term IO path encryption correctly, all the storage IO > will go through extra latency of encryption & decryption which is not > needed for my requirements as this produced extra IO latency which is why I > am trying to avoid IO path encryption & just need basic secret based > authentication. > > > > > -- > Deepak > > > On Mar 18, 2017, at 10:46 AM, Joseph Lorenzini > wrote: > > > > 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. > > > > 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 c
Re: [Gluster-users] Secured mount in GlusterFS using keys
Hi Joe, thanks for taking time for explaining. I am having basic set of requirements along with IO performance as key factor, my reply below should justify what I am trying to achieve. >>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. Yes, this is the exact use case for my requirements. >>That's exactly what gluster MTLS is doing since the gluster server performs >>chain-of-trust validation on the client's leaf certificate. That's good, but my confusion here is does this MTLS also encrypt's IO traffic like TLS. If yes, than it's not want I am looking for. The reason is the IO encryption/decryption is an extra overhead for my use case as performance of IO is also factor why we're are looking for GlusterFS, unless my understanding is incorrect that IO encryption has no overhead. >> 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. If I understand the term IO path encryption correctly, all the storage IO will go through extra latency of encryption & decryption which is not needed for my requirements as this produced extra IO latency which is why I am trying to avoid IO path encryption & just need basic secret based authentication. -- Deepak > On Mar 18, 2017, at 10:46 AM, Joseph Lorenzini wrote: > > 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. > > 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. > > 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. --- 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. --- ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Secured mount in GlusterFS using keys
Hi Deepak, 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. 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. 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. Joe On Sat, Mar 18, 2017 at 11:57 AM, Deepak Naidu wrote: > 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 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. > > --- > ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Secured mount in GlusterFS using keys
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 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. --- ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] 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. ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Secured mount in GlusterFS using keys
Any info guys ? -- Deepak From: Deepak Naidu Sent: Friday, March 17, 2017 12:32 AM To: gluster-users@gluster.org Subject: Secured mount in GlusterFS using keys Hello, Is there a way like cephFS where a keyring can be passed for mount. I see SSL in GlusterFS something secured mount based on pem & key files, but I am bit confused where these are only for mount authentication or for IO path encryption. I only want authorized Glusterfs mount based on keys or certs or secret "no encryption of IO path" . Is there a way possible for GlusterFS. https://gluster.readthedocs.io/en/latest/Administrator%20Guide/SSL/ -- Deepak --- 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. --- ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
[Gluster-users] Secured mount in GlusterFS using keys
Hello, Is there a way like cephFS where a keyring can be passed for mount. I see SSL in GlusterFS something secured mount based on pem & key files, but I am bit confused where these are only for mount authentication or for IO path encryption. I only want authorized Glusterfs mount based on keys or certs or secret "no encryption of IO path" . Is there a way possible for GlusterFS. https://gluster.readthedocs.io/en/latest/Administrator%20Guide/SSL/ -- Deepak --- 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. --- ___ Gluster-users mailing list Gluster-users@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-users
