hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-14445) Delegation tokens are not shared between KMS instances
Date Tue, 28 Nov 2017 07:03:00 GMT

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

Xiao Chen commented on HADOOP-14445:

Thanks all for the discussions about this, and Rushabh for a demonstration patch.
I've read through the comments of this one as well as HADOOP-14441. The patch would also take
care of HADOOP-14134.

To summarize and make sure my understanding is correct:
- We all agree the token sharing will be an issue
- For HDFS clients, the kp uri is already provided by NN. (Already done by HADOOP-14104)
- Token should be recognized from UGI credentials when clients trying to authenticate. (reason
for HADOOP-14441)
- Token renewal currently reads configs. We'd want this to be read from the token, and make
sure it's HA'ed. (reason for HADOOP-14134)
- Besides the ip:port of the KMS instance, there's also information about whether it's http
or https. We'd need a way to get this information, during renewal/cancelation.
- Backwards compatible: old clients should work with new server; new clients should work with
old server. 

Having a way to let clients work without reading configs feels to me to be a better approach,
and more inline with HADOOP-14104, and the 'transparent' name of HDFS encryption. It feels
to me a 'nameservice' solution doesn't add much value than the current way of using the full
kp uri, which by itself is a representation of available services. For added KMS scenario,
I think it's fine to let existing tokens to use the existing instances in that token's uri
- presumbly this is better than deploying the config and restarting the client. For removed
KMS instances, LBKMSCP handles it.

It seems to me the patch here has handled most of this pretty well. I plan to take a crack
at this tomorrow to:
- rebase to trunk
- address some earlier comments
- modify with some of my thoughts: seems we can use LBKMSCP to store the full provider uri;
some tests to verify compatibility

If you have any comments, please let me know. 

> 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
> 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

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

View raw message