Open Stack

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