Open Stack

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/

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

So essentially I think you should be fine configuring heat like this if you
wish.

Steve