Include encryption_key_id in volume and backup details¶
This spec adds the encryption_key_id field to the volume and backup details for volumes that are encrypted.
The current API supplies volume details that include a simple boolean that indicates whether a volume is encrypted. However, when a volume is encrypted, the details do not include the associated Key Manager (e.g. Barbican) encryption_key_id. This makes it difficult to correlate encryption keys stored in Barbican with their associated volumes. Any operator workflow that might benefit from knowing a volume’s encryption_key_id has to read the value from the Cinder database.
A similar situation applies to backups of an encrypted volume. These backups include a clone of the volume’s encryption key, and the backup’s encryption_key_id is not available via the API.
1. An operator wishes to back up and export Cinder volumes and Barbican secrets for disaster recovery (DR), and later restore the volumes. Knowing each encrypted volume’s encryption_key_id will facilitate restoring the correct encryption secret.
2.1 A user or admin wants to identify the Barbican encryption keys used by Cinder volumes and/or backups. This proposal will allow them to iterate over the list of items, and note the encryption_key_id when present in its details.
2.2 A user or admin wishes to know whether a Barbican secret is used by Cinder. This is similar to 2.1, but more from Barbican’s perspective. Given a list of Barbican secrets, the user or admin may want to now which service is using the secret.
This proposal would add a microversion to include the encryption_key_id field in the volume and backup details. The field would be included in the datails only when relevant:
The encryption_key_id is set (not null)
It isn’t the all-zeros value used by the obsolete fixed-key ConfKeyManager
Operators continue to resort to accessing the Cinder database whenever they need to know a volume’s or backup’s encryption_key_id.
The proposed change could be enhanced to require admin privileges.
Data model impact¶
REST API impact¶
A new microversion will be created, and the encryption_key_id will be added to the volume and backup details.
On one hand, the proposed change will allow users to see the Key Manager (Barbican) ID where the encryption secret is stored. But it’s important to bear these factors in mind:
The encryption_key_id is just a UUID, and access to the actual secret is protected by Barbican’s security policies.
A volume’s encryption_key_id is already present in the connection_info returned by the volume attachment API.
Active/Active HA impact¶
Other end user impact¶
The feature will not affect users beyond the fact that displaying the details of an encrypted volume or backup will include the encryption_key_id field.
The feature does not require changes in cinderclient, openstackclient or openstack-sdk.
Other deployer impact¶
- Primary assignee:
Alan Bishop <email@example.com>
Add a new microversion.
Update the API documentation and code.
Add unit tests.
Unit tests provide sufficient coverage, and there are no plans for tempest changes.
Update the API documentation.