Open Stack

On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote:
> I got a question today about creating keystone users/roles/tenants in Heat
> templates. We currently support creating users via the AWS::IAM::User
> resource, but we don't have a native equivalent.

Note that AWS::IAM::User actually creates a "stack domain user"[1], e.g a
special user inside the "heat" domain, intended to be used primarily for
association with an ec2-keypair (e.g AWS::IAM::AccessKey) so we can do
signed requests via the CFN API from inside instances etc.

So it's not really creating normal keystone users, but Angus and I have
already discused the idea of a native equivalent to this, due to the fact
that all StackUser (engine/stack_user.py) subclasses effectively create a
"hidden" resource which is a keystone user in the heat domain.

I'd definitely support adding a native OS::Heat::StackUser resource,
effectively exposing the stack_user.py code as a resource, and adding
optional "user" properties to all existing StackUser subclasses (e.g all
SignalResponders like ScalingPolicy and SoftwareDeployment).

This would make the creation of the user for signal auth more transparent,
and enable template authors to choose if they want a single user associated
with multiple resources (vs now when we force them to have different users
for every SignalResponder).

[1] http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-2-stack.html

> IIUC keystone now allows you to add users to a domain that is otherwise
> backed by a read-only backend (i.e. LDAP). If this means that it's now
> possible to configure a cloud so that one need not be an admin to create
> users then I think it would be a really useful thing to expose in Heat. Does
> anyone know if that's the case?

I've not heard of that feature, but it's definitely now possible to
configure per-domain backends, so for example you could have the "heat"
domain backed by SQL and other domains containing real human users backed
by a read-only directory.

> I think roles and tenants are likely to remain admin-only, but we have
> precedent for including resources like that in /contrib... this seems like
> it would be comparably useful.

If the requirement is more to enable admins to create any
users/roles/projects in templates rather than the heat domain specifically,
I'd personally have no problem with e.g OS::Keystone::User provided it was
in contrib (as it's going to be admin-only with the default keystone policies).

Steve