+1 Thanks Steven for pointing out the pitfall.
Best regards, Hongbin -----Original Message----- From: Steven Hardy [mailto:sha...@redhat.com] Sent: December-23-15 3:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack][magnum]a problem about trust On Tue, Dec 22, 2015 at 04:55:17PM +0800, 王华 wrote: > Hi all, > When we create a trust to a trustee with a role, the trustor must have > this role. Here is a problem I meet in my bp [1]. I need to create a trust > with a role, with the trust docker registry can access Swift to store > images. But the trustor (the user who uses magnum) may not have the role. > How can we address this problem? FYI we had this exact same issue in Heat some time ago: https://bugs.launchpad.net/heat/+bug/1376562 > There are two ways. > 1. Add the role to the trustor with the magnum admin user privilege. But > when we need to delete the role, we can not know whether the role is added > by magnum or is owned by the trustor. > 2. Let magnum trust the trustee with the role. We can assign the role to > magnum before we start magnum. As you'll see from the bug report above, neither of these solutions work, because you can't know at the point of delegation what roles may be needed in the future when impersonating the trustor. So, having a special role which is always delegated (as you are proposing, and Heat used to do) doesn't work very well in environments where RBAC is actually used. The solution we reached in Heat is to delegate all roles, as determined by keystone/authtoken, with the option for deployers to specify some specific role or list of roles if they have an RBAC scheme where the expected roles are predictable: See https://review.openstack.org/128509 for the Heat solution. HTH! Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
