Open Stack

On 10/13/2014 06:21 PM, Preston L. Bannister wrote:
> 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?
Keystone trusts are User to User delegations appropriate for long 
running tasks.  So, yeah, should work for these use cases.

>
> (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 
> <mailto: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
>         <mailto: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
>     <mailto: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/20141014/e353d2fc/attachment.html>