On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto <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> > wrote: > > > On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <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> >> 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://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 >> >> > __________________________________________________________________________ > 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 > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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