I think there are two questions here: 1. Should Magnum decouple from Barbican?
2. Which options Magnum should use to achieve #1 (leverage Keystone credential store, or other alternatives [1])? For question #1, Magnum team has thoughtfully discussed it. I think we all agreed that Magnum should decouple from Barbican for now (I didn’t hear any disagreement from any of our team members). What we are currently debating is question #2. That is which approach we should use to achieve the goal. The first option is to store TLS credentials in Keystone. The second option is to store the credentials in Magnum DB. The third option is to eliminate the need to store TLS credentials (e.g. switch to another non-TLS authentication mechanism). What we want to know is if Keystone team allows us to pursue the first option. If it is disallowed, I will suggest Magnum team to pursue other options. So, for the original question, does Keystone team allow us to store encrypted data in Keystone? A point of view is that if the data to be stored is already encrypted, there will be no disagreement from Keystone side (so far, all the concerns is about the security implications of storing un-encrypted data). Would I confirm if Keystone team agrees (or doesn’t disagree) with this point of view? [1] https://etherpad.openstack.org/p/magnum-barbican-alternative Best regards, Hongbin From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] Sent: April-13-16 12:08 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto <adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> wrote: Please don't miss the point here. We are seeking a solution that allows a location to place a client side encrypted blob of data (A TLS cert) that multiple magnum-conductor processes on different hosts can reach over the network. We *already* support using Barbican for this purpose, as well as storage in flat files (not as secure as Barbican, and only works with a single conductor) and are seeking a second alternative for clouds that have not yet adopted Barbican, and want to use multiple conductors. Once Barbican is common in OpenStack clouds, both alternatives are redundant and can be deprecated. If Keystone depends on Barbican, then we have no reason to keep using it. That will mean that Barbican is core to OpenStack. Our alternative to using Keystone is storing the encrypted blobs in the Magnum database which would cause us to add an API feature in magnum that is the exact functional equivalent of the credential store in Keystone. That is something we are trying to avoid by leveraging existing OpenStack APIs. Is it really unreasonable to make Magnum depend on Barbican? I know I discussed this with you previously, but I would like to know how much pushback you're really seeing on saying "Barbican is important for these security reasons in a scaled-up environment and here is why we made this choice to depend on it". Secure by default is far better than an option that is significantly sub-optimal. So, is Barbican support really hampering Magnum in significant ways? If so, what can we do to improve the story to make Barbican compelling instead of needing this alternative? +1 to Dolph's comment on Barbican being more mature *and* another +1 for the comment that credentials being un-encrypted in keystone makes storing secure credentials in keystone significantly less desirable. These questions are intended to just fill in some blanks I am seeing so we have a complete story and can look at prioritizing work/specs/etc. -- Adrian On Apr 12, 2016, at 3:44 PM, Dolph Mathews <dolph.math...@gmail.com<mailto:dolph.math...@gmail.com>> wrote: On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <lbrags...@gmail.com<mailto:lbrags...@gmail.com>> wrote: Keystone's credential API pre-dates barbican. We started talking about having the credential API back to barbican after it was a thing. I'm not sure if any work has been done to move the credential API in this direction. From a security perspective, I think it would make sense for keystone to back to barbican. +1 And regarding the "inappropriate use of keystone," I'd agree... without this spec, keystone is entirely useless as any sort of alternative to Barbican: https://review.openstack.org/#/c/284950/ I suspect Barbican will forever be a much more mature choice for Magnum. On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote: Hi all, In short, some Magnum team members proposed to store TLS certificates in Keystone credential store. As Magnum PTL, I want to get agreements (or non-disagreement) from OpenStack community in general, Keystone community in particular, before approving the direction. In details, Magnum leverages TLS to secure the API endpoint of kubernetes/docker swarm. The usage of TLS requires a secure store for storing TLS certificates. Currently, we leverage Barbican for this purpose, but we constantly received requests to decouple Magnum from Barbican (because users normally don’t have Barbican installed in their clouds). Some Magnum team members proposed to leverage Keystone credential store as a Barbican alternative [1]. Therefore, I want to confirm what is Keystone team position for this proposal (I remembered someone from Keystone mentioned this is an inappropriate use of Keystone. Would I ask for further clarification?). Thanks in advance. [1] https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store Best regards, Hongbin __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ 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
