[
https://issues.apache.org/jira/browse/HADOOP-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281331#comment-16281331
]
Xiao Chen commented on HADOOP-14445:
------------------------------------
Looking around this again, I don't think the conf override solution can solve
the following problem:
For pure kms operations like {{hadoop key list}}, we rely on the kp conf to
list from the correct kms. Even with this fix, we'd still need the conf. It's
not reasonable to let client separate their configurations for different
purpose of the hadoop rpc / apis.
Checking the code, I think old clients / renewer should always work even with
the new token. IMO we need to have a fall back logic to the configurations,
rather than override. Specifically, when {new clients cannot find the new token
format, new renewer cannot create kp from the token format}, they'll use the
config as a last measure. Error handling is still tricky since we'd ideally
want to tell from the exception or client log on what exactly was attempted and
failed.
Other than the above I think this really should work.
Some minor comments:
- I'd mark {{DelegationTokenAuthenticatedURL#getDelegationTokenService}} as
{{InterfaceAudience.Private}}.
- Add comments on the KMSCP override of the above method to explain why.
- I'm scared of {{SecurityUtil#useIpForTokenService}}, which is used to
buildTokenService. I don't see any problems but would love to see a test
covering it.
- Can we extract the unit-test-only {{KMSUtil}} code to a test-only method, and
make it only possible to execute from unit test? Maybe via some injector or
better approaches.
> 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.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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
