[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696103#comment-15696103
]
Stefan Podkowinski commented on CASSANDRA-9633:
-----------------------------------------------
I haven't looked specifically into how an external key management system such
as vault could be integrated by implementing {{KeyProvider}}. But your're
right, it could be an option.
What I'm wondering though is if it wouldn't be worth it to implement a two tier
encryption architecture right from the start. To me support for key rotation
and table based encryption would be a key feature that makes Cassandra at-rest
encryption really worthwhile compared to filesystem/block device based
encryption. Therefor my suggestion would be to encrypt sstables using a
intermediate, sstable specific key (derived from a master key) that would be
stored along with the sstable (in an extra component). This would only require
to re-encrypt the associated keys upon key rotation, instead of rewriting all
sstables.
> Add ability to encrypt sstables
> -------------------------------
>
> Key: CASSANDRA-9633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9633
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jason Brown
> Assignee: Jason Brown
> Labels: encryption, security, sstable
> Fix For: 3.x
>
>
> Add option to allow encrypting of sstables.
> I have a version of this functionality built on cassandra 2.0 that
> piggy-backs on the existing sstable compression functionality and ICompressor
> interface (similar in nature to what DataStax Enterprise does). However, if
> we're adding the feature to the main OSS product, I'm not sure if we want to
> use the pluggable compression framework or if it's worth investigating a
> different path. I think there's a lot of upside in reusing the sstable
> compression scheme, but perhaps add a new component in cqlsh for table
> encryption and a corresponding field in CFMD.
> Encryption configuration in the yaml can use the same mechanism as
> CASSANDRA-6018 (which is currently pending internal review).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
