[
https://issues.apache.org/jira/browse/CASSANDRA-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-14107:
-------------------------------------------
Description:
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.
was:
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>:last" for referring to the latest version. Omitting the ":<version>"
part altogether would have the same effect. In this case Cassandra always picks
the latest key when the key cache has been expired.
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.
> Introduce simple key alias versioning scheme for TDE
> ----------------------------------------------------
>
> Key: CASSANDRA-14107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14107
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
