I would consider that to be something that spans further than just barbican and keystone. The ability to restrict a token to a single service/operation/resource is a super interesting problem especially when you start to consider operational dependencies between the services. If the approach spans multiple service (which in this case I think it would need to since it seems closely related to policy) communication gaps will only make achieving it harder. I think Sean nailed it with his comment about championing an effort across projects and closing communication gaps. We are currently doing this on a smaller scale with the horizon team to smooth out issues between horizon and keystone based on a set of things discussed in Barcelona . It's seems to be proving successful for both teams.
I'd love to set aside some time to get a discussion rolling in Atlanta about this.  http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting On Tue, Jan 17, 2017 at 10:55 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > Is this a Barbican problem or a Keystone one? The inability to restrict a > token to go only to one service but instead any hacked service can be used > to get tokens that can be used on any other service seems to to me to be a > more general Keystone architectural problem to solve? > > Thanks, > Kevin > ------------------------------ > *From:* Duncan Thomas [duncan.tho...@gmail.com] > *Sent:* Tuesday, January 17, 2017 6:04 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [all] [barbican] [security] Why are > projects trying to avoid Barbican, still? > > > > On 17 January 2017 at 13:41, Dave McCowan (dmccowan) <dmcco...@cisco.com> > wrote: > >> >> 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 . 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. >> > > Sure, cinder can add a secret and nova can retrieve it. But glance can > *also* retrieve it. So can trove. And any other service that gets a normal > keystone token from the user (i.e. just about all of them). This is, for > some threat models, far worse that the secret being nice and safe int he > cinder DB and only ever given out to nova via a trusted API path. The > original design vision I saw for barbican was intended to have much better > controls than this, but they never showed up AFAIK. And that's just the > problem - people think 'Oh, barbican is storing the cinder volume secrets, > great, we're secure' when actually barbican has made the security situation > worse not better. It's a pretty terrible secrets-as-a-service product at > the moment. Fixing it is not trivial. > > -- > Duncan Thomas > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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