[
https://issues.apache.org/jira/browse/HDFS-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043766#comment-14043766
]
Owen O'Malley commented on HDFS-6134:
-------------------------------------
{quote}
I don’t see a previous -1 in any of the related JIRAs.
{quote}
I had consistently stated objections and some of them have been addressed, but
the fundamentals have become clear through this jira. I am always hesitant to
use a -1 and I certainly don't do so lightly. Through the discussion, my
opinion is transparent encryption in HDFS is a *really* bad idea. Let's run
through the case:
The one claimed benefit of integrating encryption into HDFS is that the user
doesn't need to change the URLs that they use. I believe this to be a
*disadvantage* because it hides the fact that these files are encrypted. That
said, a better approach if that is the desired goal is to create a *NEW* filter
filesystem that the user can configure to respond to hdfs urls that does silent
encryption. This imposes *NO* penalty on people who don't want encryption and
does not require hacks to the FileSystem API.
{quote}
FileSystem will had a new create()/open() signature to support this, if you
have access to the file but not the key, you can use the new signatures to copy
files as per the usecase you are mentioning.
{quote}
This will break every backup application. Some of them, such as HAR and DistCp
you can hack to handle HDFS as a special case, but this kind of special casing
always comes back to haunt us as a project. Changing FileSystem API is a really
bad idea and inducing more differences between the various implementations will
create many more problems than you are trying to avoid.
> Transparent data at rest encryption
> -----------------------------------
>
> Key: HDFS-6134
> URL: https://issues.apache.org/jira/browse/HDFS-6134
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: security
> Affects Versions: 2.3.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: HDFSDataatRestEncryptionProposal_obsolete.pdf,
> HDFSEncryptionConceptualDesignProposal-2014-06-20.pdf
>
>
> Because of privacy and security regulations, for many industries, sensitive
> data at rest must be in encrypted form. For example: the healthcare industry
> (HIPAA regulations), the card payment industry (PCI DSS regulations) or the
> US government (FISMA regulations).
> This JIRA aims to provide a mechanism to encrypt HDFS data at rest that can
> be used transparently by any application accessing HDFS via Hadoop Filesystem
> Java API, Hadoop libhdfs C library, or WebHDFS REST API.
> The resulting implementation should be able to be used in compliance with
> different regulation requirements.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
