Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1904086

Summary:	[RFE] Expose encrypted volume key ID relationship via API (CLI commands) to user with a proper role (backup...)
Product:	Red Hat OpenStack	Reporter:	Siggy Sigwald <ssigwald>
Component:	openstack-cinder	Assignee:	Alan Bishop <abishop>
Status:	CLOSED ERRATA	QA Contact:	Tzach Shefi <tshefi>
Severity:	medium	Docs Contact:	RHOS Documentation Team <rhos-docs>
Priority:	high
Version:	16.1 (Train)	CC:	abishop, erpeters, gcharot, hrybacki, jamsmith, jhardee, lmarsh, mariel, mchappel, nlevinki, satmakur, spower
Target Milestone:	Alpha	Keywords:	FutureFeature, Triaged
Target Release:	17.0
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	openstack-cinder-18.1.0-0.20210903074603.73e2099.el8ost	Doc Type:	Enhancement
Doc Text:	With this enhancement, you can view a volume Encryption Key ID using the cinder client command 'cinder --os-volume-api-version 3.64 volume show <volume_name>'. You must specify microversion 3.64 to view the value.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-21 12:12:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 4 Alan Bishop 2020-12-10 17:06:49 UTC

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.

Comment 5 Alan Bishop 2020-12-14 21:04:46 UTC

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.

Comment 6 Alan Bishop 2020-12-17 21:30:08 UTC

I submitted a spec for the cinder API enhancement, see https://review.opendev.org/c/openstack/cinder-specs/+/767629.

Comment 7 Alan Bishop 2021-01-07 17:10:04 UTC

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.

Comment 9 Alan Bishop 2021-03-04 17:36:33 UTC

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.

Comment 14 Tzach Shefi 2022-01-26 08:48:18 UTC

Work is being done by Benny so as to add automation coverage
https://review.opendev.org/c/openstack/tempest/+/826364

Comment 22 Tzach Shefi 2022-07-17 13:02:56 UTC

Verified on:
openstack-cinder-18.2.1-0.20220705150903.1776695.el9ost.noarch


The test plan's 4 test cases were successfully executed and passed.

Comment 28 errata-xmlrpc 2022-09-21 12:12:17 UTC

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