cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
Date Fri, 25 Nov 2016 15:20:59 GMT


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:
>             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
> 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

View raw message