hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoy Antony (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-5910) Enhance DataTransferProtocol to allow per-connection choice of encryption/plain-text
Date Mon, 24 Mar 2014 23:56:44 GMT

     [ https://issues.apache.org/jira/browse/HDFS-5910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Benoy Antony updated HDFS-5910:
-------------------------------

    Attachment: HDFS-5910.patch

Thanks [~arpitagarwal]  for the comments.

I am attaching a new based on some of your comments. I request guidance on #1 and #4.
{quote}
 	1.	isSecureOnClient may also want to use the peer's address to make a decision. e.g. intra-cluster
transfer vs. distcp to remote cluster.
{quote}


The ip address of namenode or datanode is not available at some of the client invocations.
Please let me know if there is a way to get an ip address..

{quote}
2.	Related to #1, isSecureOnClient and isSecureOnServer look awkward. How about replacing
both with isTrustedChannel that takes the peer's IP address? We should probably avoid overloading
the term secure in this context since there is a related concept ofPeer#hasSecureChannel().
{quote}

I have renamed the class to TrustedChannelResolver and function to isTrusted() . 

{quote}
3. Could you please update the documentation
{quote}

done

{quote}
4. Is the InetAddress.getByName call in DataXceiver#getClientAddress necessary? If it were
necessary it would have been a security hole since DNS resolution may yield a different IP
address than the one used by the client. It turns out for the kinds of Peers we are interested
in this will be an IP address, so let's just remove the call.
{quote}

 I wanted to use InetAddress as the argument to TrustedChannelResolver than a string-ip-address
to maintain parity with _SaslPropertiesResolver_. To convert a string ip, I use InetAddress.getByName

>From the documentation of InetAddress.getByName(String host):
The host name can either be a machine name, such as "java.sun.com", or a textual representation
of its IP address. If a literal IP address is supplied, only the validity of the address format
is checked.
So basically , if the argument is ip address, getByName doesn't do a DNS check.
If there is a different way to get the InetAddress , we can definitely use that. 

Other option is to not care about the parity with _SaslPropertiesResolver_  and pass the string
ip address. 
Yet another option will be to pass the Peer itself to TrustedChannelResolver  so that the
custom implementation can take care of getting the ip address etc.   Will be great to get
your opinion on this. 
 


> Enhance DataTransferProtocol to allow per-connection choice of encryption/plain-text
> ------------------------------------------------------------------------------------
>
>                 Key: HDFS-5910
>                 URL: https://issues.apache.org/jira/browse/HDFS-5910
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: security
>    Affects Versions: 2.2.0
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>         Attachments: HDFS-5910.patch, HDFS-5910.patch, HDFS-5910.patch
>
>
> It is possible to enable encryption of DataTransferProtocol. 
> In some use cases, it is required to encrypt data transfer with some clients , but communicate
in plain text with some other clients and data nodes.
> A sample use case will be that any data transfer inside a firewall can be in plain text
whereas any data transfer from clients  outside the firewall needs to be encrypted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message