Description of problem: RBD Encryption, a feature available in RHCS 5.0, is unable to handle the case where an RBD is created as a clone of a snapshot, where the same encryption key (or no encryption) isn't used for the underlying RBD. There is code available now in the form of a PR to address this. This PR: https://github.com/ceph/ceph/pull/40363 is required for functionality in 5.1 to use encryption with cloned RBD's. Version-Release number of selected component (if applicable): RHCS 5.0 How reproducible: Always Steps to Reproduce: 1. Create RBD1, unencrypted, snapshot the RBD & write protect 2. Create an RBD2 that is a clone RBD1's snapshot, using RBD encryption 3. Read blocks in RBD2 that are served from the underlying snapshot Actual results: Data from RBD1 is run through crypto engine, resulting in invalid data Expected results: Blocks that aren't present in RBD2 do not use the encryption for RBD2, and are returned intact Additional info:
Hi IIya, As we have entered Code freeze/blockers only stage for 5.1z1, can you please let us know when QE can expect this BZ to be ON_QA ? Regards, Preethi
Ok lets move this one out of 5.1 z1 then.
Moving it back to 5.1 z1 - this will be an exception
Any update on this BZ. When can we expect to be ON_QA. We are close to Test phase completion. We need it by 6th for QE to verify this part of 5.1Z1 release.
Any update on this BZ. When can we expect to be ON_QA.
Lets keep it in 5.2 for tracking purposes.
Tis did not make the code complete cutoff date, so moving to 5.3 z1.
The feature is working as expected. We have performed the below steps to verify the BZ 1)Create RBD image1 2)Apply encryption format LUKS1/LUKS2 to the RBD image1 [root@magna021 ubuntu]# rbd encryption format mypool/myimage6 luks2 passphrase.bin 3)load encryption 4) create file system and mount the device 5)Run IOs 6) Create a clone i.e RBD image2, from the snapshot of RBD image1 7) Encrypt the image with LUKS2 and different passphrase 9) load the encryption and mount the device 10) Verify the data 11) Perform RBD flatten to the images loading encryption keys for parent and child images Expected result- Data is intact, we are able to read the data which was present in RBD1 before snpashot was performed We have verifed theabove steps for the following scenarios- Have a non-formatted parent, LUKS1-formatted clone non-formatted parent, LUKS2-formatted clone LUKS1-formatted parent, non-formatted clone LUKS1-formatted parent, LUKS1-formatted clone (different passphrase) LUKS1-formatted parent, LUKS2-formatted clone LUKS2-formatted parent, non-formatted clone (format and passphrase inherited from the parent) LUKS2-formatted parent, LUKS1-formatted clone LUKS2-formatted parent, LUKS2-formatted clone (different passphrase) Resize,shrink operations, flatten operations to the encrypted images negative tests/usaeblility scnearios around this area
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Red Hat Ceph Storage 5.3 security update and Bug Fix), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:0076