Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Reza,

The Barbican team has already abstracted python-barbicanclient into a
general purpose key-storage library called Castellan [1]

There are a few OpenStack projects that have planned to integrate or
are currently integrating with Castellan to avoid a hard dependency on
Barbican.

There are some tradeoffs to choosing Castellan over
python-barbicanclient and Castellan may not be right for everyone.
Also, the only complete implementation of Castellan is currently the
Barbican implementation, so even though integrating with Castellan
does not result in a direct dependency, there is still work to be done
to have a working non-barbican solution.

- - Douglas Mendizábal

[1] http://git.openstack.org/cgit/openstack/castellan/

On 4/13/16 9:26 AM, rezroo wrote:
> Hi Kevin,
> 
> I understand that this is how it is now. My question is how bad 
> would it be to wrap the Barbican client library calls in another 
> class and claim, for all practical purposes, that Magnum has no 
> direct dependency on Barbican? What is the negative of doing that?
> 
> Anyone who wants to use another mechanism should be able to do
> that with a simple change to the Magnum conf file. Nothing more 
> complicated. That's the essence of my question.
> 
> Appreciate your thoughts and insight.
> 
> Reza
> 
> On 4/13/2016 6:46 AM, Fox, Kevin M wrote:
>> Barbican is the abstraction layer. Its plugable like nova, 
>> neutron, cinder, etc.
>> 
>> Thanks, Kevin *
>> 
>> * 
>> ---------------------------------------------------------------------
- ---
>>
>>
>> 
*From:* rezroo
>> *Sent:* Tuesday, April 12, 2016 11:00:30 PM *To:* 
>> openstack-dev at lists.openstack.org *Subject:* Re: [openstack-dev] 
>> [magnum][keystone][all] Using Keystone /v3/credentials to store 
>> TLS certificates
>> 
>> 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> 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> 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>https://blueprints.launchpad.net/magnum/+spec/barbican-alternativ
e-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:unsubscri
be>
>>>> 
>>>> 
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:unsubscr
ibe
>>>>
>>>>
>>>> 
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
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXDntdAAoJEB7Z2EQgmLX7ROAP/0mEXOT331//V+wIfXa4EA3t
vMIP+yn20oR7+LtIDchEIKEs96G/VaH9mcNQKRER7moAe/dABOLhmshhXHB4/1aK
dUR78RCAmN5WNaiAlW0svmuuKmQNCanaCSOSjnPDJ4oTipPfWijnLpU1nupVnk6K
+9zg2BGJgrX7SfWOtnx6GYnu6g+v5N9hsiw8YG6049aUY4ePM5uRhMg02JNdL57I
OILiad0RM7Wey5l7vodH1J5FhDxSg/jxlrcXDUShP6xlNzlzCBlLbmx8kENuvshe
Q/MnY6day/xOl6AG3k1VPMCr4Xl0XtxugE6IulrK0Io/lHTb4pKan9zuMm/F9gMI
zgMirmrgIHJnItcX73DvJLa3yW6iLhXf8ppdmszVctTwG4dok+Np+WVFtWYqJjXM
DGBSRVeQ8cAaNUCVGQ4VvP+B8lLJmEQYxmEZ/40xhNc5NzrmUaPq2EPnSuhq1bsa
Tf4iOW4YeO0YsEe+MCX58nUBvLZuiUQ/oCFM/xG1oW7lDI8/kGAw6wUwWfSZyB+A
ti7/oTRBgxffOHMYYcD3TQhyyyBGZmQRuxM2EVcPWytPhhV8f92ssJj13K2muZ+1
xU+miQnKqKarxc7f5tXmPPdrWIdjdZeLQBEdYXz98mEEvyRxRKGbUsAZXeQvrSDK
sIBUlxtajd4a4m7+6XFG
=9qii
-----END PGP SIGNATURE-----