From: Duncan Thomas <duncan.tho...@gmail.com<mailto:duncan.tho...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, January 16, 2017 at 5:33 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?
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.) I don't know everything that was proposed in the Juno timeframe, or before, but the Nova and Cinder integration has been done now. The documentation is at [1]. A cinder user can create an encryption key through Barbican when creating a volume, then the same user (or a user with permissions granted by that user), as a nova user, can retrieve that key when mounting the encrypted volume. [1] http://docs.openstack.org/mitaka/config-reference/block-storage/volume-encryption.html
__________________________________________________________________________ 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
