Open Stack

Interesting conversation, and I think I have more of a question than a 
comment. With my understanding of OpenStack architecture, I don't 
understand the point about making "Magnum dependent on Barbican". 
Wouldn't this issue be completely resolved using a driver model, such as 
delegating the task to a separate class specified in magnum.conf, with a 
reference implementation using Barbian API (like the vif driver of nova, 
or nova chance vs. filter scheduler)? If people want choice, we know how 
to give them choice - decouple, and have a base implementation. The rest 
is up to them. That's the framework's architecture. What am I missing?
Thanks,
Reza

On 4/12/2016 9:16 PM, Fox, Kevin M wrote:
> Ops are asking for you to make it easy for them to make their security 
> weak. And as a user of other folks clouds, i'd have no way to know the 
> cloud is in that mode. That seems really bad for app developers/users.
>
> Barbican, like some of the other servises, wont become common if folks 
> keep trying to reimplement it so they dont have to depend on it. Folks 
> said the same things about Keystone. Ultimately it was worth making it 
> a dependency.
>
> Keystone doesnt support encryption, so you are asking for new 
> functionality duplicating Barbican either way.
>
> And we do understand the point of what you are trying to do. We just 
> dont see eye to eye on it being a good thing to do. If you are 
> invested enough in setting up an ha setup where you would need a 
> clusterd solution, barbicans not that much of an extra lift compared 
> to the other services you've already had to deploy. Ive deployed both 
> ha setups and barbican before. Ha is way worse.
>
> Thanks,
> Kevin
>
> *
> *
> ------------------------------------------------------------------------
> *From:* Adrian Otto
> *Sent:* Tuesday, April 12, 2016 8:06:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum][keystone][all] Using Keystone 
> /v3/credentials to store TLS certificates
>
> 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.
>
> -- 
> Adrian
>
> On Apr 12, 2016, at 3:44 PM, Dolph Mathews <dolph.mathews at gmail.com 
> <mailto:dolph.mathews at gmail.com>> wrote:
>
>>
>> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <lbragstad at gmail.com 
>> <mailto:lbragstad at 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.lu at huawei.com <mailto:hongbin.lu at 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-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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-request at lists.openstack.org 
>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160412/ac0536f5/attachment.html>