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

Mike Youngstrom <youngm@...>

- 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? 
- As part of enforcing this more secure configuration, the Diego cell components no longer map ports on their host VM directly to application ports inside the container. Each app instance currently receives the value of its host-side port in its CF_INSTANCE_PORT environment variable, though, and it is also exposed in the response from CC's app stats endpoint. For a variety of reasons (primarily the general availability of container networking and default app-security-group policies), we expect that these values are no longer useful for applications, and so we would like to deprecate them as part of this work and not to supply them in this optional, more secure configuration. Before we do so, we would like to know whether your applications, libraries, or other CF-related tools currently use this information and, if so, to what end.
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.

Join { to automatically receive all group messages.