[ 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: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org