Open Stack

Too-short token expiration times are one of my concerns, in my current
exercise.

Working on a replacement for Nova backup. Basically creating backups jobs,
writing the jobs into a queue, with a background worker that reads jobs
from the queue. Tokens could expire while the jobs are in the queue (not
too likely). Tokens could expire during the execution of a backup (while
can be very long running, in some cases).

Had not run into mention of "trusts" before. Is the intent to cover this
sort of use-case?

(Pulled up what I could find on "trusts". Need to chew on this a bit, as it
is not immediately clear if this fits.)








On Wed, Oct 1, 2014 at 6:53 AM, Adam Young <ayoung at redhat.com> wrote:

> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20141013/61131a94/attachment.html>