[jira] [Comment Edited] (HBASE-27183) Support regionserver to connect to HMaster proxy port

["Viraj Jasani (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-27183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564499#comment-17564499 ] 

Viraj Jasani edited comment on HBASE-27183 at 7/9/22 3:06 AM:
--------------------------------------------------------------

{quote}the better way is to change the registry data on zookeeper, instead of letting region server to do this static configured port change?
{quote}
This is covered with PR [https://github.com/apache/hbase/pull/4606]

Basically we let master continue exposing it's binding port but in addition to that, also let it expose new proxy port for any client to connect to. So masterAddress and backupAddress znodes both will have new proto field named masterProxyPort. Now regionservers still continue using same ServerName object retrieved/deserialized from znodes but with a new config, they can switch to using new proxy port (only if master has exposed this port on znode in the first place). Does this sound good to you [~zhangduo]?
{quote}If there is rule to block some ports due to security, then the correct way is to not bind the master port in this blocked range?
{quote}
Valid question, no doubt. However, we have special encryption requirement where a service should bind on one specific port but that port is not open for secure communication. The secure channel is established on a new proxy port of master. On the master host, "proxy port to original port" redirection is automatically done, something outside the scope of HBase/Hadoop application layer.

 

cc [~apurtell] 


was (Author: vjasani):
{quote}the better way is to change the registry data on zookeeper, instead of letting region server to do this static configured port change?
{quote}
This is covered with PR [https://github.com/apache/hbase/pull/4606]

Basically we let master continue exposing it's binding port but in addition to that, also let it expose new proxy port for any client to connect to. So masterAddress and backupAddress znodes both will have new proto field named masterProxyPort. Now regionservers still continue using same ServerName object retrieved/deserialized from znodes but with a new config, they can switch to using new proxy port (only if master has exposed this port on znode in the first place). Does this sound good to you [~zhangduo]?
{quote}If there is rule to block some ports due to security, then the correct way is to not bind the master port in this blocked range?
{quote}
Valid question, no doubt. However, we have special encryption requirement where a service should bind on one specific port but that port is not open for secure communication. The secure channel is established on a new proxy port, and on the master host, proxy port to original port redirection is automatically done, something outside the scope of HBase/Hadoop application layer.

> Support regionserver to connect to HMaster proxy port
> -----------------------------------------------------
>
>                 Key: HBASE-27183
>                 URL: https://issues.apache.org/jira/browse/HBASE-27183
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Viraj Jasani
>            Assignee: Viraj Jasani
>            Priority: Major
>             Fix For: 3.0.0-alpha-4
>
>
> Regionservers get active master address from Zookeeper/Master registry and tries to make RPC calls to master.
> For security concerns, regionservers might require making connection to a different proxy port of master rather than it's original port retrieved from Zookeeper.
> Configs:
>  # hbase.master.expose.proxy.port: Master can use this config (int) to expose new proxy port on active and backup master znodes.
>  # hbase.regionserver.consume.master.proxy.port: Clients/Regionservers can use this config (boolean) to determine whether to connect to active master on new proxy port that master has exposed or continue using original port of master for connection.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)