[
https://issues.apache.org/jira/browse/HDFS-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430389#comment-13430389
]
Eli Collins commented on HDFS-3637:
-----------------------------------
Thanks for the info on testing and performance, good stuff.
bq. It also needs to be a few multiples of the block token lifetime, since
several block tokens are valid at any given time (the current and the last two,
by default.)
Got it, put that sentence in a comment by 15s? Wasn't clear on how you arrived
at this value.
bq. Not quite sure what you mean by this. In which case should we blow up if
encryptionKey is null? Note that the client will never be allowed to not use
encryption if the DN is configured to use it. The error message won't be nice,
but no data will ever be transmitted in the clear.
Yea, I was wondering where the "encryption is enabled server side but you're
not using it client side" check/message was. Another jira?
bq. I called it "getEncryptionKey" to be in keeping with "getDelegationToken".
More appropriate for these would probably be "generate" instead of "get". What
are your thoughts on this?
I think the current naming is OK, was just wondering whether the javadoc should
indicate it's generating a new key, given getDelegationToken I think it's fine
as is.
bq. Perhaps we should just remove the TODO?
Agree.
+1 to your updated patch. The only delta suggested above is removing the TODO
and adding a comment by the timeout in the test so feel free to avoid
re-spinning the patch just for that.
> Add support for encrypting the DataTransferProtocol
> ---------------------------------------------------
>
> Key: HDFS-3637
> URL: https://issues.apache.org/jira/browse/HDFS-3637
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: data-node, hdfs client, security
> Affects Versions: 2.0.0-alpha
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
> Attachments: HDFS-3637.patch, HDFS-3637.patch, HDFS-3637.patch,
> HDFS-3637.patch
>
>
> Currently all HDFS RPCs performed by NNs/DNs/clients can be optionally
> encrypted. However, actual data read or written between DNs and clients (or
> DNs to DNs) is sent in the clear. When processing sensitive data on a shared
> cluster, confidentiality of the data read/written from/to HDFS may be desired.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
