Open Stack

On 17/01/17 10:09, Fox, Kevin M wrote:
> If the developers that had issue with the lack of functionality, contributed to Barbican rather then go off on their own, the problem would have been solved much more quickly. The lack of sharing means the problems don't get fixed as fast.
>
> As for operators, If the more common projects all started depending on it, it would be commonly deployed. Would the operators deploy Barbican just for Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely . Would they deploy it if Neutron and Keystone depended on it, yeah. they would.

IMHO, I think one of reasons is some projects just care the projects
themselves. They don't want to add any any dependency for the other
projects if they can. Though we know we should think this from higher
level, which can finally benefit OpenStack.  In other words, we only
care about if the project I'm working on can be adopted more widely. We
don't think this from the whole community's view. Big tent is making
things worse from this point of view. Most of the new non-core services
want more adoption, so any thing may impact their adoptions will be
removed from the list. As for core service, anything may impact their
existing positions will be removed from the list. It maybe correct from
the project's view, but it's not good from the OpenStack's view. For
example, if Nova or Neutron need a secret store, what are they going to
do? I'm sure Barbican will be a soft dep, just like Magnum did.

We're fear to let the projects end up depending on each other. I don't
think integration is wrong if the integration is made for good reasons.

> And then all the other projects would benefit from it being there, such as Magnum. The sooner OpenStack as a whole can decide on some new core components so that projects can start hard depending on them, the better I think. That process kind of stopped with the arrival of the big tent.
>
> Thanks,
> Kevin
>
> ________________________________________
> From: Adrian Otto [adrian.otto at rackspace.com]
> Sent: Monday, January 16, 2017 11:55 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?
>
>> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <dmccowan at cisco.com> wrote:
>>
>> On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmavirus24 at gmail.com> wrote:
>>
>>> -----Original Message-----
>>> From: Rob C <hyakuhei at gmail.com>
>>> Reply: OpenStack Development Mailing List (not for usage questions)
>>> <openstack-dev at lists.openstack.org>
>>> Date: January 16, 2017 at 10:33:20
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> <openstack-dev at lists.openstack.org>
>>> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>>> projects trying to avoid Barbican, still?
>>>
>>>> Thanks for raising this on the mailing list Ian, I too share some of
>>>> your consternation regarding this issue.
>>>>
>>>> I think the main point has already been hit on, developers don't want to
>>>> require that Barbican be deployed in order for their service to be
>>>> used.
>>>>
>>>> The resulting spread of badly audited secret management code is pretty
>>>> ugly and makes certifying OpenStack for some types of operation very
>>>> difficult, simply listing where key management "happens" and what
>>>> protocols are in use quickly becomes a non-trivial operation with some
>>>> teams using hard coded values while others use configurable algorithms
>>>> and no connection between any of them.
>>>>
>>>> In some ways I think that the castellan project was supposed to help
>>>> address the issue. The castellan documentation[1] is a little sparse but
>>>> my understanding is that it exists as an abstraction layer for
>>>> key management, such that a service can just be set to use castellan,
>>>> which in turn can be told to use either a local key-manager, provided by
>>>> the project or Barbican when it is available.
>>>>
>>>> Perhaps a miss-step previously was that Barbican made no efforts to
>>>> really provide a robust non-HSM mode of operation. An obvious contrast
>>>> here is with Hashicorp Vault[2] which has garnered significant market
>>>> share in key management because it's software-only* mode of operation is
>>>> well documented, robust and cryptographically sound. I think that the
>>>> lack of a sane non-HSM mode, has resulted in developers trying to create
>>>> their own and contributed to the situation.
> Bingo!
>
>>>> I'd be interested to know if development teams would be less concerned
>>>> about requiring Barbican deployments, if it had a robust non-HSM
>>>> (i.e software only) mode of operation. Lowering the cost of deployment
>>>> for organisations that want sensible key management without the expense
>>>> of deploying multi-site HSMs.
>>>>
>>>> * Vault supports HSM deployments also
>>>>
>>>> [1] http://docs.openstack.org/developer/castellan/
>>>> [2] https://www.vaultproject.io/
>>> The last I checked, Rob, they also support DogTag IPA which is purely
>>> a Software based HSM. Hopefully the Barbican team can confirm this.
>>> --
>>> Ian Cordasco
>> Yep.  Barbican supports four backend secret stores. [1]
>>
>> The first (Simple Crypto) is easy to deploy, but not extraordinarily
>> secure, since the secrets are encrypted using a static key defined in the
>> barbican.conf file.
>>
>> The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
>> a hardware base to encrypt and/or store the secrets.
>> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
>> encrypt and store the secrets.
>>
>> We do not currently have a secret store that is both highly secure and
>> easy to deploy/manage.
>>
>> We, the Barbican community, are very open to any ideas, blueprints, or
>> patches on how to achieve this.
>> In any of the homegrown per-project secret stores, has a solution been
>> developed that solves both of these?
>>
>>
>> [1]
>> http://docs.openstack.org/project-install-guide/key-manager/draft/barbican-
>> backend.html
> The above list of four backend secret stores, each with serious drawbacks is the reason why Barbican has not been widely adopted. Other projects are reluctant to depend on Barbican because it’s not present in most clouds. Magnum, for example believed that using Barbican for certificate storage was the correct design, and we implemented our solution such that it required Barbican. We quickly discovered that it was hurting Magnum’s adoption by multiple cloud operators that were reluctant to add the Barbican service in order to add Magnum. So, we built internal certificate storage to decouple Magnum from Barbican. It’s even less secure than using Barbican with Simple Crypto, but it solved our adoption problem. Furthermore, that’s how most clouds are using Magnum, because they still don’t run Barbican.
>
> Bottom line: As long as cloud operators have any reluctance to adopt Barbican, other community projects will avoid depending on it, even when it’s the right technical solution.
>
> Regards,
>
> Adrian
>
> __________________________________________________________________________
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------