Hi all,

I was going to post a similar question this evening, so I decided to just 
bounce on Mathieu’s question. See below inline.

> On Mar 31, 2015, at 8:35 PM, Matt Fischer <m...@mattfischer.com> wrote:
> 
> Mathieu,
> 
> We LDAP (AD) with a fallback to MySQL. This allows us to store service 
> accounts (like nova) and "team accounts" for use in Jenkins/scripts etc in 
> MySQL. We only do Identity via LDAP and we have a forked copy of this driver 
> (https://github.com/SUSE-Cloud/keystone-hybrid-backend) to do this. We don't 
> have any permissions to write into LDAP or move people into groups, so we 
> keep a copy of users locally for purposes of user-list operations. The only 
> interaction between OpenStack and LDAP for us is when that driver tries a 
> bind.
> 
> 
> 
>> On Tue, Mar 31, 2015 at 6:06 PM, Mathieu Gagné <mga...@iweb.com> wrote:
>> Hi,
>> 
>> Lets say I wish to use an existing enterprise LDAP service to manage my
>> OpenStack users so I only have one place to manage users.
>> 
>> How would you manage authentication and credentials from a security
>> point of view? Do you tell your users to use their enterprise
>> credentials or do you use an other method/credentials?

We too have integration with enterprise credentials through LDAP, but as you 
suggest, we certainly don’t want users to use those credentials in scripts or 
store them on instances. Instead we have a custom Web portal where they can 
create separate Keystone credentials for their project/tenant which are stored 
in Keystone’s MySQL database. Our LDAP integration actually happens at a level 
above Keystone. We don’t actually let users acquire Keystone tokens using their 
LDAP accounts.

We’re not really happy with this solution, it’s a hack and we are looking to 
revamp it entirely. The problem is that I never have been able to find a clear 
answer on how to do this with Keystone. 

I’m actually quite partial to the way AWS IAM works. Especially the instance 
“role" features. Roles in AWS IAM is similar to TRUSTS in Keystone except that 
it is integrated into the instance metadata. It’s pretty cool. 

Other than that, RBAC policies in Openstack get us a good way towards IAM like 
functionality. We just need a policy editor in Horizon.

Anyway, the problem is around delegation of credentials which are used 
non-interactively. We need to limit what those users can do (through RBAC 
policy) but also somehow make the credentials ephemeral.

If someone (Keystone developer?) could point us in the right direction, that 
would be great.

Thanks in advance.

>> 
>> The reason is that (usually) enterprise credentials also give access to
>> a whole lot of systems other than OpenStack itself. And it goes without
>> saying that I'm not fond of the idea of storing my password in plain
>> text to be used by some scripts I created.
>> 
>> What's your opinion/suggestion? Do you guys have a second credential
>> system solely used for OpenStack?
>> 
>> --
>> Mathieu
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to