Re: Proposal: Improving Security for HTTP Ingress to CFAR Application Containers

Eric Malm <emalm@...>

Hey, Mike,

On Wed, Aug 15, 2018 at 10:36 AM, Mike Youngstrom <youngm@...> wrote:
- This secured configuration would initially be incompatible with CF SSH, and would likely never be compatible with TCP routing, as the Routing team has focused its efforts on replacing both the Gorouter and the TCP routers with Istio-configured gateway Envoy proxies. Would those incompatibilities prohibit you as platform operators from opting into this improved security in environments where you would particularly like to enforce it?

We would love to have greater route integrity and security for our HTTP clients.  If configuring this would provide those improvements to HTTP but not for TCP and SSH, we would still deploying it just to get the benefits for HTTP.  Is that what you're asking? 

Not quite: in the initial form of this more secured configuration, neither CF SSH nor TCP routing will work at all, as their gateway/front/edge routers would not have the network pathway into the container that they currently recognize. The Diego team is actually done at this point with the diego-release features required to enable that initial secured configuration, and will soon contribute an experimental operations file to opt into it to cf-deployment shortly and then focus on our approach to make CF SSH work again in this secure mode. We don't expect the current TCP routing tier ever to work with this configuration, though, as the Routing team is instead focused on the Istio integration effort as a longer-term plan to replace both the HTTP and TCP routing tiers. So I'm interested in knowing whether you'd be able to enable this extra security in any of your CF environments if either (a) CF SSH doesn't work as a result (short-term obstacle, resolved in a month or so) or (b) TCP routing doesn't work (longer-term obstacle, resolved only with Istio integration).
We don't use these values as part of an API or client library.  However, we do find it useful, on occasion, to know real network ip address of the cell an application is running on usually for firewall or other network debugging activities.  We don't ever use the port information.  I imagine we can find this information other ways but the CC api is currently the simplest way our application developers could self service find this data.  I don't think this is a big issue.  Just noting that my team (and perhaps others) will need to devise a different way to provide this information to app developers.

Great, thanks for the feedback! The CF_INSTANCE_IP environment variable will continue to contain the cell VM's IP inside the container environment, and it'll likewise still be present in the response from the CC stats endpoint, so it sounds like those network-debugging activities would be unaffected. It'd of course be great to hear the specifics of how having that cell VM IP has been useful to your developers or to you as the platform operators in resolving those network-related issues, though.

Thanks again,

Join to automatically receive all group messages.