[ https://issues.apache.org/jira/browse/HBASE-23330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16984581#comment-16984581 ]
Wellington Chevreuil commented on HBASE-23330: ---------------------------------------------- {quote}We will still have it in ZK but clients aren't expected to have access to it (or ZK less like you said).{quote} Ah, I see. Then we are only changing it for client API, not server side internals, such as ReplicationSource initialisation? {quote}I don't think we'd have too much performance overhead because the information looked up is very small and cached on the client side and not every client does it{quote} Ok, then since it's not a performance concern, argument to provide it via http is mainly to complete remove client dependency on ZK? > Expose cluster ID for clients using it for delegation token based auth > ------------------------------------------------------------------------ > > Key: HBASE-23330 > URL: https://issues.apache.org/jira/browse/HBASE-23330 > Project: HBase > Issue Type: Sub-task > Components: Client, master > Affects Versions: 3.0.0 > Reporter: Bharath Vissapragada > Assignee: Bharath Vissapragada > Priority: Major > > As Gary Helming noted in HBASE-18095, some clients use Cluster ID for > delgation based auth. > {quote} > There is an additional complication here for token-based authentication. When > a delegation token is used for SASL authentication, the client uses the > cluster ID obtained from Zookeeper to select the token identifier to use. So > there would also need to be some Zookeeper-less, unauthenticated way to > obtain the cluster ID as well. > {quote} > Once we move ZK out of the picture, cluster ID sits behind an end point that > needs to be authenticated. Figure out a way to expose this to clients. > One suggestion in the comments (from Andrew) > {quote} > Cluster ID lookup is most easily accomplished with a new servlet on the > HTTP(S) endpoint on the masters, serving the cluster ID as plain text. It > can't share the RPC server endpoint when SASL is enabled because any > interaction with that endpoint must be authenticated. This is ugly but > alternatives seem worse. One alternative would be a second RPC port for APIs > that do not / cannot require prior authentication. > {quote} > There could be implications if SPNEGO is enabled on these http(s) end points. > We need to make sure that it is handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)