Better support for SNI-based routing for TCP resources

[Snaipe]

Today, it's possible to configure a TCP or Backend object to switch between multiple TLS services based on the SNI. It's however a bit awkward to do, and there does not seem to be a paved path for providing ingress on a "type" of TLS-based service based on its name.

A simple example is providing mongodb ingress on port 27017. If I want to do this today, I either have to define one TCP object that exhaustively lists all of the mongodb services of the cluster with backend_switching_rule_list like this, or define one Backend object that does the same with server_switching_rule_list. This makes it difficult to isolate the relevant configuration to each helm chart that happens to deploy a mongodb instance.

Ideally, there should be a way to provide ingress like the Ingress object works like: have a cluster operator define a frontend listening on port 27017 for TLS connections (refuse plain TCP), then allow cluster developers to provide their own Backend object that automatically gets added to a backend switching rule list.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Snaipe]

Still relevant today.

[jsturmics]

I came here to make the very same request. We were putting together a Helm chart with TCP resources like:

apiVersion: ingress.v1.haproxy.org/v1
kind: TCP
metadata:
  name: app-tcp-ingress
  annotations:
    ingress.class: haproxy
spec:
  - name: app-server
    frontend:
      name: app-server
      binds:
        - name: bind1
          port: {{ .Values.app.server.port }}
      backend_switching_rule_list:
        - name: {{ .Release.Namespace }}_{{ .Values.app.server.name }}_{{ .Values.app.server.port }}
          index: 0
          cond: "if"
          cond_test: "{ req_ssl_sni -i {{ .Values.app.serviceHostname }} }"
    service:
      name: {{ .Values.app.server.name }}
      port: {{ .Values.app.server.port }}

This works great the first time. Could not add another in a separate namespace due to name/port collisions.

What we really need the controller to do is merge rule lists for the same frontend. This ingress project doesn't seem to make it possible. We needed it to behave like a real ingress but with SNI and TLS passthrough.

I'm going to try this on Istio and the Gateway API instead.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Snaipe]

Still relevant.

[Snaipe]

@oktalz Can this issue be reopened? It is still an outstanding issue, and I don't think feature requests ought to be auto-closed.

[oktalz]

yes, it is unfortunate that ingress (as ingress object) does not support TCP services, hence we have this TCP CRD to at least provide some support.

potentially this is doable, so I added enhancement label. (and this label will keep it open)

PS. this does not mean we are starting implementing it, but we will consider this as new feature