On Tue, Sep 03, 2013 at 06:12:00PM -0500, Dolph Mathews wrote: > On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
