Open Stack

On 10/01/2014 04:14 AM, Steven Hardy wrote:
> On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:
>> What is keeping us from dropping the (scoped) token duration to 5 minutes?
>>
>>
>> If we could keep their lifetime as short as network skew lets us, we would
>> be able to:
>>
>> Get rid of revocation checking.
>> Get rid of persisted tokens.
>>
>> OK,  so that assumes we can move back to PKI tokens, but we're working on
>> that.
>>
>> What are the uses that require long lived tokens?  Can they be replaced with
>> a better mechanism for long term delegation (OAuth or Keystone trusts) as
>> Heat has done?
> FWIW I think you're misrepresenting Heat's usage of Trusts here - 2 minute
> tokens will break Heat just as much as any other service:
>
> https://bugs.launchpad.net/heat/+bug/1306294
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/045585.html
>
>
> Summary:
>
> - Heat uses the request token to process requests (e.g stack create), which
>    may take an arbitrary amount of time (default timeout one hour).
>
> - Some use-cases demand timeout of more than one hour (specifically big
>    TripleO deployments), heat breaks in these situations atm, folks are
>    working around it by using long (several hour) token expiry times.
>
> - Trusts are only used of asynchronous signalling, e.g Ceilometer signals
>    Heat, we switch to a trust scoped token to process the response to the
>    alarm (e.g launch more instances on behalf of the user for autoscaling)
>
> My understanding, ref notes in that bug, is that using Trusts while
> servicing a request to effectively circumvent token expiry was not legit
> (or at least yukky and to be avoided).  If you think otherwise then please
> let me know, as that would be the simplest way to fix the bug above (switch
> to a trust token while doing the long-running create operation).
Using trusts to circumvent timeout is OK.  There are two issues in 
tension here:

1.  A user needs to be able to maintain control of their own data.

2.  We want to limit the attack surface provided by tokens.

Since tokens are currently blanket access to the users data, there 
really is no lessening of control by using trusts in a wider context.  
I'd argue that using trusts would actually reduce the capability for 
abuse,if coupled with short lived tokens. With long lived tokens, anyone 
can reuse the token.  With a trust, only the trustee would be able to 
create a new token.


Could we start by identifying the set of operations that are currently 
timing out due to the one hour token duration and add an optional 
trustid on those operations?


>
> Trusts is not really ideal for this use-case anyway, as it requires the
> service to have knowledge of the roles to delegate (or that the user
> provides a pre-created trust), ref bug #1366133.  I suppose we could just
> delegate all the roles we find in the request scope and be done with it,
> given that bug has been wontfixed.
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev