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] [Updated] (HADOOP-13155) Implement TokenRenewer to renew and cancel delegation tokens in KMS
Date Tue, 31 May 2016 06:11:13 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Xiao Chen updated HADOOP-13155:
    Attachment: HADOOP-13155.05.patch

Thanks [~andrew.wang] for the review! Appreciate your comments.
Patch 5 addresses some of them, with the exceptions open for discuss:
bq. Regarding moving the config key, I think the other Renewers get around this by embedding
the static class within the parent class and accessing required state statically. I think
the parent here would be KMSClientProvider. It wouldn't be good to tie renewal to this HDFS
key anyway, since the KMS is used for more than just HDFS encryption.
Let's talk about this in more details.
I think there're 2 things mixed here:
# The renewer could be a static inner class of KMSClientProvider.
Sure, I moved the renewer into KMSCP.
# ...accessing required state statically...
I don't think this is true. Since it's static it wouldn't read any states, just configs, right?
Among those renewers, {{TokenAspect}} and {{MRDelegationTokenRenewer}} are not embedded. Both
of them plus the renewers embedded in {{TimelineDelegationTokenIdentifier}} and {{RMDelegationTokenIdentifier}}
all create the instance to {{renewDelegationToken}} using {{conf}} and {{token}}. For KMS,
we can't get the url from the token because 1) it doesn't have proto (i.e. http v.s. https)
2) it's not HA-aware.
So I think we need to read from config, which is what {{KMSUtil#createKeyProvider}} does when
it calls into [KMSCP#createProvider|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/kms/KMSClientProvider.java#L233-L241].
I think [~jojochuang]'s proposal may work (thanks Wei-Chiu!), but I also found HDFS-7004 when
the dfs config was added, and the linked HADOOP-11054 saying 'In the case of HDFS encryption,
it would be desirable to be explicitly specify a KeyProvider URI to avoid obscure misconfigurations.'.
IMO, KMS being a general component should just use the common {{hadoop.security.key.provider.path}}.

Why does renewal in particularly need a URL with USER_NAME set? IIUC this is needed for PseudoAuthentication,
but here we're doing DT authentication?
Good catch!! I guess I was not super clear on the concept so I missed it: Initially PseudoAuth
was failing and I debugged and added user name to let it pass. However, since we're using
DT here we definitely should just use DTAuth. After more background work, I found out theres
a bug in {{DelegationTokenAuthenticatedURL}} when handling delegation tokens for renew/cancel/add.
({{openConnection}} was done right, in HADOOP-10880, but seems missed renew/cancel/add.).
I fixed it in DTAuthenticatedURL and DTAuthenticator, by using a similar fall back logic.
(Can't do it in DTAuthenticatedURL along because the connection object is created in DTAuthenticator
for those methods.)
Unit test on this when {{DelegationTokenAuthenticatedURL#useQueryStringforDelegationToken
== false}} seems to be non-trivial and not easy to mock/spy, since it's all created on the
fly. Considering this is supposed to be deprecated, I manually tested it by setting the default
to true.

> Implement TokenRenewer to renew and cancel delegation tokens in KMS
> -------------------------------------------------------------------
>                 Key: HADOOP-13155
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13155
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Xiao Chen
>            Assignee: Xiao Chen
>         Attachments: HADOOP-13155.01.patch, HADOOP-13155.02.patch, HADOOP-13155.03.patch,
HADOOP-13155.04.patch, HADOOP-13155.05.patch, HADOOP-13155.pre.patch
> Service DelegationToken (DT) renewal is done in Yarn by {{org.apache.hadoop.yarn.server.resourcemanager.security.DelegationTokenRenewer}},
where it calls {{Token#renew}} and uses ServiceLoader to find the renewer class ([code|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/Token.java#L382]),
and invokes the renew method from it.
> We seem to miss the token renewer class in KMS / HttpFSFileSystem, and hence Yarn defaults
to {{TrivialRenewer}} for DT of such kinds, resulting in the token not being renewed.
> As a side note, {{HttpFSFileSystem}} does have a {{renewDelegationToken}} API, but I
don't see it invoked in hadoop code base. KMS does not have any renew hook.

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