Repository navigation
Conversation
|
@blueorangutan package |
|
@vishesh92 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14453 +/- ##
============================================
+ Coverage 20.45% 20.48% +0.03%
- Complexity 21417 21457 +40
============================================
Files 6487 6487
Lines 589329 589669 +340
Branches 72246 72281 +35
============================================
+ Hits 120554 120808 +254
- Misses 455642 455712 +70
- Partials 13133 13149 +16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19644 |
90b18fc to
6abe098
Compare
a3121b3 to
743cc40
Compare
|
@blueorangutan package |
|
@vishesh92 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19656 |
This branch has not been deployed
2 participants
Description
This PR fixes several problems in the KMS volume encryption that came with 4.23.
Volumes migrated to KMS don't start anymore
migrateVolumesToKMSwrapped the legacy passphrase as it is stored in thepassphrasetable, which is its base64 text. When the key is read back,VolumeObject.getPassphrase()base64-encodes the unwrapped key again, so the volume gets a different passphrase from the one it was encrypted with. The VM fails on the next start or attach.Migration now wraps the decoded passphrase. For keys already migrated on 4.23, a background task runs after the upgrade. It unwraps every existing key once and rewraps the ones that are in the old format. If a key is used by a volume created after the migration (e.g. a copy made by a storage migration on 4.23), that volume may have been encrypted with the wrong passphrase, so the task leaves the key alone and logs it.
Migration also removes the old
passphraserow once no volume uses it. The upgrade removes rows that were already left behind.Wrapped keys removed while still in use
VolumeDaoImpl.remove()removed a volume's wrapped key unconditionally. After a volume migration the new volume shares the key with the source, so expunging the source left the migrated volume without a key. Expunging a volume that has snapshots did the same to the snapshots: they could be neither restored nor deleted.The DAO doesn't touch the key anymore.
KMSManager.deleteKMSWrappedKey()andVolumeObject.deletePassphrase()keep the key (KMS or legacy passphrase) while another volume or a snapshot of the volume still needs it. The storage cleanup task releases it afterwards throughVolumeService.releaseKeysOfRemovedVolumes(). On upgrade, keys removed this way are restored if their KMS key and KEK still exist. The ones that can't be recovered are logged.Key wrapping in the PKCS#11 provider
The PKCS#11 provider wrapped keys with
AES/CBC/PKCS5Padding, which detects neither a modified blob nor a wrong KEK.unwrapKey()also tried all KEK versions when the recorded one failed. So a wrong key could be returned without any error, and during a rotation it would be rewrapped under the new KEK and the real key lost.wrap_algorithmdetail. The options areAES/GCM/NoPadding(the default),AES/KWP/NoPadding(needs Java 18 or later) andAES/CBC/PKCS5Padding. It can't be changed once the profile exists.AES/CBC/PKCS5Padding, so nothing changes for them. To move existing keys over, create a profile with GCM or KWP and rotate the KMS keys onto it.kms_wrapped_key.wrap_algorithm.unwrapKey()uses the recorded KEK version first. It tries the other versions only for GCM/KWP keys, where a wrong KEK is detected.KMSProvidergot adeleteKek(kekId, hsmProfileId)variant for KEKs that don't have a version row (yet). Rotation now uses it when its DB update fails. Before, that KEK stayed in the HSM.algorithmshown for a KMS key is now the actual wrap algorithm, instead of alwaysAES/GCM/NoPadding.Other changes
deleteKMSKeyno longer deletes the KMS key if the HSM fails to delete one of its KEKs, so the KEK isn't left in the HSM without anything pointing to it. A KEK that is already gone is fine, e.g. one deleted after a rotation. The PKCS#11 provider now reports such a KEK as not found instead of a generic failure.getPassphrase()returns an empty passphrase instead of throwing, so its snapshots can still be deleted.kms.dek.size.bitsis now checked to be 128, 192 or 256.Schema changes:
kms_wrapped_keygetswrap_algorithmandformat_check_pending.For the release notes: volumes already migrated on 4.23.0.0 are repaired automatically after the upgrade, once their HSM profile is reachable. Existing PKCS#11 profiles keep using CBC until their keys are rotated onto a GCM/KWP profile.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?