[
https://issues.apache.org/jira/browse/HADOOP-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaoyu Yao updated HADOOP-14920:
--------------------------------
Fix Version/s: 2.8.4
> 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: Improvement
> Components: kms
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Priority: Major
> Fix For: 2.9.0, 3.1.0, 2.8.4
>
> Attachments: HADOOP-14920.001.patch, HADOOP-14920.002.patch,
> HADOOP-14920.003.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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
