hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Haohui Mai (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11726) Allow applications to access both secure and insecure clusters at the same time
Date Mon, 23 Mar 2015 21:36:53 GMT

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

Haohui Mai commented on HADOOP-11726:
-------------------------------------

bq. will it solve the "implementing a secure distcp application that can only write to secure
clusters" issue?

Yes. Obviously the application to verify whether the token is authentic, but it is feasible
as long as you don't swallow the error at the file system layer.

bq. 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. 

Just to echo my comments in HDFS-6776 (at least for the distcp use case):

bq. What can be done is to put the hack there, and to inject a corresponding token into token
cache so that the filesystem no longer need to get the DT from the server. 

https://issues.apache.org/jira/browse/HDFS-6776?focusedCommentId=14121719&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14121719



> 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