Open Stack

Dear OpenStack developers,

we would like to propose the introduction of an encrypted image format
in OpenStack. We already created a basic implementation involving Nova,
Cinder, OSC and Glance, which we'd like to contribute.

We originally created a full spec document but since the official
cross-project contribution workflow in OpenStack is a thing of the past,
we have no single repository to upload it to. Thus, the Glance team
advised us to post this on the mailing list [1].

Ironically, Glance is the least affected project since the image
transformation processes affected are taking place elsewhere (Nova and
Cinder mostly).

Below you'll find the most important parts of our spec that describe our
proposal - which our current implementation is based on. We'd love to
hear your feedback on the topic and would like to encourage all affected
projects to join the discussion.

Subsequently, we'd like to receive further instructions on how we may
contribute to all of the affected projects in the most effective and
collaborative way possible. The Glance team suggested starting with a
complete spec in the glance-specs repository, followed by individual
specs/blueprints for the remaining projects [1]. Would that be alright
for the other teams?

[1]
http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html

Best regards,
Markus Hentsch

(excerpts from our image encryption spec below)

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. That’s why we propose the
introduction of an encrypted image format.

Use Cases
---------

* 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.

* A user wants to create an image from an existing server with ephemeral
storage. This server may contain sensitive user data. The corresponding
compute host then generates the image based on the data of the ephemeral
storage disk. To protect the confidentiality of the data within the
image, the user wants Nova to also encrypt the image using a key from
the key manager, specified by its secret ID. Consequently, the image
stored on the Glance host is encrypted.

* A user wants to create a new server or volume based on an encrypted
image created by any of the use cases described above. The corresponding
compute or volume host has to be able to decrypt the image using the
symmetric key stored in the key manager and transform it into the
requested resource (server disk or volume).

Although not required on a technical level, all of the use cases
described above assume the usage of encrypted volume types and encrypted
ephemeral storage as provided by OpenStack.


Proposed changes
================

* Glance: Adding a container type for encrypted images that supports
different mechanisms (format, cipher algorithms, secret ID) via a
metadata property. Whether introducing several container types or
outsourcing the mechanism definition into metadata properties may still
be up for discussion, although we do favor the latter.

* Nova: Adding support for decrypting an encrypted image when a servers
ephemeral disk is created. This includes direct decryption streaming for
encrypted disks. Nova should select a suitable mechanism according to
the image container type and metadata. The symmetric key will be
retrieved from the key manager (e.g. Barbican).

* Cinder: Adding support for decrypting an encrypted image when a volume
is created from it. Cinder should select a suitable mechanism according
to the image container type and metadata. The symmetric key will be
retrieved from the key manager (e.g. Barbican).

* OpenStack Client / SDK: Adding support for encrypting images using a
secret ID which references the symmetric key in the key manager (e.g.
Barbican). This also involves new CLI arguments to specify the secret ID
and encryption method.

We propose to use an implementation of symmetric AES 256 encryption
provided by GnuPG as a basic mechanism supported by this draft. It is a
well established implementation of PGP and supports streamable
encryption/decryption processes, which is important as illustrated below.

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 require the streamability of the encryption/decryption mechanism for
two reasons:

1. Loading entire images into the memory of compute hosts or a users
system is unacceptable.

2. We propose direct decryption-streaming into the target storage (e.g.
encrypted volume) to prevent the creation of temporary unencrypted files.