Merge "Re-propose spec for ephemeral encryption for libvirt"
This commit is contained in:
Zuul
Gerrit Code Review
commit
f88a2d26f9
300
specs/2024.1/approved/ephemeral-encryption-libvirt.rst
Normal file
300
specs/2024.1/approved/ephemeral-encryption-libvirt.rst
Normal file
@ -0,0 +1,300 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
========================================================================
|
||||
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 encryption [1]_ 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 encryption [1]_
|
||||
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
|
||||
encryption [1]_ 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 encryption [1]_ 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
|
||||
|
||||
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.
|
||||
|
||||
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 workarounds [2]_ 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 supports ``LUKSv1``.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* Flavor and Image defined ephemeral storage encryption [1]_
|
||||
|
||||
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
|
||||
==========
|
||||
|
||||
.. [1] https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/ephemeral-encryption.html
|
||||
.. [2] https://docs.openstack.org/nova/victoria/configuration/config.html#workarounds.disable_native_luksv1
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Wallaby
|
||||
- Introduced
|
||||
* - Yoga
|
||||
- Reproposed
|
||||
* - Zed
|
||||
- Reproposed
|
||||
* - 2023.1 Antelope
|
||||
- Reproposed
|
||||
* - 2023.2 Bobcat
|
||||
- Reproposed
|
||||
* - 2024.1 Caracal
|
||||
- Reproposed
|
||||
Loading…
Reference in New Issue
Block a user