[jira] [Updated] (CASSANDRA-14107) Dynamic key rotation support for transparent data encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-14107: - Component/s: Core > Dynamic key rotation support for transparent data encryption > > > Key: CASSANDRA-14107 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14107 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Stefan Podkowinski >Priority: Minor > Labels: encryption > Fix For: 4.x > > Attachments: patches-14107.tar > > > 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 ":latest" for referring to the latest version. In this case > Cassandra always picks the key with the highest version in > ":". > 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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14107) Dynamic key rotation support for transparent data encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14107: --- Attachment: patches-14107.tar > Dynamic key rotation support for transparent data encryption > > > 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 > > Attachments: patches-14107.tar > > > 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 ":latest" for referring to the latest version. In this case > Cassandra always picks the key with the highest version in > ":". > 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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14107) Dynamic key rotation support for transparent data encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14107: --- Status: Patch Available (was: In Progress) My approach with the latest patch was to leave as much of the existing TDE code as is and instead only modify the way the key alias is accessed in the global config. We have to make sure to use the most recent key each time new data is to be encrypted. Decrypting existing data must take place based on the serialized encryption settings. The patch will therefor * Retrieve the most recent key alias in case the ':latest' suffix is specified * In that case also start a periodical task to retrieve and update it * Store the latest alias in the active EncryptionContext instance * Make sure to have existing code always pull the currently active EncryptionContext for new encryption operations, so we always use the latest key * Make EncryptionContext immutable, so we never change the alias for already in-flight or pending encryption operations I've also added some code to use the active EncryptionContext to enable encryption for hints as well, which seems to be missing on trunk. > Dynamic key rotation support for transparent data encryption > > > 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 ":latest" for referring to the latest version. In this case > Cassandra always picks the key with the highest version in > ":". > 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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14107) Dynamic key rotation support for transparent data encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14107: --- Summary: Dynamic key rotation support for transparent data encryption (was: Introduce simple key alias versioning scheme for TDE) > Dynamic key rotation support for transparent data encryption > > > 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 ":latest" for referring to the latest version. In this case > Cassandra always picks the key with the highest version in > ":". > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
