-2

It is understood that yugabyte-db secures both data on transit and data at rest from https://docs.yugabyte.com/v1.1/secure/tls-encryption/ and https://docs.yugabyte.com/latest/secure/encryption-at-rest/.

It is observed that:

a) shown max key length option is 48bits. Whether it can be configured to use 128bits key or 256 bits key or higher bits? How to minimize its effect on performance?

b) Whether all tablets are decrypted with old key and encrypted with new key whenever key is rotated or how it is done? How performance is affected while rotating the key? How to minimize its effect on performance?

c) How to configure yugabyte-db to use keys from HSMs against using keys from disks for both data on wire and data at rest?

AVA
  • 2,474
  • 2
  • 26
  • 41

1 Answers1

2

a) This is incorrect, it can be configured to use 128/256 bit keys. Docs should be updated soon to reflect this.

b) In general when the rotate_universe_key_in_memory yb-admin command is run, only newly-written data files utilize the universe key that was rotated to (whether on enabling encryption at rest for the first time, or any subsequent key rotations). All previously existing data files still have a reference to the universe key that had been the current key when the files had been written, and the files continue to use their respective universe keys until they are flushed or compacted at which point the newly-written files will use the current universe key. So no, there is no tablet-wide decryption happening every time a key rotation occurs, and the time it takes for all data files to be using the current universe key is dependent on the write workload on the given universe.

c) Right now the Yugabyte yb-admin commands only support reading in a universe key from the contents of a file on disk for encryption at rest. Important to note that the key only needs to be persisted on disk up to the point of it being loaded into memory with add_universe_key_to_all_masters. After this, the key file can be moved from the master node and stored remotely elsewhere. Only other time this key file will be required to re-upload the key into memory is if all masters simultaneously go down. The Yugabyte Platform (https://www.yugabyte.com/platform/) offers integration support for AWS KMS that uses a CMK to generate universe keys (and you can use an AWS CloudHSM as a HSM custom key store for your AWS KMS CMK) as well as integration support for Equinix SmartKey; so this might fit your use case?

Daniel Isen
  • 36
  • 2