[Feature] TLS TCP session proxying

[davecheney]

This is a high level ticket to track the addition of TLS forwarding to Contour 0.8.

What is being added?

Support for handling TLS encrypted TCP sessions is planned for Contour 0.8. This will terminate the TLS connection at the Envoy edge and forward the decrypted TCP flow to a backend pod making up a service. [Note: this is my best understanding of the way Envoy 1.7.0 works, this may change].

How is it being added?

The DAG is being extended to differentiate between dag.HTTPService objects (#786), and dag.TCPService objects (#785). Once this is complete it will be possible to model the required configuration Envoy requires.

On the frontend the ingressroute.spec stanza will be extended with a new forward key. Something like

spec:
  virtualhost:
    fqdn: secure.example.com
    tls:
      secretname: "required"
  forward:
    services:
    - name: s1
      port: 80
      weight: 10
    - name: s2
      port: 8080
      weight: 20
    - name: s3
      port: 80
      weight: 70
      strategy: Random # Overrides default LB policy

• services is a list of Service objects, similar to spec.routes.services. There may be many entries in the services list, but only one services key may be present.
• name is the name of a service in this Ingressroute's namespace.
• port is the port on the Service object. This port is expecting NON TLS traffic. TLS demux is handled at the Envoy layer.
• weight, weighting is supported with the same logic as spec.route.services.
• strategy, load balancing strategies are supported per backend service.

Only one of virtualhost or forward keys may be present. forward is ignored if spec.virtualhost.tls is missing.

Out of scope

• Raw TCP forwarding is not in scope for Contour 0.8. All connections proxied through Envoy must begin with a TLS SNI handshake. The SNI handshake is required to establish the hostname for the incoming connection. If TLS is not used then it is not clear what value using Contour adds over a traditional service load balancer.
• TLS forwarding whereby the TLS connection is forwarded encrypted to the backend service is not in scope for Contour 0.8. This might be tracked as SSL Passthrough #15.
• UDP forwarding is not in scope. It is unlikely Contour will ever attempt this feature.
• Delegation from a Root ingressroute to another is not in scope.

[alexbrand]

Raw TCP forwarding is not in scope for Contour 0.8. All connections proxied through Envoy must begin with a TLS SNI handshake. The SNI handshake is required to establish the hostname for the incoming connection. If TLS is not used then it is not clear what value using Contour adds over a traditional service load balancer.

I think one potential value-add over traditional service load balancers is traffic consolidation. For example, in the case that I have N services that I want to load balance, I can send traffic through my ingress tier instead of having (and paying for) N cloud load balancers.

[davecheney]

@alexbrand but these N services would have to be presented externally on N ports. Without the SNI handshake we cannot tell which backend service the traffic is for so we'd have to forward then entire port carte blanche. This means contour would need to open a new incoming port on its service type:loadBalancer to route that traffic.

[mauilion]

You could map all the rest of the port range for that ip to internal services

[mauilion]

We should talk through a couple of use cases I've seen.

[rosskukulinski]

I think for 0.8 it's safe to focus on the TLS TCP user-case, but I agree with @alexbrand and @mauilion that we should work out the port-based proxying user-cases for future releases.

[joshrosso]

Is this feature available in 0.8+ via #810?

I see it's been target for 0.9.

[davecheney]

@joshrosso part of this feature is available in 0.8, please see the release notes -- there are a bunch of limitations. This ticket will stay open until those limitations are addressed.

The hope is to deliver more TCP proxying functionality in the 0.9 milestone.

[davecheney]

I'm going to mark this as closed for the moment. Additional enhancements on this feature should have their own issue number.