[openstack-dev] Volume Encryption

Caitlin Bestler caitlin.bestler at nexenta.com
Wed Feb 13 22:22:04 UTC 2013


On 2/13/2013 12:51 PM, Oleg Gelbukh wrote:
> Hello,
>
> I believe that this discussion need actually be split into two parts: 
> encryption algorithms and specific tools, and key management.
>
> The implementation of actual encryption are specific for every 
> project. We identified a number of blueprints which utilize encryption 
> in one way or another:
> https://blueprints.launchpad.net/keystone/+spec/access-key-authentication
> https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-volumes
> https://blueprints.launchpad.net/swift/+spec/encrypted-objects
> https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
>
> All these blueprints involve some key management, and it seems 
> reasonable to implement it as a shared component. Where does it 
> belongs is a discussion topic. Our understanding is that Keystone API 
> could be extended with new resource keys/ to proxy keys operations 
> with pluggable back-end drivers (much like Identity or Catalog).
>
> Please, tell me if this sounds reasonable to you. Do you think this 
> kind of discussion should take place at Summit?
>
> --
> Best regards,
> Oleg
>
Agreed separation of key management from specific encryption algorithms, 
or how encryption is actually done, is vital.

We also want to enable use of common encryption/decryption solutions 
underlying all OpenStack projects.
Vendors should be able to implement this once, and not be forced to 
support Cinder in 2Q14 while waiting
for 4Q14 for Swift. If someone wants to support just Cinder or just 
Swift, that's fine. But you shouldn't support
both but only support encryption for one.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130213/be13ea4f/attachment.html>


More information about the OpenStack-dev mailing list