Support local_bind_address for Conusl Connect upstreams

[schmichael]

Support local_bind_address for Consul Connect upstreams:

             upstreams {
               destination_name = "count-api"
               local_bind_port = 8080
               local_bind_address = "0.0.0.0"
             }

Since IPs may vary by host, I think 0.0.0.0 and 127.0.0.1 are the only two options that make sense. We may just want to bind to 0.0.0.0 in network namespaces by default.

[dclfan]

+1 for this issue

[djenriquez]

@schmichael can you explain the need for this feature? This implies that there will be other sources that would be allowed access into the upstream apart from the tasks running in the network namespace. Which would mean needing to open up the local_bind_port from the network stanza.

[schmichael]

@djenriquez Indeed, allowing binding upstreams to 0.0.0.0 inside the network namespace would allow explicitly configured port forwarding to give external access to the upstream and effectively masquerade as the service.

You could use this to implement an "ingress" style jobs which use Envoy to proxy untrusted external traffic to Connect-enabled services. For example if there was an api service using Connect, an ingress service could set a local_bind_address = "0.0.0.0"; local_bind_port = 1234 and port forward 1234 from the host interface to the upstream listener inside Envoy's network namespace.

The ingress job would be run as a system job on nodes that an ALB or similar load balancer points to, thus allowing external traffic to proxy from non-Connect load balancers, through the ingress service, to the Connect-enabled api service.

I'm not even sure local_bind_address is sufficient to make that use case work. Even if it is possible, it doesn't seem optimal. There's got to be a better way to do ingress right? 😅

It's a topic of active discussion internally but any feedback is welcome (either on this wacky "ingress" use case or other local_bind_address use cases).

[fredrikhgrelland]

There's got to be a better way to do ingress right?

https://www.consul.io/docs/agent/config-entries/ingress-gateway
With Consul 1.8 both ingress end termination is possible. Are you planning on implementing this in nomad directly? It would be a killer feature. Currently trying to figure out how to enable this feature in 11.2

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.