Open Stack

On Tue, Sep 03, 2013 at 06:12:00PM -0500, Dolph Mathews wrote:
> On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy <shardy at redhat.com> wrote:
> 
> > Hi,
> >
> > I have a question for the keystone folks re the expected behavior when
> > deleting a trust.
> >
> > Is it expected that you can only ever delete a trust as the user who
> > created it, and that you can *not* delete the trust when impersonating that
> > user using a token obtained via that trust?
> >
> 
> We have some tests in keystone somewhat related to this scenario, but
> nothing that asserts that specific behavior-
> 
> https://github.com/openstack/keystone/blob/master/keystone/tests/test_auth.py#L737-L763
> 
> 
> > The reason for this question, is for the Heat use-case, this may represent
> > a significant operational limitation, since it implies that the user who
> > creates the stack is the only one who can ever delete it.
> >
> 
> I don't follow this implication-- can you explain further? I don't see how
> the limitation above (if it exists) would impact this behavior or be a
> blocker for the design below.

As outlined already by Clint, the way Heat uses trusts is:

- User requests stack creation, passes token or user/password to Heat
- Heat uses the user credentials to create a trust between the user and the
  Heat service user, the ID of which is encrypted and stored in our DB
  (instead of the credentials)
- We use the trust to perform lifecycle operations, e.g adding a nova
  instance to an AutoScalingGroup, the Heat service user impersonates the
  User who created the stack
- The user deletes the stack, at which point we delete the trust

This final step is the problematic step - atm (unless I'm making a mistake,
which as previously proven is entirely possible! ;) it seems that it's
impossible for anyone except the trustor to delete the trust, even if we
impersonate the trustor.

Even a tenant admin, it seems, cannot delete the trust.

> > Current Heat behavior is to allow any user in the same tenant, provided
> > they have the requisite roles, to delete the stack
> 
> 
> That seems like a reasonable design. With trusts, any user who has been
> delegated the requisite role on the same tenant should be able to delete
> the stack.

If this is the case, I'd very much like to see some curl examples of this
working, in particular these two scenarios:

- Deleting a trust by impersonating the trustor (using a token obtained
  with the trust you're about to delete, which will obviously be
  invalidated as soon as the delete completes)

- Any user other than the trustor deleting the trust, e.g some other user
  in the same tenant

I'll create some minimal reproducers to try to illustrate the issue.

> > which AFAICT atm will
> > not be possible when using trusts.
> >
> Similar to the above, I don't understand how trusts presents a blocker?

Hopefully the above clarifies, we will either leak trusts or have to assert
failure on stack delete unless we can delete the trust on behalf of the
stack-creating (trustor) user in the case where some other user in the
tenant performs the stack delete.

Thanks for any further info you can provide! :)

Steve