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