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