Proposal: Improving Security for HTTP Ingress to CFAR Application Containers
Eric Malm <emalm@...>
Building on the features and technologies the CF Diego and Routing teams have introduced into the CF App Runtime to improve application routing consistency, security, and stability (https://lists.cloudfoundry.org/g/cf-dev/topic/11900235#7744, which we have often called "route integrity"), the Diego team intends to make it possible for platform operators to opt into improving the security of how traffic ingresses into application containers. In particular, operators would be able to opt into ensuring that only CF system components, or even only the gorouter HTTP routers, would be able to connect to application containers from the infrastructure-provided network.
The full proposal document is available at https://docs.google.com/document/d/1DjapCLbdgGBmpuWt2P2PV-qm_vUwI_9IZHae9TbN_Pw/edit, and we welcome your comments and questions on the document or on this mailing list thread.
Some areas on which we would particularly like community feedback:
- 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?
- 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.
Eric Malm, for the CF Diego team