Open Stack

Excerpts from Zane Bitter's message of 2015-01-29 08:41:36 -0800:
> 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.
> 
> 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 think you got that a little backward. Keystone lets you have domains
that are read/write, and domains that are read-only. So you can have
"the real users" in LDAP and then give a different class of user their
own keystone-only domain that they can control.

That is a bit confusing to the real functionality gap, which I think
is a corner case but worth exploring. Being able to create a user in a
domain that the user provides credentials for is a useful thing. A user
may want to deploy their own instance control mechanism (like standalone
Heat!) for instance, and having a limited-access user for this created
by a domain admin with credentials that are only ever stored in Heat
seems like a win. Some care is needed to make sure the role can't just
'stack show' on Heat and grab the admin creds, but that seems like
something that would go in a deployer guide.. something like "Make sure
domain admins know not to give delegated users the 'heat-user' role."

> 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.
> 

I feel like admin-only things will matter as soon as real multi-cloud
support exists in Heat. What I really want is to have a Heat in my
management cloud that reaches into my managed cloud when necessary.
Right now in TripleO we have to keep anything admin-only out of the
Heat templates and run the utilities from os-cloud-config "somewhere"
because we don't want admin credentials (even just trusts) in Heat. But
if we could use the deployment(under) cloud's Heat to reach into the
user(over) cloud to add users, roles, networks, etc., then that would
maintain the separation our security auditors desire.