<div dir="ltr">Too-short token expiration times are one of my concerns, in my current exercise. <div><br></div><div>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).</div><div><br></div><div>Had not run into mention of "trusts" before. Is the intent to cover this sort of use-case?</div><div><br></div><div>(Pulled up what I could find on "trusts". Need to chew on this a bit, as it is not immediately clear if this fits.)<br><br><br><br> </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 6:53 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/01/2014 04:14 AM, Steven Hardy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is keeping us from dropping the (scoped) token duration to 5 minutes?<br>
<br>
<br>
If we could keep their lifetime as short as network skew lets us, we would<br>
be able to:<br>
<br>
Get rid of revocation checking.<br>
Get rid of persisted tokens.<br>
<br>
OK, so that assumes we can move back to PKI tokens, but we're working on<br>
that.<br>
<br>
What are the uses that require long lived tokens? Can they be replaced with<br>
a better mechanism for long term delegation (OAuth or Keystone trusts) as<br>
Heat has done?<br>
</blockquote>
FWIW I think you're misrepresenting Heat's usage of Trusts here - 2 minute<br>
tokens will break Heat just as much as any other service:<br>
<br>
<a href="https://bugs.launchpad.net/heat/+bug/1306294" target="_blank">https://bugs.launchpad.net/<u></u>heat/+bug/1306294</a><br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/045585.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>September/045585.html</a><br>
<br>
<br>
Summary:<br>
<br>
- Heat uses the request token to process requests (e.g stack create), which<br>
may take an arbitrary amount of time (default timeout one hour).<br>
<br>
- Some use-cases demand timeout of more than one hour (specifically big<br>
TripleO deployments), heat breaks in these situations atm, folks are<br>
working around it by using long (several hour) token expiry times.<br>
<br>
- Trusts are only used of asynchronous signalling, e.g Ceilometer signals<br>
Heat, we switch to a trust scoped token to process the response to the<br>
alarm (e.g launch more instances on behalf of the user for autoscaling)<br>
<br>
My understanding, ref notes in that bug, is that using Trusts while<br>
servicing a request to effectively circumvent token expiry was not legit<br>
(or at least yukky and to be avoided). If you think otherwise then please<br>
let me know, as that would be the simplest way to fix the bug above (switch<br>
to a trust token while doing the long-running create operation).<br>
</blockquote></div></div>
Using trusts to circumvent timeout is OK. There are two issues in tension here:<br>
<br>
1. A user needs to be able to maintain control of their own data.<br>
<br>
2. We want to limit the attack surface provided by tokens.<br>
<br>
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.<br>
<br>
<br>
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?<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Trusts is not really ideal for this use-case anyway, as it requires the<br>
service to have knowledge of the roles to delegate (or that the user<br>
provides a pre-created trust), ref bug #1366133. I suppose we could just<br>
delegate all the roles we find in the request scope and be done with it,<br>
given that bug has been wontfixed.<br>
<br>
Steve<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>