Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
If delegation (trusts) were enhanced to be role based, then anyone with the same role as the initial delegator should be able to revoke the delegation regards David On 04/09/2013 05:02, Clint Byrum wrote: Excerpts from Dolph Mathews's message of 2013-09-03 16:12:00 -0700: On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy sha...@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. The way heatclient works right now, it will obtain a trust from keystone, and then give that trust to Heat to use while it is managing the stack. However, if this user was just one user in a team of users who manage that stack, then when the stack is deleted, neither heat, nor the user who is deleting the stack will be able to delete the trust that was given to Heat. This presents an operational hurdle for Heat users, as they will have to have a stack owner user that is shared amongst a team. Otherwise they may be stuck in a situation where the creating user is not available to delete a stack that must be deleted for some reason. Ideally as a final operation with the trust Heat, or the user doing the delete, would be able to use the trust to delete itself. ___ 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
Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
On Tue, Sep 03, 2013 at 06:12:00PM -0500, Dolph Mathews wrote: On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy sha...@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
On Wed, Sep 04, 2013 at 09:49:48AM +0100, Steven Hardy wrote: 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. Ok, apologies, after further testing, it appears I made a mistake and you *can* delete the trust by impersonating the user. The reason for the confusion is there's an odd issue when authenticating the client using a trust_id. If (and only if) the trust has impersonation=True, you *must* specify the endpoint when initialising the client, otherwise we do not get a token, we get a 401. So I misinterpreted the authentication failure as a 401 on delete, because I'd copied some code and changed impersonate from False to True, which changes the required arguments when consuming the trust. Seems like a bug? I've created a gist containing an example which demonstrates the problem: https://gist.github.com/hardys/6435299 I'm not sure if the bug is that the authenticate works without the endpoint when impersonate=False, or that is doesn't when impersonate=True. Thanks! Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
you can always do anything by impersonating the user. This is why impersonation should never be sanctioned david On 04/09/2013 11:45, Steven Hardy wrote: Ok, apologies, after further testing, it appears I made a mistake and you *can* delete the trust by impersonating the user. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy sha...@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. 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. which AFAICT atm will not be possible when using trusts. Similar to the above, I don't understand how trusts presents a blocker? Clarification as to whether this is as-designed or a bug somewhere much appreciated, thanks! Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][heat] Question re deleting trusts via trust token
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? 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. Current Heat behavior is to allow any user in the same tenant, provided they have the requisite roles, to delete the stack, which AFAICT atm will not be possible when using trusts. Clarification as to whether this is as-designed or a bug somewhere much appreciated, thanks! Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Question re deleting trusts via trust token
Excerpts from Dolph Mathews's message of 2013-09-03 16:12:00 -0700: On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy sha...@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. The way heatclient works right now, it will obtain a trust from keystone, and then give that trust to Heat to use while it is managing the stack. However, if this user was just one user in a team of users who manage that stack, then when the stack is deleted, neither heat, nor the user who is deleting the stack will be able to delete the trust that was given to Heat. This presents an operational hurdle for Heat users, as they will have to have a stack owner user that is shared amongst a team. Otherwise they may be stuck in a situation where the creating user is not available to delete a stack that must be deleted for some reason. Ideally as a final operation with the trust Heat, or the user doing the delete, would be able to use the trust to delete itself. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
