On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
>-----Original Message----- >From: Rob C <hyaku...@gmail.com> >Reply: OpenStack Development Mailing List (not for usage questions) ><openstack-dev@lists.openstack.org> >Date: January 16, 2017 at 10:33:20 >To: OpenStack Development Mailing List (not for usage questions) ><openstack-dev@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
