[jira] [Updated] (HBASE-26548) Investigate mTLS in RPC layer
[ https://issues.apache.org/jira/browse/HBASE-26548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil updated HBASE-26548: - Attachment: 0001-One-way-TLS-on-Netty-RPC-Implementation.patch > Investigate mTLS in RPC layer > - > > Key: HBASE-26548 > URL: https://issues.apache.org/jira/browse/HBASE-26548 > Project: HBase > Issue Type: New Feature >Reporter: Bryan Beaudreault >Priority: Major > Attachments: 0001-One-way-TLS-on-Netty-RPC-Implementation.patch > > > Current authentication options are heavily based on SASL and Kerberos. For > organizations that don't already deploy Kerberos or other token provider, > this is a heavy lift. Another very common way of authenticating in the > industry is mTLS, which makes use of SSL certifications and can solve both > wire encryption and auth. For those already deploying trusted certificates in > their infra, mTLS may be much easier to integrate. > It isn't necessarily easy to implement this, but I do think we could use > existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I know > it's easy to add SSL to non-blocking IO through a > hadoop.rpc.socket.factory.class.default which returns SSLSockets, but that > doesn't touch on the certification verification at all. > Much more investigation is needed, but logging this due to some interest > encountered on slack. > Slack thread: > https://apache-hbase.slack.com/archives/C13K8NVAM/p1638980520110600 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26548) Investigate mTLS in RPC layer
[ https://issues.apache.org/jira/browse/HBASE-26548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Beaudreault updated HBASE-26548: -- Description: Current authentication options are heavily based on SASL and Kerberos. For organizations that don't already deploy Kerberos or other token provider, this is a heavy lift. Another very common way of authenticating in the industry is mTLS, which makes use of SSL certifications and can solve both wire encryption and auth. For those already deploying trusted certificates in their infra, mTLS may be much easier to integrate. It isn't necessarily easy to implement this, but I do think we could use existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I also know it's easy to add SSL to non-blocking IO through a hadoop.rpc.socket.factory.class.default which returns SSLSockets (we do this at my company), but that doesn't touch on the certification verification at all. Much more investigation is needed, but logging this due to some interest encountered on slack. was: Current authentication options are heavily based on SASL and Kerberos. For organizations that don't already deploy Kerberos or other token provider, this is a heavy lift. Another very common way of authenticating in the industry is mTLS, which makes use of SSL certifications and can solve both wire encryption and auth. For those already deploying trusted certificates in their infra, mTLS may be much easier to integrate. It isn't necessarily easy to implement this, but I do think we could use existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I know it's easy to add SSL to non-blocking IO through a hadoop.rpc.socket.factory.class.default which returns SSLSockets, but that doesn't touch on the certification verification at all. Much more investigation is needed, but logging this due to some interest encountered on slack. > Investigate mTLS in RPC layer > - > > Key: HBASE-26548 > URL: https://issues.apache.org/jira/browse/HBASE-26548 > Project: HBase > Issue Type: New Feature >Reporter: Bryan Beaudreault >Priority: Major > > Current authentication options are heavily based on SASL and Kerberos. For > organizations that don't already deploy Kerberos or other token provider, > this is a heavy lift. Another very common way of authenticating in the > industry is mTLS, which makes use of SSL certifications and can solve both > wire encryption and auth. For those already deploying trusted certificates in > their infra, mTLS may be much easier to integrate. > It isn't necessarily easy to implement this, but I do think we could use > existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I also > know it's easy to add SSL to non-blocking IO through a > hadoop.rpc.socket.factory.class.default which returns SSLSockets (we do this > at my company), but that doesn't touch on the certification verification at > all. > Much more investigation is needed, but logging this due to some interest > encountered on slack. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26548) Investigate mTLS in RPC layer
[ https://issues.apache.org/jira/browse/HBASE-26548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath Vissapragada updated HBASE-26548: - Description: Current authentication options are heavily based on SASL and Kerberos. For organizations that don't already deploy Kerberos or other token provider, this is a heavy lift. Another very common way of authenticating in the industry is mTLS, which makes use of SSL certifications and can solve both wire encryption and auth. For those already deploying trusted certificates in their infra, mTLS may be much easier to integrate. It isn't necessarily easy to implement this, but I do think we could use existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I know it's easy to add SSL to non-blocking IO through a hadoop.rpc.socket.factory.class.default which returns SSLSockets, but that doesn't touch on the certification verification at all. Much more investigation is needed, but logging this due to some interest encountered on slack. Slack thread: https://apache-hbase.slack.com/archives/C13K8NVAM/p1638980520110600 was: Current authentication options are heavily based on SASL and Kerberos. For organizations that don't already deploy Kerberos or other token provider, this is a heavy lift. Another very common way of authenticating in the industry is mTLS, which makes use of SSL certifications and can solve both wire encryption and auth. For those already deploying trusted certificates in their infra, mTLS may be much easier to integrate. It isn't necessarily easy to implement this, but I do think we could use existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I also know it's easy to add SSL to non-blocking IO through a hadoop.rpc.socket.factory.class.default which returns SSLSockets (we do this at my company), but that doesn't touch on the certification verification at all. Much more investigation is needed, but logging this due to some interest encountered on slack. > Investigate mTLS in RPC layer > - > > Key: HBASE-26548 > URL: https://issues.apache.org/jira/browse/HBASE-26548 > Project: HBase > Issue Type: New Feature >Reporter: Bryan Beaudreault >Priority: Major > > Current authentication options are heavily based on SASL and Kerberos. For > organizations that don't already deploy Kerberos or other token provider, > this is a heavy lift. Another very common way of authenticating in the > industry is mTLS, which makes use of SSL certifications and can solve both > wire encryption and auth. For those already deploying trusted certificates in > their infra, mTLS may be much easier to integrate. > It isn't necessarily easy to implement this, but I do think we could use > existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I know > it's easy to add SSL to non-blocking IO through a > hadoop.rpc.socket.factory.class.default which returns SSLSockets, but that > doesn't touch on the certification verification at all. > Much more investigation is needed, but logging this due to some interest > encountered on slack. > Slack thread: > https://apache-hbase.slack.com/archives/C13K8NVAM/p1638980520110600 -- This message was sent by Atlassian Jira (v8.20.1#820001)
