[
https://issues.apache.org/jira/browse/HBASE-28321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808269#comment-17808269
]
Duo Zhang commented on HBASE-28321:
-----------------------------------
I think for server principal, we could do something like [~bharathv] proposed
on HBASE-25051 to solve this problem, i.e, to get the information through
connection setup.
For ClusterId, it is more like a cluster wide configuration, so usually we want
to initialize it when creating the RpcClient, not a RpcConnection, I believe
that is also part of the reason that why the work there finally hung for a long
time.
But for server principal, I think it is OK to return it before starting sasl
negotiate, but the problem is how to do this in a backward compatible way.
Will be back soon after I find out some ways.
Thanks.
> RpcConnectionRegistry is broken when security is enabled and we use different
> principal for master and region server
> --------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-28321
> URL: https://issues.apache.org/jira/browse/HBASE-28321
> Project: HBase
> Issue Type: Sub-task
> Components: Client, IPC/RPC, security
> Reporter: Duo Zhang
> Priority: Critical
>
> After introducing RpcConnectionRegistry, we let master and region server both
> implement ClientMetaService.
> In our current client architecture, when security is enabled, we rely on the
> record in SecurityInfo to determine the server principal to use,
> unfortunately there is only one principal can be specified, so if we use
> different principal for master and region server, either we can not connect
> to master, or we can not connect to region server.
> And just changing the server principal field in SecurityInfo to an array can
> not solve the problem, as when connecting, we do not know whether the remote
> server is a master or region server, so we still can not determine which
> principal to use...
> Anyway, since this has been in our code base since 2.5.0, it is not a new
> problem, so just set it as critical, not a blocker. But we should find out
> the solution ASAP.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
