Sorry for the repost, it seems this mail was in the outbox of another machine that I hadn't turned on in a while.
Please ignore. > On Aug 29, 2015, at 11:56, 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 >>> >>> _______________________________________________ >>> 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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
