Open Stack

On Wed, Aug 7, 2013 at 8:23 PM, Jarret Raim <jarret.raim at rackspace.com> wrote:
> Judging from the description, this commit just seems to remove the tokens
> from Keystone? If the product has cached the token and auth response, the
> token would still work?

indeed, those tokens are memcached only by default for 5 minutes :

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L263

which is way better than the 24 hours with the token (which is what
this patch address).

There is not much way currently to clear the cached token globally.

Having an external service that does the token clearing (and at the
same time doing the resource scrubbing when a project is removed)
could be the long term solution like you have I guess at Rackspace.

>>Do you find it a lot of work to have the various projects polling?
> Not really. We have Repose sitting in front of a lot of services (20+) so
> we only really implemented it a couple of times.
> From a performance standpoint, it's pretty light-weight. ATOM is hugely
> cacheable and even with 5000+ Rackers, the feed doesn't change quickly.

Is that used only for internal employees (i.e: rackers) or as well for
the public cloud?
Is it something opensourcable?

Cheers,
Chmouel.

>
>>
>>> -----Original Message-----
>>> From: Jarret Raim [mailto:jarret.raim at RACKSPACE.COM]
>>> Sent: 07 August 2013 13:42
>>> To: Clark, Robert Graham; openstack-security at lists.openstack.org
>>> Subject: Re: [Openstack-security] [OSSN][DRAFT] Disabling a tenant
>>does
>>> not disable a user token
>>>
>>> At Rackspace, we've attempted to mitigate this be requiring products
>>that
>>> want to cache user tokens to listen to an ATOM feed that our identity
>>> system exposes that tracks user state changes. When a tenant is
>>disabled, a
>>> message appears on the ATOM feed, which the products use to invalidate
>>> the cache entry.
>>>
>>> It's not super great (ATOM is still polling), but it does allow some
>>guarantee
>>> that an existing token will get revoked within x minutes from
>>invalidation,
>>> usually less than 5.
>>>
>>>
>>> I think this functionality is build into repose, our rest proxy. It's
>>open source
>>> if people want to poke at it:
>>>
>>> http://openrepose.org/
>>>
>>>
>>>
>>> Jarret
>>>
>>>
>>>
>>>
>>> On 8/7/13 7:33 AM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:
>>>
>>> >[DRAFT] - Please Review
>>> >Disabling a tenant does not disable a user token
>>> >----
>>> >
>>> >### Summary ###
>>> >When a tenant is disabled in Keystone, tokens that have been issued
>>to
>>> >that tenant are not invalidated. This can result in users having
>>access
>>> >to your cloud after you have attempted to revoke them.
>>> >
>>> >### Affected Services / Software ###
>>> >Keystone
>>> >
>>> >### Discussion ###
>>> >It appears that Keystone does not purge the tokens given out to
>>tenants
>>> >when a tenant is disabled. In some scenarios this could be very
>>> >important to cloud providers. Take the case where a cloud provider
>>must
>>> >a tenant's access because of some legal investigation. Even though
>>the
>>> >tenant is disabled it would be possible for them to terminate VMs /
>>> >delete Swift files etc. - There are many other abuse-cases...
>>> >
>>> >### Recommended Actions ###
>>> >How the tokens are stored depends on your cloud deployment. If you
>>> >deploy using Memcache to back Keystone then flushing the cash when
>>> >disabling a token would resolve this issue for you, at the cost of
>>> >other token lookups which are no longer in the cash requiring
>>Keystone
>>> >interaction.
>>> >
>>> >It is of course possible to script something to remove tokens from
>>any
>>> >backend DB or cache but there is no 'official' way to do this.
>>> >
>>> >### Contacts / References ###
>>> >Proposed Fix : https://review.openstack.org/#/c/39878/
>>> >This OSSN : https://bugs.launchpad.net/ossn/+bug/1179955
>>> >OpenStack Security ML : openstack-security at lists.openstack.org
>>> >OpenStack Security Group : https://launchpad.net/~openstack-ossg
>>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security