SNI routingmodule and routing of TCP traffic with TransportServer

[shaun-nx]

Overview

As a maintainer of NGINX Ingress Controller, I would like to enable users of our TransportServer resource to route traffic to their backend services using a Server Name Indicator (SNI) provided by a Host Header, so that resources hosted on the same server can be identified by their host name, even if they are on the same host IP.

High-level Functional Requirements

• Enable TransportServer to dynamically route traffic based on the value of the HostHeader
• Enable TransportServer to be deployed with a host field in its spec, without requiring tls-passthrough to be enabled

Definition of Done

Development

• Unit tests are written to cover functionality delivered in the story.
• Make sure that the unit test passes before creating a pull request.
• Make sure that the test coverage stays optimal.
• Run make lint locally before creating a PR.

Testing

• Automated tests are written as part of the story.
• Run “make lint-python“ from root
• Acceptance criteria are met.
• Stories are demonstrated to the team.
• Product Manager accepts the story as done.
• If a feature requires changes/extensions of the Helm chart, those shall be done as part of the story.

Release Notes & Documentation

• PR is labeled appropriately so they display in GitHub release notes.
• Create/update documentation related to the user story.
• Create/update the example in our codebase when applicable.

---

Additional Context

SNI based routing of Layer 4 traffic is a way to support customers using DNS names for TCP traffic and support routing based on the SNI header.
With NGINX this is implemented using the stream ssl pre-read module.
https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html

This module is already present in the NGINX Plus binary.

Today, this is possible with heavy use of snippets. The ask is to make this present and first class with the TransportServer resource.

This also historically described here:
https://stackoverflow.com/questions/34741571/nginx-tcp-forwarding-based-on-hostname

There are some additional considerations that need to be included here:

• The possibility for greater flexibility with TransportServer

The overall concept is multiple upstream targets for TCP behind a single listener and to route based on SNI.
This would support both TLS Passthrough as well as advanced programmability that might require TLS decryption and re-encryption.

To bring this all together:

• TransportServer would include the option for a top level domain type SNI match ( foo.com )
• Following a concept similar to an http path or nginx location - the extension of a service specific route that matches to the backend service (service.foo.com)
• This would support TLS passthrough and decrypted TLS (it would use preread)

TLS traffic in -> TransportServer matched TLS of HostHeader -> Routes to appropriate upstream based on HostHeader

POC Tasks

Preview Give feedback

1. POC - Routing based on HostHeader without tls-passthrough #6438
   3 of 3
   backlog +1
   
2. Create documentation for routing based on HostHeader without tls-passthrough #6439
   1 of 1
   backlog +1

Implementation Tasks

Preview Give feedback

1. Routing based on HostHeader without tls-passthrough #6440
   backlog +1
   

[github-actions]

Hi @shaun-nx thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!