You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Bharath Vissapragada (Jira)" <ji...@apache.org> on 2021/12/08 17:41:00 UTC
[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)