[
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)
