Open Stack

+ 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
> >>
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150401/29ab4288/attachment.html>