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/ On Mon, Jan 16, 2017 at 4:14 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > -----Original Message----- > From: Hayes, Graham <graham.ha...@hpe.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: January 16, 2017 at 09:26:00 > 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? > > > On 16/01/2017 13:38, Ian Cordasco wrote: > > > Is the problem perhaps that no one is aware of other projects using > > > Barbican? Is the status on the project navigator alarming (it looks > > > like some of this information is potentially out of date)? Has > > > Barbican been deemed too hard to deploy? > > > > I know that historically it was considered hard to do a HA deploy of > > Barbican. When we initially evaluated DNSSEC in Designate (many years > > ago now) it was one of the sticking points. > > > > This may have (and most likely has) changed, but we seem to have long > > memories. > > I know Rackspace recently made Barbican available to its cloud > customers. I suspect it's easier now to perform an HA deploy. > > > It could be a side effect of the Big Tent - there are so many projects > > doing so many different things that projects don't want deployers to > > have deploy everything. > > Yeah, I completely understand that. The thing is that in one case, > there's a project that currently relies on Barbican and wants to > replace that with a completely brand new service that will be doing > other things and then wants to layer secrets on top of it. It seems to > me like a terrible case of both scope creep and not actually caring > about the security the users expect from services that have to > interact with secrets. N services (besides Barbican) implementing > their own secrets storage each in their own way seem like N different > services that will be dealing with vulnerabilities and security > releases for the next few years. Perhaps that's pessimistic, but > looking at that with my operator hat on, I'd rather have to update *1* > service (barbican) rather than N if there's some vulnerability that > comes up. It's the same argument when it comes down to packaging and > vendoring dependencies. Update once instead of N times for each > package that has a copy of the library bundled in it. > > > > I really want to understand why so many projects feel the need to > > > implement their own secrets storage. This seems a bit short-sighted > > > and foolish. While these projects are making themselves easier to > > > deploy, if not done properly they are potentially endangering their > > > users and that seems like a bigger problem than deploying Barbican to > > > me. > > > > +100 - One of the reasons we didn't just write our own signing was I > > am allergic to writing crypto code - I am not very good at it, and there > > is a project that people that either are, or know how to use the libs > > correctly. > > I have the same allergy! This is why I've been pushing folks talking > about implementing their own secrets storage. > > -- > Ian Cordasco > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
