[
https://issues.apache.org/jira/browse/HADOOP-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16190055#comment-16190055
]
Xiao Chen commented on HADOOP-14920:
------------------------------------
Thanks [~xyao] for looking and explaining. Looking at the webhdfs example, I
don't see a reason we should not do it. Also agree having service check would
still be good to have.
Some questions/comments, (some Qs I'm not clear, will try to figure out time
permits...):
- httpfs highly shares webhdfs code inside NN, and highly shares authentication
code with KMS. Would adding a service param here mean httpfs would be
double-service-configured?
- if the service could be set arbitrarily, it would be good to find a way to
make it easier to debug...
- Delegation token related ops are not even in the [kms
docs|http://hadoop.apache.org/docs/r3.0.0-alpha4/hadoop-kms/index.html#KMS_HTTP_REST_API],
would be great to add those too. Can be a separate jira.
> KMSClientProvider won't work with KMS delegation token retrieved from
> non-Java client.
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-14920
> URL: https://issues.apache.org/jira/browse/HADOOP-14920
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Attachments: HADOOP-14920.001.patch
>
>
> HADOOP-13381 added support to use KMS delegation token to connect to KMS
> server for key operations. However, the logic to check if the UGI container
> KMS delegation token assumes that the token must contain a service attribute.
> Otherwise, a KMS delegation token won't be recognized.
> For delegation token obtained via non-java client such curl (http), the
> default DelegationTokenAuthenticationHandler only support *renewer* parameter
> and assume the client itself will add the service attribute. This makes a
> java client with KMSClientProvdier can't use for KMS delegation token
> retrieved form non-java client because the token does not contain a service
> attribute.
> I did some investigation on this and found two solutions:
> 1. Similar use case exists for webhdfs, and webhdfs supports it with a
> ["service"
> parameter|https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Get_Delegation_Token].
> We can do this similarly by allowing client to specify a service attribute in
> the request URL and included in the token returned like webhdfs. Even though
> this will change in DelegationTokenAuthenticationHandler and may affect many
> other web component, this seems to be a clean and low risk solution because
> it will be an optional parameter. Also, other components get non-java client
> interop support for free if they have the similar use case.
> 2. The other way to solve this is to release the token check in
> KMSClientProvider to check only the token kind instead of the service. This
> is an easy work around but seems less optimal to me.
> cc: [~xiaochen] for additional input.
--
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
