<p dir="ltr">The "single master token" issue is something I think a lot of services may suffer from, and it's definitely something the Barbican folks are aware of (I've made it a point to personally bring this up many times, including hijacking parts of the keystone and barbican sessions at the Tokyo, Austin, and Barcelona summits). When ACLs work, they should do this job,  but there should also be better ways to do this. I know there have been proposals around using more tightly scoped Trusts (I participated in proposing some) but I don't know how much traction they actually got.</p>
<p dir="ltr">Yes, currently Barbican does both secret storage and certificate provisioning, though I'm certain that basic secret storage was fully implemented before any of the certificate stuff ever happened… I believe you are correct though that it should be more tightly focused, and I think the Barbican team agrees as well -- to my (admittedly fuzzy) recollection there was agreement to split the certificate provisioning system into another project as of version two of the API. Maybe Dave or Doug can confirm this?</p>
<p dir="ltr">And for the record, Neutron-LBaaS and Octavia have at least a soft requirement for Barbican, which is to say we only support our TLS Termination features if Barbican is deployed. We do have our own Castellan-like interface, but it only has a Barbican driver, and we'd love to have that interface merged with Castellan if possible (I'm still salty that this didn't happen years ago, but that's a much longer story).</p>
<p dir="ltr">    --Adam Harwell</p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 16, 2017, 14:36 Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">To give a totally different prospective on why somebody might dislike Barbican (I'm one of those people). Note that I'm working from pretty hazy memories so I don't guarantee I've got everything spot on, and I am without a doubt giving a very one sided view. But hey, that's the side I happen to sit on. I certainly don't mean to cause great offence to the people concerned, but rather to give  ahistory from a PoV that hasn't appeared yet.<br class="gmail_msg"><br class="gmail_msg"></div>Cinder needed somewhere to store volume encryption keys. Long, long ago, Barbican gave a great presentation about secrets as a service, ACLs on secrets, setups where one service could ask for keep material to be created and only accessible to some other service. Having one service give another service permission to get at a secret (but never be able to access that secret itself). All the clever things that cinder could possibly leverage. It would also handle hardware security modules and all of the other craziness that no sane person wants to understand the fine details of. Key revocation, rekeying and some other stuff was mentioned as being possible future work.<br class="gmail_msg"><br class="gmail_msg"></div>So I waited, and I waited, and I asked some security people about what Barbican was doing, and I got told it had gone off and done some unrelated to anything we wanted certificate cleverness stuff for some other service, but secrets-as-a-service would be along at some point. Eventually, a long time after all my enthusiasm had waned, the basic feature<br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">It doesn't do what it says on the tin. It isn't very good at keeping secrets. If I've got a token then I can get the keys for all my volumes. That kind of sucks. For several threat models, I'd have done better to just stick the keys in the cinder db.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I really wish I'd got a video of that first presentation, because it would be an interesting project to implement. Barbican though, from a really narrow focused since usecase view point really isn't very good though.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(If I've missed something and Barbican can do the clever ACL type stuff that was talked about, please let me know - I'd be very interested in trying to fit it to cinder, and I'm not even working on cinder professionally currently.)<br class="gmail_msg"></div></div>
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div>