[
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 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: [email protected]
For additional commands, e-mail: [email protected]
