[
https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398980#comment-17398980
]
Bharath Vissapragada edited comment on HBASE-25051 at 8/13/21, 11:11 PM:
-------------------------------------------------------------------------
I think one way to fix this problem is to "advertise" the cluster ID as a part
of channel setup. This is an IPC protocol change. Currently the way connection
setup works is
1. client to server: socket connect()
2. client sends a connection preamble (validated on server and connection
closed if malformed)
3. client optionally does a sasl handshake (if configured)
(3) is where cluster ID is needed (if token is configured as a part of DIGEST
based auth).
Now my proposal is to modify it as follows.
1. client to server: socket connect()
2. server responds with a 16 byte UUID that is read by the client (client can
get the actual SASL mode with this clusterId info and looking up the tokens)
3. client sends a connection preamble (validated on server and connection
closed if malformed)
4. client optionally does a sasl handshake (using the sasl and token from
step(2)).
A sample implementation using netty IPC is something like this
https://github.com/bharathv/hbase/commit/95ff0d65828e8459d212e6173c00648b9c7b6814
. The patch still needs to do the following,
1. Move providers.selectProvider(clusterId, ticket) .. to after step (2)
2. Implement an equivalent change in Blocking IPC.
One problem I can think of is compatibility between old client and new server
(say during a rolling upgrade when server is upgraded first), I can see if I
can get it working by making client ignore this piece of response.
cc: [~zhangduo] WDYT. You think this breaks anything else too or is there a
better way?
was (Author: bharathv):
I think one way to fix this problem is to "advertise" the cluster ID as a part
of channel setup. This is an IPC protocol change. Currently the way connection
setup works is
1. client to server: socket connect()
2. client sends a connection preamble (validated on server and connection
closed if malformed)
3. client optionally does a sasl handshake (if configured)
(3) is where cluster ID is needed (if token is configured as a part of DIGEST
based auth).
Now my proposal is to modify it as follows.
1. client to server: socket connect()
2. server responds with a 16 byte UUID that is read by the client (client can
get the actual SASL mode with this clusterId info and looking up the tokens)
2. client sends a connection preamble (validated on server and connection
closed if malformed)
3. client optionally does a sasl handshake (using the sasl and token from
step(2)).
A sample implementation using netty IPC is something like this
https://github.com/bharathv/hbase/commit/95ff0d65828e8459d212e6173c00648b9c7b6814
. The patch still needs to do the following,
1. Move providers.selectProvider(clusterId, ticket) .. to after step (2)
2. Implement an equivalent change in Blocking IPC.
One problem I can think of is compatibility between old client and new server
(say during a rolling upgrade when server is upgraded first), I can see if I
can get it working by making client ignore this piece of response.
cc: [~zhangduo] WDYT. You think this breaks anything else too or is there a
better way?
> DIGEST based auth broken for MasterRegistry
> -------------------------------------------
>
> Key: HBASE-25051
> URL: https://issues.apache.org/jira/browse/HBASE-25051
> Project: HBase
> Issue Type: Sub-task
> Components: Client, security
> Affects Versions: 3.0.0-alpha-1, 2.3.0, 1.7.0
> Reporter: Bharath Vissapragada
> Assignee: Bharath Vissapragada
> Priority: Minor
>
> DIGEST-MD5 based sasl auth depends on cluster-ID to obtain tokens. With
> master registry, we have a circular dependency here because master registry
> needs an rpcClient to talk to masters (and to get cluster ID) and rpc-Client
> needs a clusterId if DIGEST based auth is configured. Earlier, there was a ZK
> client that has its own authentication mechanism to fetch the cluster ID.
> HBASE-23330, I think doesn't fully fix the problem. It depends on an active
> connection to fetch delegation tokens for the MR job and that inherently
> assumes that the active connection does not use a DIGEST auth.
> It is not clear to me how common it is to use DIGEST based auth in
> connections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
