Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 3 Jan 2018 07:32:00 +0000 (UTC)
From: "Xiao Chen (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13073925.1495470249000.562116.1514964720216@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: Wed, 03 Jan 2018 07:32:04 -0000


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

Xiao Chen commented on HADOOP-14445:
------------------------------------

Thanks for the comments Rushabh.

Agree on duplicating tokens is bad. Conf solution would be better than duplicating tokens, and is necessary for compat. This will bring us down to only support 1-direction compat (instead of bi-directional).
But even with conf, there could also be a time that it's not rolled to all nodes simultaneously (e.g. config deploy timing, multi-cluster etc.). Good we can control when the token creation would use new format, but it looks like we'd still need the fallback in {{DelegationTokenAuthenticatedURL#getDelegationTokenService}} right (which I'm okay with...)? I thought this could be another layer of authfilters, which can be taken out once we're sure no one is using the old token format. But perhaps just a fallback logic would be easier to do.


I know this stirs too many fallbacks and make the code difficult to read, but seems to be the only way to support rolling upgrade / deployment..

> 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