[
https://issues.apache.org/jira/browse/HDFS-5910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945925#comment-13945925
]
Arpit Agarwal commented on HDFS-5910:
-------------------------------------
Thanks for making the changes Benoy.
{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}
Just for my understanding - lacking the peer's IP address is it your intention
to use configuration to decide the client's behavior?
I looked through the usages of {{isTrusted}} and some of them already have the
connected socket available, so it is fairly easy to query the remote's socket
address and pass it to {{isTrusted}}.
For the usage in getDataEncryptionKey(), we can refactor to pass a functor as
the encryption key to e.g. {{getFileChecksum}}. However I am okay with doing
the refactoring in a separate change. We can leave the parameter-less overload
of {{isTrusted}} for now and just use it from {{getEcnryptionKey}} and file a
separate Jira to fix it.
{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
{quote}
Thanks for the explanation. Will
[InetAddresses#forString|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/InetAddresses.html#forString%28java.lang.String%29]
from Guava work for you? I just checked and it's available in our build.
> 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)
