[ https://issues.apache.org/jira/browse/HBASE-23330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bharath Vissapragada updated HBASE-23330: ----------------------------------------- Fix Version/s: (was: HBASE-18095) 2.3.0 > 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 > Fix For: 3.0.0, 2.3.0 > > > 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)