Spec for the Cinder part of the Image Encryption
This introduces a new version of the Image Encryption Spec that focuses on standardizing metadata for LUKS-encrypted images. Change-Id: If939a604cd40c20dffe85ac74394bf176b14b1e8
This commit is contained in:
Josephine Seifert
Brian Rosmaita
parent
3fe68c9fad
commit
10afe7bcb9
315
specs/2024.2/LUKS-image-encryption.rst
Normal file
315
specs/2024.2/LUKS-image-encryption.rst
Normal file
@ -0,0 +1,315 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
===========================================
|
||||
Standardize Image Encryption and Decryption
|
||||
===========================================
|
||||
|
||||
OpenStack already has the ability to create encrypted volumes and ephemeral
|
||||
storage to ensure the confidentiality of block data. Even though it is also
|
||||
already possible to store encrypted images, there is only one service (Cinder)
|
||||
that utilizes this option, but it is only indirectly usable by Nova (a user
|
||||
must create a volume from the image first), and thus users don't have an
|
||||
intuitive way to create and upload encrypted images. In addition, all metadata
|
||||
needed to detect and use encrypted images is either not present or specifically
|
||||
scoped for Cinder right now. In conclusion, support for encrypted images does
|
||||
exist to some extent but only in a non-explicit and non-standardized way. To
|
||||
establish a consistent approach to image encryption for all OpenStack services
|
||||
as well as users, several adjustments need to be implemented in Glance, Cinder
|
||||
and OSC.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
An image, when uploaded to Glance or being created through Nova from an
|
||||
existing server (VM), may contain sensitive information. The already provided
|
||||
signature functionality only protects images against alteration. Images may be
|
||||
stored on several hosts over long periods of time. First and foremost this
|
||||
includes the image storage hosts of Glance itself. Furthermore it might also
|
||||
involve caches on systems like compute hosts. In conclusion they are exposed to
|
||||
a multitude of potential scenarios involving different hosts with different
|
||||
access patterns and attack surfaces. The OpenStack components involved in those
|
||||
scenarios do not protect the confidentiality of image data.
|
||||
|
||||
Using encrypted storage backends for volume and compute hosts in conjunction
|
||||
with direct data transfer from/to encrypted images can enable workflows that
|
||||
never expose an image's data on a host's filesystem. Storage of encryption keys
|
||||
on a dedicated key manager host ensures isolation and access control for the
|
||||
keys as well.
|
||||
|
||||
As stated in the introduction above, some disk image encryption implementations
|
||||
for ephemeral disks in Nova and volumes in Cinder already touch on this topic
|
||||
but not always in a standardized and interoperable way. For example, the way of
|
||||
handling image metadata and encryption keys can differ. Furthermore, users
|
||||
are not easily able to make use of these implementations when supplying their
|
||||
own images in a way that encryption can work the same across services.
|
||||
|
||||
That’s why we propose the introduction of a streamlined encrypted image format
|
||||
along with well-defined metadata specifications which will be supported across
|
||||
OpenStack services for the existing encryption implementations and increase
|
||||
interoperability as well as usability for users.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
| 1. A user wants to create a new volume based on an encrypted image. The
|
||||
corresponding volume host has to be enabled to detect, that the image is
|
||||
encrypted. Additionally encrypted images should always result in encrypted
|
||||
volumes to avoid decryption.
|
||||
|
|
||||
| 1.1 If an encrypted image is the base for a new volume the used volume type
|
||||
should always have an encryption type. If the given volume type or default
|
||||
volume type does not have an encryption type the operation should result
|
||||
in an ERROR.
|
||||
|
|
||||
| 1.2 There are two possible types of encrypted images: qcow2 and raw images.
|
||||
Cinder can already handle encrypted raw images. Encrypted qcow2 images
|
||||
may need to be flattend to raw before transfering them into volumes.
|
||||
|
|
||||
| 1.3 Encrypted images, that were created from encrypted volumes, may be
|
||||
compressed depending on Cinder's allow_compression_on_image_upload
|
||||
option. This also needs to be handled when creating an encrypted volume
|
||||
from such an image.
|
||||
|
||||
| 2. Whenever an encrypted image is converted to an encrypted volume the secret
|
||||
should be copied to give Cinder full control over the life-cycle of the
|
||||
secret.
|
||||
|
|
||||
| 2.1. The secret can be a key or a passphrase. The secret type
|
||||
classification in the Key-Manager will determine the key handling
|
||||
("symmetric" vs "passphrase"). Currently, Cinder is only able to handle
|
||||
"symmetric". Support for "passphrase" (like used in Nova) has to be added.
|
||||
|
||||
| 3. A user wants to create an image from a volume with an encrypted volume
|
||||
type. The target image will reuse the LUKS encryption and key. This use case
|
||||
is already implemented as part of the default behavior of Cinder.
|
||||
|
|
||||
| 3.1. Creating an encrypted image from an unencrypted volume will not be
|
||||
part of this spec, but may be implemented later on.
|
||||
|
|
||||
| 3.2. Creating an unencrypted image from an encrypted volume is not possible
|
||||
right now. The volume encryption is transparently also used for the image.
|
||||
This behavior will stay in place to optimize resource usage and avoid costly
|
||||
conversion of the whole volume data on volume hosts.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
In Glance we propose the following additional metadata properties that should be
|
||||
carried by encrypted images:
|
||||
|
||||
* 'os_encrypt_format' - the main mechanism used, e.g. 'LUKS'
|
||||
* 'os_encrypt_cipher' - the cipher algorithm, e.g. 'AES256'
|
||||
* 'os_encrypt_key_id' - reference to secret in the key manager
|
||||
* 'os_encrypt_key_deletion_policy' - on image deletion indicates whether the key
|
||||
should be deleted too
|
||||
* 'os_decrypt_container_format' - format change, e.g. from 'compressed' to
|
||||
'bare'
|
||||
* 'os_decrypt_size' - size after payload decryption
|
||||
|
||||
We propose to align the encryption with Nova and Cinder and use LUKS, which
|
||||
will be allowed in combination with qcow and raw images. We use this two
|
||||
versions for the following reasons:
|
||||
|
||||
1. Nova can directly use qcow-LUKS encrypted when creating a server. This is
|
||||
the standard procedure of Nova.
|
||||
|
||||
2. Cinder allows the creation of Images from encrypted volumes. These will
|
||||
always result in LUKS-encrypted raw images. Those images can be converted
|
||||
directly to volumes again.
|
||||
|
||||
In the latter case it is already possible to upload such an encrpyted image to
|
||||
another OpenStack infrastructure, upload the key as well and set the
|
||||
corresponding metadata. After doing so the image can be used in the second
|
||||
infrastructure to create an encrypted volume.
|
||||
|
||||
We want to align the existing implementations between Nova and Cinder by
|
||||
standardizing the used metadata parameters and adding interoperability where
|
||||
applicable. This would in the case of Cinder mainly be a rename:
|
||||
- 'cinder_encryption_key_deletion_policy' to 'os_encrypt_key_deletion_policy'
|
||||
- 'cinder_encryption_key_id' to 'os_encrypt_key_id'
|
||||
|
||||
In the Volume creation there will be a check added, to look for encrypted
|
||||
images proposed as a volume source. If an image is encrypted another check is
|
||||
added to determine, whether the volume type to create the volume has an
|
||||
encryption type. If that is not the case the volume create will be aborted in
|
||||
the API still. Otherwise there will be an unusable volume created.
|
||||
|
||||
The flattening of a qcow2 image should be handled when uploading the image to
|
||||
the volume. The volume size should be resulting from the 'os_decrypt_size'
|
||||
parameter. If compression is enabled through Cinder's
|
||||
allow_compression_on_image_upload option Cinders implementation to handle this
|
||||
should be re-used.
|
||||
|
||||
The key management for creating an encrypted volume from an encrypted image
|
||||
must include the copying of the secret in Barbican. On this way Cinder always
|
||||
has the full control over the life-cycle of the secret, because this way is
|
||||
similar to the original creation of an encrypted volume.
|
||||
|
||||
In all places that use decryption within Cinder, there need to be an
|
||||
additional check for the type of the secret. And a different handling, if the
|
||||
secret is a "passphrase", because the way Cinder treats keys to create a
|
||||
passphrase for the LUKS header of a volume is quite unique and differs from
|
||||
Nova's handling of images, that have passphrases only.
|
||||
|
||||
The creation of an image from an volume just need to be adjusted to use the new
|
||||
parameters.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We also evaluated an image encryption implementation based on GPG. The downside
|
||||
with such an implementation is, that everytime such an image is used to create
|
||||
a server or a volume the image has to be decrypted and maybe re-encrypted for
|
||||
another encryption format as both Nova and Cinder use LUKS as an encryption
|
||||
mechanism. This would not only have impact on the performance of the operation
|
||||
but it also would need free space for the encrypted image file, the decrypted
|
||||
parts and the encrypted volume or server that is created.
|
||||
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
When creating a volume from an encrypted image there might occure a new ERROR
|
||||
that is triggered, when an image is encrypted but no encrypted volume type is
|
||||
given.
|
||||
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
There are impacts on the security of OpenStack:
|
||||
|
||||
* confidentiality of data in images will be addressed in this spec
|
||||
|
||||
* image encryption is introduced formally, thus cryptographic algorithms will
|
||||
be used in all involved components (Nova, Cinder, OSC)
|
||||
|
||||
|
||||
Active/Active HA impact
|
||||
-----------------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
* Users should be able to use encrypted images to create volumes in a
|
||||
consistant way
|
||||
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The proposed checks for the Cinder API may have minimal impact on performance.
|
||||
|
||||
When creating a volume or server from an encrypted image the only operation
|
||||
that may be triggerd is the conversion between qcow-LUKS and raw LUKS blocks.
|
||||
|
||||
Thus, any performance impact is only applicable to the newly introduced
|
||||
encrypted image type where the processing of the image will have increased
|
||||
computational costs and longer processing times than regular images. Impact
|
||||
will vary depending on the individual host performance and supported CPU
|
||||
extensions for cipher algorithms.
|
||||
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
* For interoperability between the OpenStack services only the presence of a
|
||||
key manager should decide, whether encryption can be used or not.
|
||||
|
||||
* A key manager - like Barbican - is required, if encrypted images are to be
|
||||
used.
|
||||
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee: Markus Hentsch (IRC: mhen)
|
||||
|
||||
Other contributors: Josephine Seifert (IRC: Luzi)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add checks in the create volume API
|
||||
|
||||
* Add copying the secret and registering as a consumer in Barbican
|
||||
|
||||
* Add flattening of qcow2 to raw encrypted images
|
||||
|
||||
* In the image create from volume: change the
|
||||
'cinder_encryption_key_deletion_policy' to 'os_encrypt_key_deletion_policy'
|
||||
and 'cinder_encryption_key_id' to 'os_encrypt_key_id'
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* Presence of the image encryption parameters in Glance has to be implemented
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Tempest tests would require access to encrypted images for testing. This means
|
||||
that Tempest either needs to be provided with an image file that is already
|
||||
encrypted and its corresponding key or needs to be able to encrypt images
|
||||
itself. This point is still open for discussion.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
It should be documented for deployers, how to enable this feature in the
|
||||
OpenStack configuration.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] Barbican Secret Consumer Spec:
|
||||
https://review.opendev.org/#/c/662013/
|
||||
|
||||
[2] Glance Image Encryption Spec:
|
||||
https://review.opendev.org/c/openstack/glance-specs/+/915726
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Dalmatian
|
||||
- Introduced
|
||||
Loading…
x
Reference in New Issue
Block a user