Open Stack

Someone mentioned Castellan, and was exactly correct -- Castellan is
supposed to allow for flexibility, so developers can code for the Castellan
interface and simply configure it to use Barbican or whatever else they
want.

The only drawback of Castellan at the moment is that it doesn't directly
support certificate storage (that is, if you are using groupings of
cert/intermediates/PK, they have to be stored individually). Otherwise,
using that interface would make it very easy to allow use of Barbican for
any clouds that deploy it, and something else (maybe even a *common*
something simple) otherwise (though I am fully behind just using Barbican).

   --Adam Harwell (LBaaS/Octavia)

On Mon, Jan 16, 2017, 11:57 Adrian Otto <adrian.otto at rackspace.com> wrote:

>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170116/2ed2c8b0/attachment-0001.html>