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