kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Birdsell <jordan.birdsell.k...@statefarm.com>
Subject RE: Kudu - Data Encryption
Date Mon, 28 Mar 2016 14:07:00 GMT
Hey Patrick,

If I understand these methods correctly, they both decrypt the entire volume on disk before
anything can be read.  We would require an approach that decrypts data only as its read into
memory (if the client decides to store decrypted output, that’s on them) and where the only
data decrypted is the data being used.  We could potentially tackle part of this using these
methods by creating a different volume for each “table” however we would still be decrypting
on disk leaving data security in the hands of the fs permissions.

I’m sorry for not getting to this point sooner in the chain, was just trying to better understand
your suggestion.  If I’ve gotten something wrong here let me know.

Thanks again for your help,
Jordan Birdsell
Data Engineer
State Farm - Research

From: Patrick Angeles [mailto:patrick@cloudera.com]
Sent: Saturday, March 26, 2016 2:59 PM
To: user@kudu.incubator.apache.org
Subject: Re: Kudu - Data Encryption

Yes, or dm-crypt.

Patrick Angeles
Chief Architect Financial Services
151 West 26th Street Suite 1002 | New York, NY 10001
+1 (650) 644-3943

On Sat, Mar 26, 2016 at 8:50 AM, Jordan Birdsell <jordan.birdsell.kdvm@statefarm.com<mailto:jordan.birdsell.kdvm@statefarm.com>>
wrote:
For clarification, are you talking about using something like ecryptfs?


-----Original Message-----
From: Patrick Angeles [patrick@cloudera.com<mailto:patrick@cloudera.com>]
Sent: Friday, March 25, 2016 03:40 PM US Mountain Standard Time
To: user@kudu.incubator.apache.org<mailto:user@kudu.incubator.apache.org>
Subject: Re: Kudu - Data Encryption
Hey Jordan,

Volume-level encryption is at the filesystem level and so would effectively prevent physical
theft and most OS-level attacks. In this sense, it is functionally as secure as HDFS encrypt.

One thing HDFS encrypt lets you do, however, is to selectively encrypt certain files and directories.
You can't do this with volume-level encryption -- it's all or nothing. Which might be fine
for some use cases.



Patrick Angeles
Chief Architect Financial Services
151 West 26th Street Suite 1002 | New York, NY 10001
+1 (650) 644-3943<tel:%2B1%20%28650%29%20644-3943>

On Fri, Mar 25, 2016 at 5:45 PM, Jordan Birdsell <jordan.birdsell.kdvm@statefarm.com<mailto:jordan.birdsell.kdvm@statefarm.com>>
wrote:
Hey Patrick,

Thanks for the quick response. This approach would leave all data unencrypted while Kudu is
being used and thus only protect against physical theft, would it not?  We’re looking for
something more like the HDFS encryption, prevents os-level attacks, unencrypted on the client,
etc. Sorry if I’ve misunderstood your meaning.

Thanks,
Jordan Birdsell
Data Engineer
State Farm - Research

From: Patrick Angeles [mailto:patrick@cloudera.com<mailto:patrick@cloudera.com>]
Sent: Friday, March 25, 2016 4:54 PM
To: user@kudu.incubator.apache.org<mailto:user@kudu.incubator.apache.org>
Subject: Re: Kudu - Data Encryption

Hey Jordan,

It would help to understand your particular requirements. For example, can it be solved using
volume-level encryption? (This could be done today.) Are you looking for per-table or per-column
encryption?

Patrick Angeles
Chief Architect Financial Services
151 West 26th Street Suite 1002 | New York, NY 10001
+1 (650) 644-3943<tel:%2B1%20%28650%29%20644-3943>

On Fri, Mar 25, 2016 at 4:40 PM, Jordan Birdsell <jordan.birdsell.kdvm@statefarm.com<mailto:jordan.birdsell.kdvm@statefarm.com>>
wrote:
In the release notes section I see mention that lack of encryption is a current security limitation,
however I do not see a JIRA for tracking this feature.    Have I overlooked something or should
I open a request?

Jordan Birdsell
Data Engineer
State Farm - Research




Mime
View raw message