mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-11-09 08:06:33 +00:00
832d6f0e19
This change updates KMS v2 to not create a new DEK for every encryption. Instead, we re-use the DEK while the key ID is stable. Specifically: We no longer use a random 12 byte nonce per encryption. Instead, we use both a random 4 byte nonce and an 8 byte nonce set via an atomic counter. Since each DEK is randomly generated and never re-used, the combination of DEK and counter are always unique. Thus there can never be a nonce collision. AES GCM strongly encourages the use of a 12 byte nonce, hence the additional 4 byte random nonce. We could leave those 4 bytes set to all zeros, but there is no harm in setting them to random data (it may help in some edge cases such as live VM migration). If the plugin is not healthy, the last DEK will be used for encryption for up to three minutes (there is no difference on the behavior of reads which have always used the DEK cache). This will reduce the impact of a short plugin outage while making it easy to perform storage migration after a key ID change (i.e. simply wait ten minutes after the key ID change before starting the migration). The DEK rotation cycle is performed in sync with the KMS v2 status poll thus we always have the correct information to determine if a read is stale in regards to storage migration. Signed-off-by: Monis Khan <mok@microsoft.com>