Open Stack

On 9/27/18 1:36 PM, Markus Hentsch wrote:
> 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).

Are you aware of the existing Cinder support for similar functionality?

When encrypted volumes are uploaded to Glance images from Cinder, 
encryption keys are cloned in Barbican and tied to Glance images as 
metadata.  Then, volumes created from those images can consume the 
Barbican key to use the volume.

The keys I mention here are used for the LUKS encryption layer -- which 
is different from what you are proposing.  But I'd like to point it out 
to make sure that the interaction between the two different encryption 
methods is understood when designing this and considering use cases.

(Note: there is still at least one big TODO pending around this 
functionality, namely that the Glance service doesn't know to remove a 
key from Barbican when the image is deleted from Glance.)

> 
> * 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.
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>