Re: [openstack-dev] [nova][cinder] Using externally stored keys for encryption
Dear Mohammed, with SecuStack we've been integrating end-to-end (E2E) transfer of secrets into the OpenStack code. From your problem description, it sounds like our implementation would address some of your points. For below explanation, I will refer to those secrets as "keys". Our solution works as follows: - when the user creates an encrypted resource, they may specify to use E2E key transfer instead of Barbican - the resource will be allocated and enter a state where it is waiting for the transmission of the key - the user establishes an E2E relationship with the compute/volume host where the resource has been scheduled - the key is encrypted (asymmetrically) on the user side specifically for this host (using its public key) and transferred through the API to this host - the key reaches the compute/volume host, is decrypted by the host's private key and is then used temporarily for the duration of the resource creation and discarded afterwards Whenever such resource is to be used (instance booted or volume attached), a similar workflow is triggered on-demand that requires the key to be transferred via the E2E channel again. Our solution is complemented by an extension of the Barbican workflow which also allows users to specify secret IDs and manage them manually for encrypted resources instead of having OpenStack handle all of that automatically. This represents a solution that is kind of in-between the current OpenStack and our E2E approach. We have not looked into external Barbican integration yet, though. We do plan to contribute our E2E key transfer and user-centric key control to OpenStack, if we can obtain support for this idea. However, we are currently in the middle of trying to contribute image encryption to OpenStack, which is already proving to be a lengthy process as it involves a lot of different teams. The E2E stuff would be an even bigger change across the components. Unfortunately, we currently don't have the resources to tackle two huge contributions at the same time as it requires a lot of effort getting multiple teams to agree on a single solution. Best regards, Markus Hentsch Mohammed Naser wrote: > Hi everyone: > > I've been digging around the documentation of Nova, Cinder and the > encrypted disks feature and I've been a bit stumped on something which > I think is a very relevant use case that might not be possible (or it > is and I have totally missed it!) > > It seems that both Cinder and Nova assume that secrets are always > stored within the Barbican deployment in the same cloud. This makes a > lot of sense however in scenarios where the consumer of an OpenStack > cloud wants to operate it without trusting the cloud, they won't be > able to have encrypted volumes that make sense, an example: > > - Create encrypted volume, keys are stored in Barbican > - Boot VM using said encrypted volume, Nova pulls keys from Barbican, > starts VM.. > > However, this means that the deployer can at anytime pull down the > keys and decrypt things locally to do $bad_things. However, if we had > something like any of the following two ideas: > > - Allow for "run-time" providing secret on boot (maybe something added > to the start/boot VM API?) > - Allow for pointing towards an external instance of Barbican > > By using those 2, we allow OpenStack users to operate their VMs > securely and allowing them to have control over their keys. If they > want to revoke all access, they can shutdown all the VMs and cut > access to their key storage management and not worry about someone > just pulling them down from the internal Barbican. > > Hopefully I did a good job explaining this use case and I'm just > wondering if this is a thing that's possible at the moment or if we > perhaps need to look into it. > > Thanks, > Mohammed > __ 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
Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Dear OpenStack developers, as you suggested, we have written individual specs for Nova [1] and Cinder [2] so far and will write another spec for Glance soon. We'd appreciate any feedback and reviews on the specs :) Thank you in advance, Markus Hentsch [1] https://review.openstack.org/#/c/608696/ [2] https://review.openstack.org/#/c/608663/ __ 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
[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Hello Eric, Eric Harney wrote: > > 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.) > We are aware of this and plan to integrate this existing case with our new approach. This would mean that the container_format property of such image - which currently is simply 'bare' iirc - would be changed to the new one for encrypted images and its metadata adjusted to contain appropriate information about the encryption used. Such metadata would indicate the Cinder-specific encryption in this case and differentiate it from our general encryption mechanism. Regarding the key deletion: that's an interesting point actually. Although OpenStack does create and delete keys for encryption of volumes or ephemeral storage itself automatically, we didn't plan to do that in our current proposal for the image encryption. As our quoted use cases describe, the user is to upload or order a key in Barbican beforehand themselves. This means the key management (including deletion) for encrypted images was meant to be in the hand of the user. I wonder, would this be undesired from the OpenStack perspective? Best regards, Markus __ 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
Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Hello Julia, we will begin formulating an individual spec for each project accordingly. Regarding your question: as you already assumed correctly, the code necessary to handle image decryption is driver specific in our current design as it is very close to the point where the ephemeral storage disk is initialized. Our proposed goal of direct decryption streaming makes it hard to design this in a generic fashion since we can't simply place the decrypted image somewhere temporarily in a generic place and then take it as a base for a driver specific next step, since that'd expose the image data. Best regards, Markus Julia Kreger wrote: > Greetings! > > I suspect the avenue of at least three different specs is likely going > to be the best path forward and likely what will be required for each > project to fully understand how/what/why. From my point of view, I'm > quite interested in this from a Nova point of view because that is the > initial user interaction point for majority of activities. I'm also > wondering if this is virt driver specific, or if it can be applied to > multiple virt drivers in the nova tree, since each virt driver has > varying constraints. So maybe the best path forward is something nova > centric to start? > > -Julia > > On Thu, Sep 27, 2018 at 10:36 AM 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 >> > [trim] > > __________ > 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 > -- ** *Markus Hentsch* Head of Cloud Innovation CLOUD *CLOUD & HEAT Technologies GmbH* Königsbrücker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: markus.hent...@cloudandheat.com <mailto:markus.hent...@cloudandheat.com> Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Geschäftsführer: Nicolas Röhrs __ 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
[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
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
