OK. If using Keystone is not acceptable, I am going to propose a new approach:
· Store data in Magnum DB · Encrypt data before writing it to DB · Decrypt data after loading it from DB · Have the encryption/decryption key stored in config file · Use encryption/decryption algorithm provided by a library The approach above is the exact approach used by Heat to protect hidden parameters [1]. Compared to the Barbican option, this approach is much lighter and simpler, and provides a basic level of data protection. This option is a good supplement to the Barbican option, which is heavy but provides advanced level of protection. It will fit into the use cases that users don’t want to install Barbican but want a basic protection. If you disagree, I would request you to justify why this approach works for Heat but not for Magnum. Also, I also wonder if Heat has a plan to set a hard dependency on Barbican for just protecting the hidden parameters. If you don’t like code duplication between Magnum and Heat, I would suggest to move the implementation to a oslo library to make it DRY. Thoughts? [1] https://specs.openstack.org/openstack/heat-specs/specs/juno/encrypt-hidden-parameters.html Best regards, Hongbin From: David Stanek [mailto:dsta...@dstanek.com] Sent: March-18-16 4:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] High Availability On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal <douglas.mendiza...@rackspace.com<mailto:douglas.mendiza...@rackspace.com>> wrote: [snip] > > Regarding the Keystone solution, I'd like to hear the Keystone team's > feadback on that. It definitely sounds to me like you're trying to put a > square peg in a round hole. > I believe that using Keystone for this is a mistake. As mentioned in the blueprint, Keystone is not encrypting the data so magnum would be on the hook to do it. So that means that if security is a requirement you'd have to duplicate more than just code. magnum would start having a larger security burden. Since we have a system designed to securely store data I think that's the best place for data that needs to be secure.
__________________________________________________________________________ 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
