Open Stack

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 [0]. 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.


[0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

On Tue, Jan 17, 2017 at 10:55 AM, Fox, Kevin M <Kevin.Fox at 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.thomas at 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) <dmccowan at 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 [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.
>>
>
> 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-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/20170117/e3650ad6/attachment.html>