Re: [Openstack-operators] Security around enterprise credentials and OpenStack API
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 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é 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
Re: [Openstack-operators] Fwd: [openstack-dev] [release] oslo.messaging 1.8.1
Also, If you are running oslo.messaging 1.8.1 or higher and are wondering why you are no longer seeing notifications from nova. Change notification_driver=nova.openstack.common.notifier.rpc_notifier to notification_driver=messaging and you will start seeing notifications for nova events again. I assume this will apply to other services as well - but we are configured to receive notifications from nova. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 3/25/15, 8:30 AM, "Davanum Srinivas" wrote: >FYI. for those waiting to try oslo.messaging rabbitmq heartbeat support. > >-- dims > >-- Forwarded message -- >From: Doug Hellmann >Date: Wed, Mar 25, 2015 at 10:13 AM >Subject: [openstack-dev] [release] oslo.messaging 1.8.1 >To: "OpenStack Development Mailing List (not for usage questions)" > > > >We are pleased to announce the release of: > >oslo.messaging 1.8.1: Oslo Messaging API > >This is a Kilo-series patch release, fixing several bugs. > >For more details, please see the git log history below and: > >http://launchpad.net/oslo.messaging/+milestone/1.8.1 > >Please report issues through launchpad: > >http://bugs.launchpad.net/oslo.messaging > >Changes in oslo.messaging 1.8.0..1.8.1 >-- > >57fad97 Publish tracebacks only on debug level >b5f91b2 Reconnect on connection lost in heartbeat thread >ac8bdb6 cleanup connection pool return >ee18dc5 rabbit: Improves logging >db99154 fix up verb tense in log message >64bdd80 rabbit: heartbeat implementation >9b14d1a Add support for multiple namespaces in Targets > >Diffstat (except docs and test files) >- > >oslo_messaging/_drivers/amqp.py | 44 ++- >oslo_messaging/_drivers/amqpdriver.py| 15 +- >oslo_messaging/_drivers/impl_qpid.py | 2 +- >oslo_messaging/_drivers/impl_rabbit.py | 346 >--- >oslo_messaging/rpc/dispatcher.py | 2 +- >oslo_messaging/target.py | 9 +- >11 files changed, 541 insertions(+), 70 deletions(-) >__ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >-- >Davanum Srinivas :: https://twitter.com/dims > >___ >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
Re: [Openstack-operators] Fwd: [openstack-dev] [release] oslo.messaging 1.8.1
I hope that in the future https://review.openstack.org/#/c/140318/ can help out making this more obvious; as a good example set that works can be very very helpful to understand why/what the options are... Docs that are good would help to... Kris G. Lindgren wrote: Also, If you are running oslo.messaging 1.8.1 or higher and are wondering why you are no longer seeing notifications from nova. Change notification_driver=nova.openstack.common.notifier.rpc_notifier to notification_driver=messaging and you will start seeing notifications for nova events again. I assume this will apply to other services as well - but we are configured to receive notifications from nova. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 3/25/15, 8:30 AM, "Davanum Srinivas" wrote: FYI. for those waiting to try oslo.messaging rabbitmq heartbeat support. -- dims -- Forwarded message -- From: Doug Hellmann Date: Wed, Mar 25, 2015 at 10:13 AM Subject: [openstack-dev] [release] oslo.messaging 1.8.1 To: "OpenStack Development Mailing List (not for usage questions)" We are pleased to announce the release of: oslo.messaging 1.8.1: Oslo Messaging API This is a Kilo-series patch release, fixing several bugs. For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.8.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.8.0..1.8.1 -- 57fad97 Publish tracebacks only on debug level b5f91b2 Reconnect on connection lost in heartbeat thread ac8bdb6 cleanup connection pool return ee18dc5 rabbit: Improves logging db99154 fix up verb tense in log message 64bdd80 rabbit: heartbeat implementation 9b14d1a Add support for multiple namespaces in Targets Diffstat (except docs and test files) - oslo_messaging/_drivers/amqp.py | 44 ++- oslo_messaging/_drivers/amqpdriver.py| 15 +- oslo_messaging/_drivers/impl_qpid.py | 2 +- oslo_messaging/_drivers/impl_rabbit.py | 346 --- oslo_messaging/rpc/dispatcher.py | 2 +- oslo_messaging/target.py | 9 +- 11 files changed, 541 insertions(+), 70 deletions(-) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ 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
