> 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.
For issue #2, I think you're right, we should probably make the oauth interfaces https://github.com/openstack/keystone/blob/master/etc/policy.json#L109..L114 have the same policy as the trust ones, (user_id:%(trust.trustor_user_id)s).
#1 is a bit more work, it would definitely be a new blueprint.
I'll see what I can do about providing a more realistic example.
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
|
| |
| Phone:
1-905-413-2851 E-mail: steve...@ca.ibm.com |
8200 Warden Ave Markham, ON L6G 1C7 Canada |
Steven Hardy <sha...@redhat.com> wrote on 06/02/2014 06:41:48 AM:
> From: Steven Hardy <sha...@redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>,
> Date: 06/02/2014 06:43 AM
> Subject: Re: [openstack-dev] [solum] [mistral] [heat] keystone
> chained trusts / oauth
>
> 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
> 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
