Open Stack

On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto <adrian.otto at 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.mathews at gmail.com>
> wrote:
>
>
> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <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>
>> 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://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
>>
>>
> __________________________________________________________________________
> 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
>
>
> __________________________________________________________________________
> 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/0f0bd2c0/attachment.html>