9.7 KiB
libvirt driver support for flavor and image defined ephemeral encryption
https://blueprints.launchpad.net/nova/+spec/ephemeral-encryption-libvirt
This spec outlines the specific libvirt virt driver implementation to support the Flavor and Image defined ephemeral storage encryption1 spec.
Problem description
The libvirt virt driver currently provides very limited support for
ephemeral disk encryption through the LVM
imagebackend and
the use of the PLAIN
encryption format provided by
dm-crypt
.
As outlined in the Flavor and Image defined ephemeral storage encryption2 spec this current implementation is controlled through compute host configurables and is transparent to end users, unlike block storage volume encryption via Cinder.
With the introduction of the Flavor and Image defined ephemeral storage encryption3 spec we can now implement support for encrypting ephemeral disks via images and flavors, allowing support for newer encryption formats such as LUKSv1. This also has the benefit of being natively supported by QEMU, as already seen in the libvirt driver when attaching LUKSv1 encrypted volumes provided by Cinder.
Use Cases
- As a user of a cloud with libvirt based computes I want to request that all of my ephemeral storage be encrypted at rest through the selection of a specific flavor or image.
- As a user of a cloud with libvirt based computes I want to be able to pick how my ephemeral storage be encrypted at rest through the selection of a specific flavor or image.
- As a user I want each encrypted ephemeral disk attached to my instance to have a separate unique secret associated with it.
- As an operator I want to allow users to request that the ephemeral
storage of their instances is encrypted using the flexible
LUKSv1
encryption format.
Proposed change
Deprecate the legacy implementation within the libvirt driver
The legacy implementation using dm-crypt
within the
libvirt virt driver needs to be deprecated ahead of removal in a future
release, this includes the following options:
[ephemeral_storage_encryption]/enabled
[ephemeral_storage_encryption]/cipher
[ephemeral_storage_encryption]/key_size
Limited support for dm-crypt
will be introduced using
the new framework before this original implementation is removed.
Populate disk_info with encryption properties
The libvirt driver has an additional disk_info
dict
built from the contents of the previously mentioned
block_device_info
and image metadata associated with an
instance. With the introduction of the
DriverImageBlockDevice
within the Flavor and Image defined
ephemeral storage encryption4 spec we can now avoid
the need to look again at image metadata while also adding some
ephemeral encryption related metadata to the dict.
This dict currently contains the following:
disk_bus
-
The default bus used by disks
cdrom_bus
-
The default bus used by cd-rom drives
mapping
-
A nested dict keyed by disk name including information about each disk.
Each item within the mapping
dict containing following
keys:
bus
-
The bus for this disk
dev
-
The device name for this disk as known to libvirt
type
-
A type from the BlockDeviceType enum ('disk', 'cdrom','floppy', 'fs', or 'lun')
It can also contain the following optional keys:
format
-
Used to format swap/ephemeral disks before passing to instance (e.g. 'swap', 'ext4')
boot_index
-
The 1-based boot index of the disk.
In addition to the above this spec will also optionally add the following keys for encrypted disks:
encryption_format
-
The encryption format used by the disk
encryption_options
-
A dict of encryption options
encryption_secret_uuid
-
The UUID of the encryption secret associated with the disk
backing_encryption_secret_uuid
-
The UUID of the encryption secret for the backing file associated with the disk in the case of qcow2.
Handle ephemeral disk encryption within imagebackend
With the above in place we can now add encryption support within each
image backend. As highlighted at the start of this spec this initial
support will only be for the LUKSv1
encryption format.
Generic key management code will be introduced into the base
nova.virt.libvirt.imagebackend.Image
class and used to
create and store the encryption secret within the configured key
manager. The initial LUKSv1
support will store a passphrase
for each disk within the key manager. This is unlike the current
ephemeral storage encryption or encrypted volume implementations that
currently store a symmetric key in the key manager. This remains a long
running piece of technical debt in the encrypted volume implementation
as LUKSv1
does not directly encrypt data with the provided
key.
The base nova.virt.libvirt.imagebackend.Image
class will
also be extended to accept and store the optional encryption details
provided by disk_info
above including the format, options
and secret UUID(s).
Each backend will then be modified to encrypt disks during
nova.virt.libvirt.imagebackend.Image.create_image
using the
provided format, options and secret.
Enable the
COMPUTE_EPHEMERAL_ENCRYPTION_LUKS
trait
Finally, with the above support in place the
COMPUTE_EPHEMERAL_ENCRYPTION
and
COMPUTE_EPHEMERAL_ENCRYPTION_LUKS
traits can be enabled
when using a backend that supports LUKSv1
. This will in
turn enable scheduling to the compute of any user requests asking for
ephemeral storage encryption using the format.
Alternatives
Continue to use the transparent host configurables and expand support
to other encryption formats such as LUKS
.
Data model impact
As discussed above the ephemeral encryption keys will be added to the disk_info for individual disks within the libvirt driver.
REST API impact
N/A
Security impact
This should hopefully be positive given the unique secret per disk and user visible choice regarding how their ephemeral storage is encrypted at rest.
Notifications impact
N/A
Other end user impact
Users will now need to opt-in to ephemeral storage encryption being used by their instances through their choice of image or flavors.
Performance Impact
QEMU will natively decrypt these LUKSv1
ephemeral disks
for us using the libgcrypt
library. While there have been
performance issues with this in the past workarounds5 can
be implemented that use dm-crypt
instead.
Other deployer impact
N/A
Developer impact
This spec will aim to implement LUKSv1
support for all
imagebackends but in the future any additional encryption formats
supported by these backends will need to ensure matching traits are also
enabled.
Upgrade impact
The legacy implementation is deprecated but will continue to work for the time being. As the new implementation is separate there is no further upgrade impact.
Implementation
Assignee(s)
- Primary assignee:
-
melwitt
- Other contributors:
-
lyarwood
Feature Liaison
- Feature liaison:
-
melwitt
Work Items
- Populate the individual disk dicts within
disk_info
with any ephemeral encryption properties. - Provide these properties to the imagebackends when creating each disk.
- Introduce support for
LUKSv1
based encryption within the imagebackends. - Enable the
COMPUTE_EPHEMERAL_ENCRYPTION_LUKS
trait when the selected imagebackend supportsLUKSv1
.
Dependencies
- Flavor and Image defined ephemeral storage encryption6
Testing
Unlike the parent spec once imagebackends support LUKSv1
and enable the required trait we can introduce Tempest based testing of
this implementation in addition to extensive functional and unit based
tests.
Documentation Impact
- New user documentation around the specific
LUKSv1
support for ephemeral encryption within the libvirt driver. - Reference documentation around the changes to the virt block device layer.
- Document that for the
raw
imagebackend, both[libvirt]images_type = raw
and[DEFAULT]use_cow_images = False
must be configured in order for resize to work. This is also true without encryption but it may still be helpful to users. - Document that a user must have policy permission to create secrets in Barbican in order for encryption to work for that user. Secrets are created in Barbican using the user's auth token. Admins have permission to create secrets in Barbican by default.
References
Release Name | Description |
---|---|
Wallaby | Introduced |
Yoga | Reproposed |
Zed | Reproposed |
2023.1 Antelope | Reproposed |
2023.2 Bobcat | Reproposed |
2024.1 Caracal | Reproposed |
2024.2 Dalmation | Reproposed |
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html↩︎
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html↩︎
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html↩︎
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html↩︎
https://docs.openstack.org/nova/victoria/configuration/config.html#workarounds.disable_native_luksv1↩︎
https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html↩︎