Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Matthew Oliver]

Just an FYI, it doesn't solved cached images, but Swift does support at
rest encryption, so if using the Swift store backend you can at least know
your image on disk on the storage nodes would be safe.
We still need to add more functionality like key rotation, but we do
integrate with kmip sevices or barbican.

Still could be a good idea for other projects. I wasn't the one who wrote
the Swift at-rest encryption but happy to, probably badly, help answer
questions cause we might have some interesting lessons learned.

Matt

On Tue, Oct 16, 2018 at 12:36 AM Josephine Seifert <
josephine.seif...@secustack.com> wrote:

> Hello OpenStack developers,
>
> we have made an etherpad as there were a few questions concerning
> the library we want to use for the encryption and decryption method:
>
>
> https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
>
>
> Am 11.10.2018 um 15:10 schrieb Josephine Seifert:
> > Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
> >> 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
> > The spec for Glance is also on gerrit now:
> >
> > https://review.openstack.org/#/c/609667/
> >
> >
> __
> > 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 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 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)

[Josephine Seifert]

Hello OpenStack developers,

we have made an etherpad as there were a few questions concerning
the library we want to use for the encryption and decryption method:

https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption


Am 11.10.2018 um 15:10 schrieb Josephine Seifert:
> Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
>> 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
> The spec for Glance is also on gerrit now:
>
> https://review.openstack.org/#/c/609667/
>
> __
> 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 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)

[Josephine Seifert]

Am 08.10.2018 um 17:16 schrieb Markus Hentsch:
> 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

The spec for Glance is also on gerrit now:

https://review.openstack.org/#/c/609667/

__
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)

[Markus Hentsch]

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)

[Markus Hentsch]

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)

[Eric Harney]

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 

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Julia Kreger]

On Fri, Sep 28, 2018 at 5:00 AM Jeremy Stanley  wrote:

>
> If memory serves, the biggest challenge around that solution was
> determining who approves such proposals since they still need
> per-project specs for the project-specific details anyway. Perhaps
> someone who has recently worked on a feature which required
> coordination between several teams (but not a majority of teams like
> our cycle goals process addresses) can comment on what worked for
> them and what improvements they would make on the process they
> followed.
> --

This is definitely the biggest challenge, and I think it is one of
those things that is going to be on case by case basis.

In the case of neutron smartnic support with ironic, the spec is
largely living in ironic-specs, but we are collaborating with neutron
folks. They may have other specs that tie in, but that we don't
necessarily need to be aware of. I also think the prior ironic/neutron
integration work executed that way.  My perception with nova has also
largely been similar with ironic's specs driving some changes in the
nova ironic virt driver because we were evolving ironic, as long as
there is a blueprint or something tracking that piece of work so they
have visibility.  At some point, some spec has to get a green light or
be pushed forward first. Beyond that, it is largely a tracking issue
as long as there is consensus.

__
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)

[Josephine Seifert]

Hi,

Am 28.09.2018 um 13:51 schrieb Erlon Cruz:
> I don't know if our workflow supports this, but it would be nice to
> have a place to
> place cross-projec changes like that (something like,
> openstack-cross-projects-specs), 
> and use that as a initial point for high level discussions. But for
> now, you can start creating
> specs for the projects involved.
There was a repository for cross-project-specs, but it is deprecated:
https://github.com/openstack/openstack-specs

So we are currently writing specs for each involved project, as suggested.
You are right, it would be nice to discuss this topic with people from
all involved projects together.
> When you do so, please bring the topic to the project weekly
> meetings[1][2][3]
We actually started with bringing this up in the Glance meeting yesterday.
And of course, we would like to discuss our specs in the project
meetings. :)

Best regards,
Josephine (Luzi)


__
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)

[Markus Hentsch]

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

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

Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Jeremy Stanley]

On 2018-09-28 08:51:46 -0300 (-0300), Erlon Cruz wrote:
> I don't know if our workflow supports this, but it would be nice
> to have a place to place cross-projec changes like that (something
> like, openstack-cross-projects-specs), and use that as a initial
> point for high level discussions. But for now, you can start
> creating specs for the projects involved.
[...]

If memory serves, the biggest challenge around that solution was
determining who approves such proposals since they still need
per-project specs for the project-specific details anyway. Perhaps
someone who has recently worked on a feature which required
coordination between several teams (but not a majority of teams like
our cycle goals process addresses) can comment on what worked for
them and what improvements they would make on the process they
followed.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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)

[Erlon Cruz]

I don't know if our workflow supports this, but it would be nice to have a
place to
place cross-projec changes like that (something like,
openstack-cross-projects-specs),
and use that as a initial point for high level discussions. But for now,
you can start creating
specs for the projects involved.

When you do so, please bring the topic to the project weekly
meetings[1][2][3] so you can get
some attention and feedback.

Erlon
___
[1] https://wiki.openstack.org/wiki/Meetings/Glance
[2] https://wiki.openstack.org/wiki/Meetings/Nova
[3] https://wiki.openstack.org/wiki/CinderMeetings



Em qui, 27 de set de 2018 às 22:51, hao wang 
escreveu:

> +1 to Julia's suggestion, Cinder should also have a spec to discuss
> the detail about how to implement the creation of volume from an
> encrypted image.
> Julia Kreger  于2018年9月28日周五 上午9:39写道：
> >
> > 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
>
> __
> 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 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)

[hao wang]

+1 to Julia's suggestion, Cinder should also have a spec to discuss
the detail about how to implement the creation of volume from an
encrypted image.
Julia Kreger  于2018年9月28日周五 上午9:39写道：
>
> 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

__
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)

[Julia Kreger]

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

[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Markus Hentsch]

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