Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 2 Jan 2018 21:03:00 +0000 (UTC)
From: "Rushabh S Shah (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13073925.1495470249000.558899.1514926980393@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, 02 Jan 2018 21:03:06 -0000


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

Rushabh S Shah commented on HADOOP-14445:
-----------------------------------------

Thanks [~xiaochen] for the review.
bq. There is also 1 thing that I think missed in the recent compat discussions:
That is an excellent catch.
The general contract for hadoop upgrade is client should be the last one to upgrade after all the servers are upgraded.
But this argument doesn't hold true for multi cluster support. We need to support that.
Personally I don't like the idea of duplicatiing the tokens with different service fields because once the token lifetime expires, RM will have to renew 2 tokens instead of one.

One way I can think is have a conf like {{hadoop.kms.token.use.new.format}} and treat this release as bridge release.
Default this conf to false.
If the conf value is false, the client will create the token with old format.
KMSCP will have support for renewing/cancelling both format of tokens.

Once all the servers, clients, servers and all the clusters are upgraded, set the conf value to true.
If the conf value is true, it will add the token with new format.
I am also not a big supporter of conf based solutions but to ensure backwards compatibility I am proposing this.
Xiao: Let me know what you think.

Daryn is not back from vacation. He should be in tomorrow. I will discuss with him tomorrow and will update the ticket.
I will address all the review comments in next patch when we have clear way for fixing the last compatibility issue.


> 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: kms
>    Affects Versions: 2.8.0, 3.0.0-alpha1
>         Environment: CDH5.7.4, Kerberized, SSL, KMS-HA, at rest encryption
>            Reporter: Wei-Chiu Chuang
>            Assignee: Rushabh S Shah
>         Attachments: HADOOP-14445-branch-2.8.002.patch, HADOOP-14445-branch-2.8.patch, HADOOP-14445.002.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.4.14#64029)

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