Open Stack

On 03/25/2014 02:50 PM, Bryan D. Payne wrote:
> A few thoughts come to mind:
> 
> * For any production system, I suspect that you will be running a front
> end server in front of the actual endpoint.  So, at a minimum, that
> server is where the TLS termination would happen.  Depending on your
> setup, it may make more sense to terminate directly at that server
> (e.g., Apache or Nginx), or using a dedicated / purpose built TLS
> termination shim (e.g., Stud or Pound).
> 
> * In many deployments, the control plane uses a different trust model
> than the external networks.  Services on the control plane may not trust
> the same set of root certs that clients on the external network choose
> to trust.  As such, the TLS setup would need to be different.
>  Re-encrypting the connection at a proxy that sits on the boundary of
> the external network and the control plane serves to handle this use
> somewhat common use case.
> 
> * In some cases it may be useful for purposes of load balancing, and
> auditing to be able to inspect the traffic at a proxy sitting between
> the external network and the control plane.
> 
> * If there is no use case to inspect the traffic, and there is a common
> set of trusted root certs on both networks, then I see no problem just
> taking the TLS all the way back to the front-end server handling the
> endpoint (these would likely be deployed on the same machine... and
> could then just communicate the clear-text information over a unix
> socket or similar setup).

A unix socket would definitely be ideal.  As you say, if inspection of
the encrypted traffic is not needed for something like load balancing,
this sort of deployment would meet the goal of keeping clear-text
traffic off of the network.  It would also add some privilege separation
by keeping access to the private key limited to the SSL terminator (vs.
allowing the API endpoint process to access it).

> 
> If others agree, perhaps there is room to improve the wording in the
> book around this point?  I do suspect that the setup described in the
> book is most common for real world deployments, but I don't see anything
> wrong with the other setup from a security standpoint.

I do think that some re-wording and more detail would add clarity in
this area.  I think that each deployment will have different security
requirements and concerns.  The Security Guide should spell out the
options, with limitations and concerns mentioned for each.  This would
allow the reader to make their own decision about what type of
deployment would meet their requirements.

I'm working on writing up some details in this area, so I'd be happy to
submit some patches for this chapter of the Security Guide.

-NGK

> 
> My two cents,
> -bryan
> 
> 
> 
> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <nkinder at redhat.com
> <mailto:nkinder at redhat.com>> wrote:
> 
>     Hi,
> 
>     The Security Guide currently recommends that SSL/TLS be used to protect
>     the API endpoints (as it should).  We specifically mention that SSL
>     proxies should be used for this, as opposed to configuring SSL natively
>     in the services themselves:
> 
> 
>     http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html
> 
>     Is there any particular reason why we don't recommend configuring
>     SSL/TLS natively in the services?  It seems like that would be an ideal
>     approach, as it eliminates the need for running proxies.  It also keeps
>     access to the unencrypted traffic closer to the actual services that
>     need to access it, which is better from a security standpoint.
> 
>     I'm not sure that all of the integrated projects actually have working
>     native SSL/TLS support, but I know that a number of them claim to have
>     support.  Shouldn't native support be the preferred recommendation from
>     a security standpoint?
> 
>     Thanks,
>     -NGK
> 
>     _______________________________________________
>     Openstack-security mailing list
>     Openstack-security at lists.openstack.org
>     <mailto:Openstack-security at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
>