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