[
https://issues.apache.org/jira/browse/HADOOP-10769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052049#comment-14052049
]
Aaron T. Myers commented on HADOOP-10769:
-----------------------------------------
bq. That seems pretty convoluted.
In the future, would appreciate you explaining why a proposal seems convoluted.
It seems quite straightforward to me, so not sure how to address this comment.
This proposal is an attempt to compromise and address your concern, which I
understood to be not wanting to have this method baked into the {{KeyProvider}}
interface, and thus allow some implementations to use it and others to not.
bq. A. For #1 can't we have a standalone DelegationTokenClient component -
especially since there is another jira for refactoring delegation token support
out into common to be more reusable? Such a client could then potentially be
used inside the KMSClientKeyProvider.
That JIRA seems to me to be orthogonal to this one, so I don't think we should
couple the two. How the {{KmsClientKeyProvider}} gets tokens under the hood
shouldn't have anything to do with the API. Also, as you point out later in
question C, it will still be necessary for the submitting code to somehow
call/interact with the tokens/credentials of the KeyProvider at submission
time, so I don't think it's actually possible to entirely encapsulate the
delegation token fetching/storage within the {{KeyProvider}} implementation.
bq. B. Wouldn't it be better if providers that know they need delegation tokens
were able to handle #2 themselves?
How about changing the proposal to mimic what's done in FileSystem today and
add a method like "{{public Token<?>[] addDelegationTokens(final String
renewer, Credentials credentials)}}" to the {{KeyProvider}} API? The default
behavior would be to add no tokens to the provided {{Credentials}} object, but
the {{KmsClientKeyProvider}} could instead fetch and stash away the tokens in
the provided {{Credentials}} object.
bq. C. How is #3 above going to be handled using the current interfaces - I
don't see how it is being added to the interaction currently?
I believe this will happen transparently, because the tokens contained in the
{{Credentials}} object will be added to the UGI object which will then be used
to authenticate all the RPCs. The {{KeyProvider}} shouldn't need access to the
tokens in the tasks.
bq. D. If the KMSClientKeyProvider had access to the credentials object (
already have access to UserKeyProvider) or some other execution context itself
then could that be a way that #3 could be addressed?
If I'm understanding you correctly, I think this basically the same as what I'm
proposing above in response to your question B. Am I right about that? Will
this work for you?
> Add getDelegationToken() method to KeyProvider
> ----------------------------------------------
>
> Key: HADOOP-10769
> URL: https://issues.apache.org/jira/browse/HADOOP-10769
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 3.0.0
> Reporter: Alejandro Abdelnur
> Assignee: Arun Suresh
>
> The KeyProvider API needs to return delegation tokens to enable access to the
> KeyProvider from processes without Kerberos credentials (ie Yarn containers).
> This is required for HDFS encryption and KMS integration.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
