<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/13/2014 06:21 PM, Preston L.
Bannister wrote:<br>
</div>
<blockquote
cite="mid:CA+R0NjZfk4SoJy43qkuhQNtvq+9zLF4S-ypf=pg71MS7t=DLJA@mail.gmail.com"
type="cite">
<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>
</blockquote>
Keystone trusts are User to User delegations appropriate for long
running tasks. So, yeah, should work for these use cases.<br>
<br>
<blockquote
cite="mid:CA+R0NjZfk4SoJy43qkuhQNtvq+9zLF4S-ypf=pg71MS7t=DLJA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://bugs.launchpad.net/heat/+bug/1306294"
target="_blank">https://bugs.launchpad.net/heat/+bug/1306294</a><br>
<br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/045585.html"
target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>