Re: [openstack-dev] [Nova][FFE] requesting FFE for LVM ephemeral storage encryption
On Thu, Sep 04, 2014 at 11:41:48AM -0400, Dan Genin wrote: I would like to request a feature freeze exception for LVM ephemeral storage encryption[1]. The spec[2] for which was approved early in the Juno release cycle. This feature provides security for data at-rest on compute nodes. The proposed feature protects user data from disclosure due to disk block reuse and improper storage media disposal among other threats and also eliminates the need to sanitize LVM volumes. The feature is crucial to data security in OpenStack as explained in the OpenStack Security Guide[3] and benefits cloud users and operators regardless of their industry and scale. The feature was first submitted for review on August 6, 2013 and two of the three patches implementing this feature were merged in Icehouse[4,5]. The remaining patch has had approval from a core reviewer for most of the Icehouse and Juno development cycles. The code is well vetted and ready to be merged. The main concern about accepting this feature pertains to key management. In particular, it uses Barbican to avoid storing keys on the compute host, and Barbican at present has no gate testing. However, the risk of regression in case of failure to integrate Barbican is minimal because the feature interacts with the key manager through an*existing* abstract keymgr interface, i.e., has no*explicit* dependence on Barbican. Moreover, the feature provides some measure of security even with the existing place-holder key manager, for example, against disk block reuse attack. For all of the above reasons I request a feature freeze exception for LVM ephemeral storage encryption. I'm happy to sponsor this, since I've positively reviewed it and it is a pretty well isolated feature so risk to other existing code is low. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][FFE] requesting FFE for LVM ephemeral storage encryption
On 09/04/2014 11:48 AM, Daniel P. Berrange wrote: On Thu, Sep 04, 2014 at 11:41:48AM -0400, Dan Genin wrote: I would like to request a feature freeze exception for LVM ephemeral storage encryption[1]. The spec[2] for which was approved early in the Juno release cycle. This feature provides security for data at-rest on compute nodes. The proposed feature protects user data from disclosure due to disk block reuse and improper storage media disposal among other threats and also eliminates the need to sanitize LVM volumes. The feature is crucial to data security in OpenStack as explained in the OpenStack Security Guide[3] and benefits cloud users and operators regardless of their industry and scale. The feature was first submitted for review on August 6, 2013 and two of the three patches implementing this feature were merged in Icehouse[4,5]. The remaining patch has had approval from a core reviewer for most of the Icehouse and Juno development cycles. The code is well vetted and ready to be merged. The main concern about accepting this feature pertains to key management. In particular, it uses Barbican to avoid storing keys on the compute host, and Barbican at present has no gate testing. However, the risk of regression in case of failure to integrate Barbican is minimal because the feature interacts with the key manager through an*existing* abstract keymgr interface, i.e., has no*explicit* dependence on Barbican. Moreover, the feature provides some measure of security even with the existing place-holder key manager, for example, against disk block reuse attack. For all of the above reasons I request a feature freeze exception for LVM ephemeral storage encryption. I'm happy to sponsor this, since I've positively reviewed it and it is a pretty well isolated feature so risk to other existing code is low. I'm happy to sponsor this one. The last patch is pretty straight forward, I think one change around the way barbican is included should make it ready (reviewed yesterday). -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
