[openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates
rezroo
openstack at roodsari.us
Wed Apr 13 06:00:30 UTC 2016
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>
More information about the OpenStack-dev
mailing list