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", 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).  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 __________________________________________________________________________ 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