Open Stack

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).

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.

My two cents,
-bryan



On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140325/ebcb6ea0/attachment.html>