<div dir="ltr"><div><div>Thanks for raising this on the mailing list Ian, I too share some of</div><div>your consternation regarding this issue.</div><div><br></div><div>I think the main point has already been hit on, developers don't want to</div><div>require that Barbican be deployed in order for their service to be</div><div>used.</div><div><br></div><div>The resulting spread of badly audited secret management code is pretty</div><div>ugly and makes certifying OpenStack for some types of operation very</div><div>difficult, simply listing where key management "happens" and what</div><div>protocols are in use quickly becomes a non-trivial operation with some</div><div>teams using hard coded values while others use configurable algorithms</div><div>and no connection between any of them.</div><div><br></div><div>In some ways I think that the castellan project was supposed to help</div><div>address the issue. The castellan documentation[1] is a little sparse but</div><div>my understanding is that it exists as an abstraction layer for</div><div>key management, such that a service can just be set to use castellan,</div><div>which in turn can be told to use either a local key-manager, provided by</div><div>the project or Barbican when it is available.</div><div><br></div><div>Perhaps a miss-step previously was that Barbican made no efforts to</div><div>really provide a robust non-HSM mode of operation. An obvious contrast</div><div>here is with Hashicorp Vault[2] which has garnered significant market</div><div>share in key management because it's software-only* mode of operation is</div><div>well documented, robust and cryptographically sound. I think that the</div><div>lack of a sane non-HSM mode, has resulted in developers trying to create</div><div>their own and contributed to the situation. </div><div><br></div><div>I'd be interested to know if development teams would be less concerned</div><div>about requiring Barbican deployments, if it had a robust non-HSM</div><div>(i.e software only) mode of operation. Lowering the cost of deployment</div><div>for organisations that want sensible key management without the expense</div><div>of deploying multi-site HSMs.</div><div><br></div><div>* Vault supports HSM deployments also</div><div><br></div><div>[1] <a href="http://docs.openstack.org/developer/castellan/">http://docs.openstack.org/developer/castellan/</a> </div><div>[2] <a href="https://www.vaultproject.io/">https://www.vaultproject.io/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 4:14 PM, Ian Cordasco <span dir="ltr"><<a href="mailto:sigmavirus24@gmail.com" target="_blank">sigmavirus24@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">-----Original Message-----<br>
From: Hayes, Graham <<a href="mailto:graham.hayes@hpe.com">graham.hayes@hpe.com</a>><br>
Reply: OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Date: January 16, 2017 at 09:26:00<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are<br>
projects trying to avoid Barbican, still?<br>
<br>
> On 16/01/2017 13:38, Ian Cordasco wrote:<br>
</span><span class="gmail-">> > Is the problem perhaps that no one is aware of other projects using<br>
> > Barbican? Is the status on the project navigator alarming (it looks<br>
> > like some of this information is potentially out of date)? Has<br>
> > Barbican been deemed too hard to deploy?<br>
><br>
> I know that historically it was considered hard to do a HA deploy of<br>
> Barbican. When we initially evaluated DNSSEC in Designate (many years<br>
> ago now) it was one of the sticking points.<br>
><br>
> This may have (and most likely has) changed, but we seem to have long<br>
> memories.<br>
<br>
</span>I know Rackspace recently made Barbican available to its cloud<br>
customers. I suspect it's easier now to perform an HA deploy.<br>
<span class="gmail-"><br>
> It could be a side effect of the Big Tent - there are so many projects<br>
> doing so many different things that projects don't want deployers to<br>
> have deploy everything.<br>
<br>
</span>Yeah, I completely understand that. The thing is that in one case,<br>
there's a project that currently relies on Barbican and wants to<br>
replace that with a completely brand new service that will be doing<br>
other things and then wants to layer secrets on top of it. It seems to<br>
me like a terrible case of both scope creep and not actually caring<br>
about the security the users expect from services that have to<br>
interact with secrets. N services (besides Barbican) implementing<br>
their own secrets storage each in their own way seem like N different<br>
services that will be dealing with vulnerabilities and security<br>
releases for the next few years. Perhaps that's pessimistic, but<br>
looking at that with my operator hat on, I'd rather have to update *1*<br>
service (barbican) rather than N if there's some vulnerability that<br>
comes up. It's the same argument when it comes down to packaging and<br>
vendoring dependencies. Update once instead of N times for each<br>
package that has a copy of the library bundled in it.<br>
<span class="gmail-"><br>
> > I really want to understand why so many projects feel the need to<br>
> > implement their own secrets storage. This seems a bit short-sighted<br>
> > and foolish. While these projects are making themselves easier to<br>
> > deploy, if not done properly they are potentially endangering their<br>
> > users and that seems like a bigger problem than deploying Barbican to<br>
> > me.<br>
><br>
> +100 - One of the reasons we didn't just write our own signing was I<br>
> am allergic to writing crypto code - I am not very good at it, and there<br>
> is a project that people that either are, or know how to use the libs<br>
> correctly.<br>
<br>
</span>I have the same allergy! This is why I've been pushing folks talking<br>
about implementing their own secrets storage.<br>
<br>
--<br>
Ian Cordasco<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>