Open Stack

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.

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?

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

    --Adam Harwell

On Mon, Jan 16, 2017, 14:36 Duncan Thomas <duncan.thomas at gmail.com> wrote:

> 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.
>
> 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.
>
> 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
>
> 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.
>
> 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.
>
> (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.)
> __________________________________________________________________________
> 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/ac442919/attachment.html>