Open Stack

Hi Angus,

On Wed, May 28, 2014 at 12:56:52AM +0000, Angus Salkeld wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all
> 
> During our Solum meeting it was felt we should make sure that all three
> team are on the same page wrt $subject.
> 
> I'll describe the use case we are trying to solve and hopefully get some
> guidance from the keystone team about the best way forward.
> 
> Solum implements a ci/cd pipeline that we want to trigger based on a git
> receive hook. What we do is generate a magic webhook (should be
> ec2signed url - on the todo list) and when it is hit we want
> to call mistral-execution-create (which runs a workflow that calls
> to other openstack services (heat is one of them).
> 
> We currently use a trust token and that fails because both mistral and
> heat want to create trust tokens as well :-O (trust tokens can't be
> rescoped).

So, I've been looking into this, and there are two issues:

1. On stack-create, heat needs to create a trust so it can do deferred
operation on behalf of the user.  To do this we will require explicit
support for chained delegation in keystone, which does not currently exist.
I've been speaking to ayoung about it, and plan to raise a spec for this
work soon.  The best quick-fix is probably to always create a stack when
the user calls Solum (even if it's an empty stack), using their
non-trust-scoped token.

2. Heat doesn't currently work (even for non-create operations) with a
trust-scoped token.  The reason for this is primarily that keystoneclient
always tries to request a new token to populate the auth_ref (e.g service
catalog etc), so there is no way to just validate the existing trust-scoped
token.  AFAICS this requires a new keystoneclient auth plugin, which I'm
working on right now, I already posted a patch for the heat part of the
fix:

https://review.openstack.org/#/c/96452/

> 
> So what is the best mechanism for this? I spoke to Steven Hardy at
> summit and he suggested (after talking to some keystone folks) we all
> move to using the new oauth functionality in keystone.
> 
> I believe there might be some limitations to oauth (are roles supported?).

I spent a bit of time digging into oauth last week, based on this example
provided by Steve Martinelli:

https://review.openstack.org/#/c/80193/

Currently, I can't see how we can use this as a replacement for our current
use-cases for trusts:
1. There doesn't seem to be any non-global way to prevent oauth accesskeys
from expiring.  We need delegation to last the (indefinite) lifetime of the
heat stack, so the delegatation cannot expire.
2. Most (all?) of the oauth interfaces are admin-only.  I'm not clear if
this is a blocker, but it seems like it's the opposite of what we currently
do with trusts, where a (non-admin) user can delegate a subset of their
roles via a trust, which is created using their token.

What would be *really* helpful, is if we could work towards another
example, which demostrates something closer to the Solum/Heat use-case for
delegation (as opposed to the current example which just shows an admin
delegating their admin-ness).

e.g (these users/roles exist by default in devstack deployments):

1. User "demo" delegates "heat_stack_owner" role in project "demo" to the
"heat" service user.  The resulting delegation-secret to be stored by heat
must not expire, and it must be possible for the "heat" user to explicitly
impersonate user "demo".

Until we can see how that use-case can be solved with oauth, I don't think
we can make any progress on actually adopting it.

The next part of the use-case would be working out how either a delegation
secret can be shared between services (e.g Solum/Heat), or how delegation
can be chained between services, but the first thing is working out the
basic user->service delegation model IMO.

Thanks,

Steve