Open Stack

On Wed, Apr 1, 2015 at 1:17 AM, Daniel Comnea <comnea.dani at 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.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
>>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150401/c5028b1a/attachment.html>