Key rotation process for a compromised KMIP-managed encryption key in ScyllaDB

We have set up a remote KMIP server and encrypted several tables, creating a new key for each table on the KMIP server. We would like to understand the process in case of a potential compromise. According to the documentation (Encryption at Rest | ScyllaDB Docs), we can use the ALTER command on a table to generate a new key on the KMIP server, while keeping the old key intact on the KMIP server.

However, based on the key alias/UUID (available to us on the KMIP server), how can we determine which table is associated with a specific key UUID? Is there an internal table in Scylla that links tables to their respective key UUIDs? Or, if there is a better approach to key rotation, we would appreciate any guidance on that.

To rotate a key using KMIP:
First Modify your KMIP config so that queries for a key based on properties (such as length, cryptographic usage etc) does no longer return the key to be retired.
Then either:

  • Wait for natural sstable rewrites (compaction) to rewrite all data using new key(s) (can take days)
    Or:
  • Wait 20m for caches to expire
  • Run nodetool upgradesstables -all on all relevant nodes to force rewriting sstables.
1 Like