Open Stack

On 01/30/2015 02:19 AM, Thomas Spatzier wrote:
>> From: Zane Bitter <zbitter at redhat.com>
>> To: openstack Development Mailing List
> <openstack-dev at lists.openstack.org>
>> Date: 29/01/2015 17:47
>> Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in
> Heat
>> 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 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.
>>
>> Thoughts?
> I am really not a keystone expert,
I am!  But when I grow up, I want to be a fireman!
> so don't know what the security
> implications would be, but I have heard the requirement or wish to be able
> to create users, roles etc. from a template many times.
SHould be possible.  LDAP can be read only, but these things can all go 
into SQL, and just have a loose coupling with the LDAP entities.


> I've talked to
> people who want to explore this for onboarding use cases, e.g. for
> onboarding of lines of business in a company, or for onboarding customers
> in a public cloud case. They would like to be able to have templates that
> lay out the overall structure for authentication stuff, and then
> parameterize it for each onboarding process.

THose domains, users, projects ,etc would all go intop SQL.  THe only 
case ot use LDAP would be if their remote organization already had an 
LDAP system that contained users, and the4y wanted to reuse it.  There 
are issues, there, and I suspect Federation (SAML) will be the mechanism 
of choice for these types of integrations, not LDAP.

> If this is something to be enabled, that would be interesting to explore.
>
> Regards,
> Thomas
>
>> cheers,
>> Zane.
>>
>>
> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev