Spec for the Glance 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: I05ef9a0cf3ed663ac2ee3097259a1325d206121e
This commit is contained in:
Josephine Seifert
parent
3bdda0e98f
commit
fc0e4cd737
|
|
@ -0,0 +1,329 @@
|
|||
..
|
||||
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 not usable by Nova and 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 upload an image, which includes sensitive information. To
|
||||
ensure the integrity of the image, a signature can be generated and used
|
||||
for verification. Additionally, the user wants to protect the
|
||||
confidentiality of the image data through encryption. The user generates or
|
||||
uploads a key in the key manager (e.g. Barbican) and uses it to encrypt the
|
||||
image locally using the OpenStack client (osc) when uploading it.
|
||||
Consequently, the image stored on the Glance host is encrypted.
|
||||
|
||||
2. A user wants to create a new server or volume based on a) an encrypted image
|
||||
created externally or b) an image created as a backup from already encrypted
|
||||
storage objects in components like Nova and Cinder. The corresponding
|
||||
compute or volume host has to be able to directly use the encrypted image or
|
||||
(if incompatible) transfer its encryption from e.g. qcow2-LUKS to raw
|
||||
LUKS-encrypted blocks to be used for volumes. For this the OpenStack
|
||||
services need access to the key in the key manager and a few metadata
|
||||
information about the encrypted image.
|
||||
|
||||
3. A user wants to download and directly decrypt an encrypted image to be used
|
||||
privately or in another deployment. Therefore the download mechanism should
|
||||
be adjusted on client side to directly decrypt such an image.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
For Glance we propose to add a new container_format called 'encrypted'.
|
||||
Furthermore, we propose the following additional metadata properties carried by
|
||||
images of this format:
|
||||
|
||||
* '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 key 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 after payload decryption, e.g. 'qcow'
|
||||
* 'os_decrypt_size' - size after payload decryption
|
||||
|
||||
To upload an encrypted image to Glance we want to add support for encrypting
|
||||
images using a key ID which references the symmetric key or passphrase in the
|
||||
key manager (e.g. Barbican) in the OpenStack Client. This also involves new
|
||||
CLI arguments to specify the key ID and encryption method.
|
||||
|
||||
In other words: the user has to encrypt an image before the upload. While
|
||||
uploading the encrypted image to Glance, the metadata properties above have to
|
||||
be specified and the container format has to be set to 'encrypted'.
|
||||
|
||||
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. Furthermore, we want to provide users with the means to encrypt
|
||||
images outside of the infrastructure for upload in Glance which will later be
|
||||
handled in similar ways by both Cinder and Nova.
|
||||
|
||||
The key management is handled differently than with encrypted volumes or
|
||||
encrypted ephemeral storage. The reason for this is, that the encryption and
|
||||
decryption of an image will never happen in Glance but only on client side.
|
||||
Therefore the service which needs to create a key for a newly created
|
||||
encrypted image may not be the same service which then has to delete the key
|
||||
(in most cases Glance). To delete a key, which has not been created by the same
|
||||
entity, is bad behavior. To avoid this, we choose to let the user create and
|
||||
delete the key and optionally delegate the deletion to Glance through setting
|
||||
a special metadata parameter. To not accidently delete a key, which is used to
|
||||
encrypt an image, we will let Glance register as a consumer of that key (secret
|
||||
in Barbican [1]) when the corresponding encrypted image is uploaded and
|
||||
unregister as a consumer when the image is deleted in Glance.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could introduce individual container types in Glance for each combination
|
||||
of data format and cipher algorithm instead of a single container type with
|
||||
metadata. This decision affects the implementation in nova and cinder.
|
||||
Regarding the image encryption, we also explored the possibility of using more
|
||||
elaborated and dynamic approaches like PKCS#7 (CMS) but ultimately failed to
|
||||
find a free open-source implementation (e.g. OpenSSL) that supports streamable
|
||||
decryption of CMS-wrapped encrypted data. More precisely, no implementation we
|
||||
tested was able to decrypt a symmetrically encrypted, CMS-wrapped container
|
||||
without trying to completely load it into memory or suffering from other
|
||||
limitations regarding big files.
|
||||
|
||||
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
|
||||
-----------------
|
||||
|
||||
The impact depends on whether the implementation will make actual changes to
|
||||
the image data model or simply use the generic properties field in the
|
||||
metadata. In the latter case the encryption properties would be added to
|
||||
metadefs.
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
While uploading an image, which should be encrypted, additional properties in
|
||||
the request body will need to be introduced to specify the desired encryption
|
||||
format and key id. Both to be used while encrypting the image locally before
|
||||
uploading it.
|
||||
|
||||
|
||||
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)
|
||||
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
* Users should be able to optionally, but knowingly upload an encrypted image.
|
||||
|
||||
* If an administrator has configured Glance to reject unencrypted images, such
|
||||
images will not be accepted when attempted to be uploaded to Glance.
|
||||
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The proposed encryption/decryption mechanisms in the OpenStack components will
|
||||
only be utilized on the client side and skipped entirely for image container
|
||||
types that aren’t encrypted.
|
||||
|
||||
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
|
||||
---------------------
|
||||
|
||||
* Deployers MUST allow the usage of encrypted images by adding 'encrypted' in
|
||||
'container_formats'. For interoperability between the OpenStack services only
|
||||
the presence of a key manager should decide, whether encryption can be used
|
||||
or not.
|
||||
|
||||
* Deployers enforcing the usage of encrypted images by omitting all other image
|
||||
types in 'container_formats' will make public images unavailable due to the
|
||||
lack of a public secrets functionality in Barbican.
|
||||
|
||||
* A key manager - like Barbican - is required, if encrypted images are to be
|
||||
used.
|
||||
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
We can assume, that all images that are encrypted and already present in an
|
||||
OpenStack deployment were created from encrypted Cinder volumes. They need to
|
||||
be adjusted in the following way:
|
||||
|
||||
* all images that have 'cinder_encryption_key_id' set, need to convert it to
|
||||
'os_encrypt_key_id'
|
||||
|
||||
* all images that have 'cinder_encryption_key_deletion_policy' set, need to
|
||||
convert it to 'os_encrypt_key_deletion_policy'
|
||||
|
||||
In the Glance config file the 'container_formats' have to be adjusted to also
|
||||
include 'encrypted'.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee: Markus Hentsch (IRC: mhen)
|
||||
|
||||
Other contributors: Josephine Seifert (IRC: Luzi)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add standardized parameters and container type(s) with encryption support to
|
||||
Glance
|
||||
|
||||
* Add registering as consumer for a Barbican secret when uploading an
|
||||
encrypted image
|
||||
|
||||
* Add unregistering as consumer for a Barbican secret when deleting an
|
||||
encrypted image
|
||||
|
||||
* Add support for providing the new image properties to the
|
||||
python-openstackclient and openstacksdk, so that an image where the
|
||||
'container_format' is 'encrypted' can be uploaded
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* The secret consumer API in Barbican is required for Glance to be able to
|
||||
register and unregister as a consumer of a secret
|
||||
|
||||
|
||||
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. An end user should have documentation on how to create
|
||||
and use encrypted images.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] Barbican Secret Consumer Spec:
|
||||
https://review.opendev.org/#/c/662013/
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Dalmatian
|
||||
- Introduced
|
||||
|
|
@ -6,7 +6,13 @@
|
|||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
TODO: fill this in once a new approved spec is added.
|
||||
2024.2 approved specs for glance:
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
glance/*
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue