cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14107) Introduce simple key alias versioning scheme for TDE
Date Wed, 10 Jan 2018 13:01:00 GMT


Stefan Podkowinski commented on CASSANDRA-14107:

Yes. The basic idea is that you just need to add a new key with an incremented version number
(could also be a timestamp I guess) and Cassandra will pick it up automatically and uses it
from that point. Any data written to disk will still refer to the original key alias (e.g.
mykey:1) that has been used for encryption. 

I've also added a periodical job that will every 10 mins reload the local JKCKeyStore and
check for new keys, so you wouldn't have to restart or touch the config after adding a new
key. The Vault implementation supports this as well of course.

> Introduce simple key alias versioning scheme for TDE
> ----------------------------------------------------
>                 Key: CASSANDRA-14107
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>            Priority: Minor
>              Labels: encryption
>             Fix For: 4.x
> Handling of encryption keys as introduced in CASSANDRA-9945 takes place by referencing
a key alias in either cassandra.yaml, or the header of the (commitlog/hints) file that has
been encrypted. Using the alias as literal value will work, but requires some attention when
rotating keys.
> Currently each time a key is rotated (i.e. adding a new key to the keystore while preserving
the previous version), the alias in cassandra.yaml has to be update as well and the node needs
to be restarted. It would be more convenient to use a symbolic reference instead. My suggestion
here would be to use "<alias>:latest" for referring to the latest version. In this case
Cassandra always picks the key with the highest version in "<alias>:<seq_number>".
> The non-trivial part of this suggestion is how the "latest" key is referenced in the
file header. If we use "latest", e.g. for the commit log header, and the key gets rotated,
we'd now try do decrypt the file with the new key, instead of the key it has been created
with. Therefor we'd have to introduce an extra step that will resolve the canonical version
for "latest" and refer to that one during any encrypt operation. 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message