On Wed, Apr 1, 2015 at 1:17 AM, Daniel Comnea <comnea.d...@gmail.com> wrote:
> + developers mailing list, hopefully a developer might be able to chime in. > > > > On Wed, Apr 1, 2015 at 3:58 AM, Marc Heckmann <marc.heckm...@ubisoft.com> > wrote: > >> 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 >> > The solution for this in keystone is to use domain-specific drivers. The only documentation on it I can find is in the developer docs -- http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers -- like a lot of keystone features, it hasn't made it to the admin guide. To give an idea how it works, you have a domain for service users which is local in SQL, and a separate domain for regular users which uses LDAP. - Brant
__________________________________________________________________________ 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
