hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3637) Add support for encrypting the DataTransferProtocol
Date Tue, 07 Aug 2012 01:33:02 GMT

    [ 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

        

Mime
View raw message