<div dir="ltr"><div>Hi Russel,</div><div><br></div>Thank for your input. <div>I'll look into that.</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 6:57 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 01/27/2014 09:37 AM, Eugene Nikanorov wrote:<br>
> Hi folks,<br>
><br>
> As we are going to add ssl implementation to lbaas which would be based<br>
> on well-known haproxy+stunnel combination, there is one problem that we<br>
> need to solve: securing communication channel between neutron-server and<br>
> the agent.<br>
><br>
> I see several approaches here:<br>
> 1) Rely on secure messaging as described here:<br>
> <a href="http://docs.openstack.org/security-guide/content/ch038_transport-security.html" target="_blank">http://docs.openstack.org/security-guide/content/ch038_transport-security.html</a><br>
><br>
> pros: no or minor additional things to care of on neutron-server side<br>
> and client side<br>
> cons: might be more complex to test. Also I'm not sure testing<br>
> infrastructure uses that.<br>
> We'll need to state that lbaas ssl is only secure when transpost<br>
> security is enabled.<br>
><br>
> 2) Provide neutron server/agent with certificate for encrypting<br>
> keys/certificates that are dedicated to loadbalancers.<br>
><br>
> pros: doesn't depend on cloud-wide messaging security. We can say that<br>
> 'ssl works' in any case.<br>
> cons: more to implement, more complex deployment.<br>
><br>
> Unless I've missed some other obvious solution what do you think is the<br>
> best approach here?<br>
> (I'm not considering the usage of external secure store like barbican at<br>
> this point)<br>
><br>
> What do you think?<br>
<br>
</div></div>Using existing available transport security is a good start (SSL to your<br>
amqp broker).<br>
<br>
For a step beyond that, we really need to look at a solution that<br>
applies across all of OpenStack, as this is a very general problem that<br>
needs to be solved across many components.<br>
<br>
There was a proposal a while back:<br>
<br>
    <a href="https://wiki.openstack.org/wiki/MessageSecurity" target="_blank">https://wiki.openstack.org/wiki/MessageSecurity</a><br>
<br>
This has since been moving forward.  Utilizing it has been blocked on<br>
getting KDS in Keystone.  IIRC, KDS should be implemented in Icehouse,<br>
so we can start utilizing it in other services in the Juno cycle.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>