[jira] [Commented] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader

["Andrew Purtell (JIRA)" <ji...@apache.org>]

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

Andrew Purtell commented on HBASE-22253:
----------------------------------------

This shouldn’t be possible. The lily fake RS should not be allowed to authenticate to ZK with the same credentials as HBase. It shouldn’t be able to write znodes with the HBase principal. This is an operator error, a deliberate hack, really. 

> An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
> ----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-22253
>                 URL: https://issues.apache.org/jira/browse/HBASE-22253
>             Project: HBase
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 3.0.0, 2.1.0, 2.2.0
>            Reporter: Esteban Gutierrez
>            Assignee: Esteban Gutierrez
>            Priority: Critical
>
> We ran into a situation were a rogue Lily HBase Indexer [SEP Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169] sharing the same {{zookeeper.znode.parent}} claimed to be AuthenticationTokenSecretManager for an HBase cluster. This situation undesirable since the leader running on the HBase cluster doesn't steps down when the rogue leader registers in the HBase cluster and both will start rolling keys with the same IDs causing authentication errors. Even a reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we should make sure that we step down as leader correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)