Switching to public comments (not sure any previous ones need to be private). The cinder squad discussed a few issues that would impact how the feature might be handled in stable releases. My test code was easily hacked in, but there's a lot more "paperwork" to do for an upstream patch that probably requires an API microversion. It's difficult to know exactly what it might take to support the feature in OSP-16.2 until after it's actually implemented upstream.
I've been thinking about this further and need to raise some points. The use case presented describes exporting the backup of an encrypted volume, and its associated encryption key. However, when an encrypted volume is backed up, the backup contains a clone of the encryption key which is stored in its own barbican secret. In other words, the volume and backup each have their own encryption_key_id, but both barbican keys contain the same encryption secret. Because the use case is related to backup and restore operations, I'm now thinking the API should support displaying the backup's encryption_key_id instead of the volume's encryption_key_id. It would also be good to get as much input as possible on whether the backup's (or volume's) encryption_key_id needs special protection. A code change of this nature that affects the API will require approval of an upstream cinder spec that covers security considerations. Should a user who has access to the volume be prevented from knowing its encryption_key_id? Remember this is just a barbican UUID, and nothing related to the actual encryption secret. An alternative would be to require admin privileges. Can we make some of the earlier comments public, especially the description? That way I could include the BZ as a reference in the upstream spec. Lastly, just for awareness, the Wallaby spec freeze is December 18.
I submitted a spec for the cinder API enhancement, see https://review.opendev.org/c/openstack/cinder-specs/+/767629.
The spec was approved, and I'll be working on it during the Wallaby cycle. We will need to reassess when it can be supported in OSP after the the upstream work is complete. This includes how it might be supported in OSP-16.x.
The feature just merge upstream, and should soon be imported into the OSP-17 source code. The cinder squad discussed the feasibility of backporting the feature into OSP-16.2, but there are logistic problems due to the feature relying on an API microversion.
Work is being done by Benny so as to add automation coverage https://review.opendev.org/c/openstack/tempest/+/826364
Verified on: openstack-cinder-18.2.1-0.20220705150903.1776695.el9ost.noarch The test plan's 4 test cases were successfully executed and passed.
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 (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), 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/RHEA-2022:6543