Open Stack

On 03/31/2015 10:58 PM, Marc Heckmann 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.

Kerberos.  Works well for Keystone.

http://adam.younglogic.com/2014/07/kerberos-for-horizon-and-keystone/

We are working on Kerberos support for Horizon as well, but we might not 
get it blessed by Kilo time frame.


I think there might be a better approach on the Horizon front using SSSD 
and Federation:

http://adam.younglogic.com/2015/03/key-fed-lookup-redux/

That will likely work with Horizon as is (in Kilo) but I have not yet 
tested it...doing so is on my short list.

What CERN is doing is using SAML for everything, and using ADFS with a 
discovery page to let you use X509, Kerberos, or Password to get a SAML 
assertion, and then handing that over to Horizon.


SAML against Keystone CLI wise requires ECP support on the SAML 
side...you've been warned,.



>
> 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