Open Stack

On 03/31/2014 12:12 PM, Nathan Kinder wrote:
> 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.

I've published a blog post based on my research of this topic:

  https://blog-nkinder.rhcloud.com/?p=7

I'd like to use this as a basis for improving the Security Guide, but
I'd love to get some feedback from others first.  Any comments would be
much appreciated!

Thanks,
-NGK

> 
> -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
>>
>>
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>