Open Stack

We create "service accounts" in AD, for teams to use inside scripts or within services.  We have an home built solution to prevent credentials from being stored in clear text on the server and allow for password rotation of the service accounts without service interruption.




On 8/29/15, 9:49 AM, "Marc Heckmann" <marc.heckmann at 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 <matt at 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é <mgagne at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators