The following change provides a key manager implementation that reads a static key from the project's configuration: https://review.openstack.org/#/c/45103/
This key manager implementation naturally does not provide the same confidentiality that would be proffered by retrieving keys from a service like Barbican or a KMIP server, but it still provides protection against certain attacks like intercepting iSCSI traffic between the compute and storage host and lost / stolen disks. From: Bryan D. Payne [mailto:bdpa...@acm.org] Sent: Wednesday, September 04, 2013 9:47 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] key management and Cinder volume encryption External dependencies are fine, obviously. The difference is whether we actually have code to interface with those external dependencies. We have code to talk to databases and message queues. There's no code right now to interface with anything for key management. Ok, this makes sense. I generally assume that people deploying OpenStack have some integration work to do anyway. So, for me, writing a few python methods isn't much different than writing a configuration file. Having said this, I do understand where you are coming from here. I do believe that a static key configuration is a useful starting place for a lot of users. I spoke with Joel this morning and I think he is going to try to put together an example key management driver that does this today. Such a solution would allow deployers to use their existing orchestration tools to write a key to a configuration file. Cheers, -bryan
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
