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 <ayo...@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 >> OpenStackemail@example.com >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev