[
https://issues.apache.org/jira/browse/HDFS-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13429649#comment-13429649
]
Eli Collins commented on HDFS-3637:
-----------------------------------
ATM,
Overall design and implementation looks great - nice work.
Testing?
What's the latest performance slowdown for the basic HDFS read/write path with
RC4 enabled?
BlockReaderFactory
- Seems like DFSOutputStream#newBlockReader in the conf.useLegacyBlockReader
conditional should use a precondition or throw an RTE (eg AssertionError) if
encryptionKey is null, otherwise the client will just consider this a dead DN
and keep trying.
- In the other case it should blow up if encryptionKey is null right, otherwise
we can have it enabled server side but allow a client not to use it?
hdfs-default.xml
- The dfs.encrypt.data.transfer description that this is a server-side config
- Add dfs.encrypt.data.transfer.algorithm with out a default and list two
supported values?
DataTransferEncryptor
- What are the main HDFS-specific tweaks/delta from TSaslTransport?
DFSClient
- Shouldn't shouldEncryptData throw an exception if server defaults is null
instead of assume it shouldn't encrypt? Seems more secure, eg if we ever
introduce a bug that results in the NN returning a null server default (should
never happen currently).
FSN
- Consider pulling out the block manager not setting the block pool ID bug to a
separate change?
TestEncryptedTransfer
- Use DFS_BLOCK_ACCESS_TOKEN_LIFETIME_DEFAULT instead of 15s? Also perhaps
update the relevant NN java doc to indicate that "getting" the key generates a
new key with this timeout.
RemoteBlockReader
- Jira for supporting encryption or remove this TODO?
- Are the sendReadResult write timeout and DFSOutputStream#flush a separate
issue or something introduced here?
> 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
>
>
> 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
