On 8 September 2014 19:33, Steven Hardy <sha...@redhat.com> wrote: > On Mon, Sep 08, 2014 at 11:11:07AM +1000, Kieran Spear wrote: >> Hi, >> >> I'm looking at configuring our Heat deployment to use trusts as the >> deferred auth method. The requirement to grant each user the >> heat_stack_owner role (or similar) makes things a bit awkward, since >> we allow users to grant each other membership within a project and >> don't want them to have to worry about specific roles for different >> services. >> >> I'm considering just setting: >> >> trusts_delegated_roles=member >> >> But I'm wondering if there are any security implications in doing this >> that I haven't considered? Obviously we'd lose the ability to restrict >> exactly what Heat can do with this trust, but it seems like this is >> still a better alternative than not using trusts at all? > > As it happens, I posted a patch last week which will make the heat default > exactly what you describe: > > https://review.openstack.org/#/c/119415/
Ah, great. It does seem like a more sensible default. > > The only downsides I'm aware of: > > - Some residual confusion between _member_ and Member roles, also I'm not > sure if this is necessarily going to be the same in all environments, but > I'm assuming aligning with the keystone.conf default role name is sane. > > - My testing indicates the user only gets the _member_ role if created via > the v2 Keystone API : https://bugs.launchpad.net/keystone/+bug/1366133 Interesting. IIRC, _member_ was added to handle the implicit role grant in v2 when a user's default project is changed. There's a config option to specify which particular role is granted in this case. The implicit grant was removed in v3 though, so you need to explicitly grant the user the role on the project in that case. > > So essentially I think you should be fine configuring heat like this if you > wish. Great, thanks! Kieran > > Steve > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
