Open Stack

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. 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