hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yongjun Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11726) Allow applications to access both secure and insecure clusters at the same time
Date Thu, 19 Mar 2015 01:25:39 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368301#comment-14368301
] 

Yongjun Zhang commented on HADOOP-11726:
----------------------------------------

HI [~wheat9],

Thanks for creating this jira. For the dummy delegation token approach you listed, will it
solve the "implementing a secure distcp application that can only write to secure clusters"
issue? 

For the "fix all application" approach, I found that for distcp, there is a wildcard issue
that the change has to go beyond distcp. See my latest comment in HDFS-7036. I wonder if it's
feasible even if we go beyond distcp without any fundamental thing like approach 1 and 3 you
listed. It'd be nice if you can comment in that jira.

Thanks.



> Allow applications to access both secure and insecure clusters at the same time
> -------------------------------------------------------------------------------
>
>                 Key: HADOOP-11726
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11726
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Haohui Mai
>
> Today there are multiple integration issues when an application (particularly, distcp)
access both secure and insecure clusters (e.g., HDFS-6776 / HDFS-7036)
> There are four use cases in this scenario:
> * Secure <-> Secure. Works.
> * Insecure <-> Insecure. Works.
> * Accessing secure clusters from insecure client. Will not work as expected. The insecure
client won't be able to be authenticated with the secure client, otherwise it is a security
vulnerability.
> * Accessing insecure clusters from secure client. Currently it will not work as the secure
client won't be able to obtain a delegation token from the insecure cluster.
> This jira proposes to fix the last use case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message