Open Stack

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