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