<div dir="ltr">I just read the blog post and it is a nice summary of the discussion we've had in this thread. Thanks for putting that together. I'd be happy to work with you to help make these improvements to the book.<div>
<br></div><div>-bryan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 1:49 PM, Nathan Kinder <span dir="ltr"><<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@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 03/31/2014 12:12 PM, Nathan Kinder wrote:<br>
> On 03/25/2014 02:50 PM, Bryan D. Payne wrote:<br>
>> A few thoughts come to mind:<br>
>><br>
>> * For any production system, I suspect that you will be running a front<br>
>> end server in front of the actual endpoint. So, at a minimum, that<br>
>> server is where the TLS termination would happen. Depending on your<br>
>> setup, it may make more sense to terminate directly at that server<br>
>> (e.g., Apache or Nginx), or using a dedicated / purpose built TLS<br>
>> termination shim (e.g., Stud or Pound).<br>
>><br>
>> * In many deployments, the control plane uses a different trust model<br>
>> than the external networks. Services on the control plane may not trust<br>
>> the same set of root certs that clients on the external network choose<br>
>> to trust. As such, the TLS setup would need to be different.<br>
>> Re-encrypting the connection at a proxy that sits on the boundary of<br>
>> the external network and the control plane serves to handle this use<br>
>> somewhat common use case.<br>
>><br>
>> * In some cases it may be useful for purposes of load balancing, and<br>
>> auditing to be able to inspect the traffic at a proxy sitting between<br>
>> the external network and the control plane.<br>
>><br>
>> * If there is no use case to inspect the traffic, and there is a common<br>
>> set of trusted root certs on both networks, then I see no problem just<br>
>> taking the TLS all the way back to the front-end server handling the<br>
>> endpoint (these would likely be deployed on the same machine... and<br>
>> could then just communicate the clear-text information over a unix<br>
>> socket or similar setup).<br>
><br>
> A unix socket would definitely be ideal. As you say, if inspection of<br>
> the encrypted traffic is not needed for something like load balancing,<br>
> this sort of deployment would meet the goal of keeping clear-text<br>
> traffic off of the network. It would also add some privilege separation<br>
> by keeping access to the private key limited to the SSL terminator (vs.<br>
> allowing the API endpoint process to access it).<br>
><br>
>><br>
>> If others agree, perhaps there is room to improve the wording in the<br>
>> book around this point? I do suspect that the setup described in the<br>
>> book is most common for real world deployments, but I don't see anything<br>
>> wrong with the other setup from a security standpoint.<br>
><br>
> I do think that some re-wording and more detail would add clarity in<br>
> this area. I think that each deployment will have different security<br>
> requirements and concerns. The Security Guide should spell out the<br>
> options, with limitations and concerns mentioned for each. This would<br>
> allow the reader to make their own decision about what type of<br>
> deployment would meet their requirements.<br>
><br>
> I'm working on writing up some details in this area, so I'd be happy to<br>
> submit some patches for this chapter of the Security Guide.<br>
<br>
</div></div>I've published a blog post based on my research of this topic:<br>
<br>
<a href="https://blog-nkinder.rhcloud.com/?p=7" target="_blank">https://blog-nkinder.rhcloud.com/?p=7</a><br>
<br>
I'd like to use this as a basis for improving the Security Guide, but<br>
I'd love to get some feedback from others first. Any comments would be<br>
much appreciated!<br>
<br>
Thanks,<br>
-NGK<br>
<div><div class="h5"><br>
><br>
> -NGK<br>
><br>
>><br>
>> My two cents,<br>
>> -bryan<br>
>><br>
>><br>
>><br>
>> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <<a href="mailto:nkinder@redhat.com">nkinder@redhat.com</a><br>
>> <mailto:<a href="mailto:nkinder@redhat.com">nkinder@redhat.com</a>>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> The Security Guide currently recommends that SSL/TLS be used to protect<br>
>> the API endpoints (as it should). We specifically mention that SSL<br>
>> proxies should be used for this, as opposed to configuring SSL natively<br>
>> in the services themselves:<br>
>><br>
>><br>
>> <a href="http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html" target="_blank">http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html</a><br>
>><br>
>> Is there any particular reason why we don't recommend configuring<br>
>> SSL/TLS natively in the services? It seems like that would be an ideal<br>
>> approach, as it eliminates the need for running proxies. It also keeps<br>
>> access to the unencrypted traffic closer to the actual services that<br>
>> need to access it, which is better from a security standpoint.<br>
>><br>
>> I'm not sure that all of the integrated projects actually have working<br>
>> native SSL/TLS support, but I know that a number of them claim to have<br>
>> support. Shouldn't native support be the preferred recommendation from<br>
>> a security standpoint?<br>
>><br>
>> Thanks,<br>
>> -NGK<br>
>><br>
>> _______________________________________________<br>
>> Openstack-security mailing list<br>
>> <a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Openstack-security mailing list<br>
> <a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a><br>
</div></div>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
><br>
<br>
</blockquote></div><br></div>