You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Charles Lamb (JIRA)" <ji...@apache.org> on 2014/08/04 23:34:12 UTC
[jira] [Commented] (HDFS-6394) HDFS encryption documentation
[ https://issues.apache.org/jira/browse/HDFS-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085320#comment-14085320 ]
Charles Lamb commented on HDFS-6394:
------------------------------------
Nice writeup [~andrew.wang].
Here are some suggested changes:
bq. Once configured, data read from and written to HDFS will be <transparently> encrypted and decrypted without requiring changes to user application code.
s/will be/is/
bq. This encryption is also <end-to-end>, which means the data can only encrypted and decrypted by the client.
s/can only/is only/
bq. HDFS never stores or has access to unencrypted data or data encryption keys.
s/stores or has access to/stores, or has access to,/
bq. Having transparent encryption built-in to HDFS makes it easier for organizations to comply with these regulations.
s/built-in to/built into/
bq. Encryption can also be done at the application-level, but integrating it into HDFS means that existing HDFS applications can operate on encrypted data without changes.
but by integrating it into HDFS, existing HDFS applications can ...
bq. Integrating directly into HDFS also means we can provide stronger semantics about the handling of encrypted files, as well as better integration with other HDFS functionality.
Integrating directly also means that HDFS can provide stronger...
bq. The KMS implements additional functionality which enables creation and decryption of <encrypted encryption keys (EEKs)>.
which enables encrypted encryption keys (EEKs) to be created and decrypted.
bq. When creating a new EEK, the KMS will generate a new random key, encrypt it with the specified key, and return the EEK to the client.
s/will generate/generates/, s/encrypt it/encrypts it/, s/return/returns/
bq. When decrypting an EEK, the KMS will check that the user has access to the encryption key, uses it to decrypt the EEK, and returns the decrypted encryption key.
s/will check/checks/
bq. When creating a new file in an encryption zone, the NameNode will ask the KMS to generate a new EDEK encrypted with the encryption zone's key.
s/will ask/asks/
bq. Assuming that is successful, the client can finally use the DEK to decrypt the file's contents.
s/can finally use/uses/
bq. All of the above steps for the read and write path happens automatically through interactions between the DFSClient, the NameNode, and the KMS.
s/happens/happen/
bq. It should be noted that access to encrypted file data and metadata is controlled by normal HDFS filesystem permissions.
s/It should be noted that access/Access/
bq. This means compromising HDFS (e.g., gaining access to an HDFS superuser account) allows access to ciphertext and encrypted keys.
This means that if the HDFS superuser account is compromised, access is gained to ciphertext and encrypted keys.
> HDFS encryption documentation
> -----------------------------
>
> Key: HDFS-6394
> URL: https://issues.apache.org/jira/browse/HDFS-6394
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode, security
> Reporter: Alejandro Abdelnur
> Assignee: Andrew Wang
> Attachments: hdfs-6394.001.patch
>
>
> Documentation for HDFS encryption behavior and configuration
--
This message was sent by Atlassian JIRA
(v6.2#6252)