Thanks for your inputs. It sounds like we have no other option besides Barbican as long as we need to store credentials in Magnum. Then I have a new proposal: switch to an alternative authentication mechanism that doesn't require to store credentials in Magnum. For example, the following options are available in Kubernetes [1]:
· Client certificate authentication · Token File · OpenID Connect ID Token · Basic authentication · Keystone authentication Could we pick one of those? [1] http://kubernetes.io/docs/admin/authentication/ Best regards, Hongbin From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com] Sent: March-19-16 10:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum] High Availability The most basic requirement here for Magnum is that it needs a safe place to store credentials. A safe place can not be provided by just a library or even by just a daemon. Secure storage is provided by either hardware solution (an HSM) or a software solution (SoftHSM, DogTag, IPA, IdM). A project should give a variety of secure storage options to the user. On this, we have competing requirements. Devs need a turnkey option for easy testing locally or in the gate. Users kicking the tires want a realistic solution they try out easily with DevStack. Operators who already have secure storage deployed for their cloud want an option that plugs into their existing HSMs. Any roll-your-own option is not going to meet all of these requirements. A good example, that does meet all of these requirements, is the key manager implementation in Nova and Cinder. [1] [2] Nova and Cinder work together to provide volume encryption, and like Magnum, have a need to store and share keys securely. Using a plugin architecture, and the Barbican API, they implement a variety of key storage options: - Fixed key allows for insecure stand alone operation, running only Nova and Cinder - Barbican with static key, allows for easy deployment that can be started within DevStack by few lines of config. - Barbican with a secure backend, allows for production grade secure storage of keys that has been tested on a variety of HSMs and software options. Barbican's adoption is growing. Nova, Cinder, Neutron LBaaS, Sahara, and Magnum all have implementations using Barbican. Swift and DNSSec also have use cases. There are both RPM and Debian packages available for Barbican. There are (at least tech preview) versions of puppet modules, Ansible playbooks, and DevStack plugins to deploy Barbican. In summary, I think using Barbican absorbs the complexity of doing secure storage correctly. It gives operators production grade secure storage options, while giving devs easier options. --Dave McCowan [1] https://github.com/openstack/nova/tree/master/nova/keymgr [2] https://github.com/openstack/cinder/tree/master/cinder/keymgr From: Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Friday, March 18, 2016 at 10:52 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] High Availability 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
