[
https://issues.apache.org/jira/browse/HADOOP-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189292#comment-16189292
]
Xiaoyu Yao edited comment on HADOOP-14920 at 10/3/17 5:51 AM:
--------------------------------------------------------------
Thanks [~xiaochen] for the pointers. I briefly looked into the discussion on
HADOOP-14445. I seems that we agree the client should be able to set the
service as needed based on [~daryn]'s latest summary "client gets tokens and
sets service to kp uri"
The issue here is orthogonal to HADOOP-14445 where we want to enable *non-java
client* like curl+http to set the service for its requested delegation token.
This will be needed for non-java client even with HADOOP-14445 unless we remove
the service check in KMSClientProvider completely which is the solution 2
mentioned in the description.
was (Author: xyao):
Thanks [~xiaochen] for the pointers. I briefly looked into the discussion on
HADOOP-14445. I seems that we agree the client should be able to set the
service as needed based on [~daryn]'s latest summary "client gets tokens and
sets service to kp uri"
The issue here is orthogonal to HADOOP-14445 where we want to enable *non-java
client* like curl+http to set the service for its requested delegation token.
This will be needed for non-java client even with HADOOP-14445 unless we remove
the service check in KMSClientProvider completely.
> 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: [email protected]
For additional commands, e-mail: [email protected]
