Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 30 May 2017 17:27:04 +0000 (UTC)
From: "Yongjun Zhang (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13073925.1495470249000.322622.1496165224350@Atlassian.JIRA>
In-Reply-To: <JIRA.13073925.1495470249000@Atlassian.JIRA>
References: <JIRA.13073925.1495470249000@Atlassian.JIRA> <JIRA.13073925.1495470249804@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HADOOP-14445) Delegation tokens are not shared
 between KMS instances
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 30 May 2017 17:27:10 -0000


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

Yongjun Zhang commented on HADOOP-14445:
----------------------------------------

Thanks much [~shahrs87].

My thinking is:

For clients which are running without the fix, the behavior will be the same as before;
For clients which are started after installing the fix, the tokens will be stored with the new key;
If different pieces of a client job are running with different software (some has the fix, some don't), then fallback may or may not work.

Does this make sense to you?  Maybe we can add the tokens with both the old key and new key, then apply fallback when needed, so fallback will be successful?

[~asuresh]'s #2 proposal at 
https://issues.apache.org/jira/browse/HADOOP-14441?focusedCommentId=16019893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16019893
seems more robust, but I'm not sure how involved this solution is too.

Thanks.


> Delegation tokens are not shared between KMS instances
> ------------------------------------------------------
>
>                 Key: HADOOP-14445
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14445
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: documentation, kms
>    Affects Versions: 2.8.0, 3.0.0-alpha1
>            Reporter: Wei-Chiu Chuang
>            Assignee: Rushabh S Shah
>         Attachments: HADOOP-14445-branch-2.8.patch
>
>
> As discovered in HADOOP-14441, KMS HA using LoadBalancingKMSClientProvider do not share delegation tokens. (a client uses KMS address/port as the key for delegation token)
> {code:title=DelegationTokenAuthenticatedURL#openConnection}
> if (!creds.getAllTokens().isEmpty()) {
>         InetSocketAddress serviceAddr = new InetSocketAddress(url.getHost(),
>             url.getPort());
>         Text service = SecurityUtil.buildTokenService(serviceAddr);
>         dToken = creds.getToken(service);
> {code}
> But KMS doc states:
> {quote}
> Delegation Tokens
> Similar to HTTP authentication, KMS uses Hadoop Authentication for delegation tokens too.
> Under HA, A KMS instance must verify the delegation token given by another KMS instance, by checking the shared secret used to sign the delegation token. To do this, all KMS instances must be able to retrieve the shared secret from ZooKeeper.
> {quote}
> We should either update the KMS documentation, or fix this code to share delegation tokens.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org