Open Stack

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.

-bryan


On Thu, Apr 3, 2014 at 1:49 PM, Nathan Kinder <nkinder at redhat.com> wrote:

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140403/741531b7/attachment.html>