[openstack-dev] [Neutron][LBaaS] Securing RPC channel between the server and the agent

Eugene Nikanorov enikanorov at mirantis.com
Thu Jan 30 10:58:24 UTC 2014


Hi Russel,

Thank for your input.
I'll look into that.

Thanks,
Eugene.


On Mon, Jan 27, 2014 at 6:57 PM, Russell Bryant <rbryant at redhat.com> wrote:

> On 01/27/2014 09:37 AM, Eugene Nikanorov wrote:
> > Hi folks,
> >
> > As we are going to add ssl implementation to lbaas which would be based
> > on well-known haproxy+stunnel combination, there is one problem that we
> > need to solve: securing communication channel between neutron-server and
> > the agent.
> >
> > I see several approaches here:
> > 1) Rely on secure messaging as described here:
> >
> http://docs.openstack.org/security-guide/content/ch038_transport-security.html
> >
> > pros: no or minor additional things to care of on neutron-server side
> > and client side
> > cons: might be more complex to test. Also I'm not sure testing
> > infrastructure uses that.
> > We'll need to state that lbaas ssl is only secure when transpost
> > security is enabled.
> >
> > 2) Provide neutron server/agent with certificate for encrypting
> > keys/certificates that are dedicated to loadbalancers.
> >
> > pros: doesn't depend on cloud-wide messaging security. We can say that
> > 'ssl works' in any case.
> > cons: more to implement, more complex deployment.
> >
> > Unless I've missed some other obvious solution what do you think is the
> > best approach here?
> > (I'm not considering the usage of external secure store like barbican at
> > this point)
> >
> > What do you think?
>
> Using existing available transport security is a good start (SSL to your
> amqp broker).
>
> For a step beyond that, we really need to look at a solution that
> applies across all of OpenStack, as this is a very general problem that
> needs to be solved across many components.
>
> There was a proposal a while back:
>
>     https://wiki.openstack.org/wiki/MessageSecurity
>
> This has since been moving forward.  Utilizing it has been blocked on
> getting KDS in Keystone.  IIRC, KDS should be implemented in Icehouse,
> so we can start utilizing it in other services in the Juno cycle.
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/0a5249a2/attachment.html>


More information about the OpenStack-dev mailing list