Fix tproxy listeners with discovery chains.

[hashi-derek]

Description

Transparent proxy does not spawn outbound listeners for explicit upstreams to service-resolvers. When upstreams are explicitly defined, a corresponding listener should be spawned.

Testing & Reproduction steps

Create a service with the following fields configured:

consul.hashicorp.com/connect-inject: "true"
consul.hashicorp.com/connect-service-upstreams: "upstream:9001"
consul.hashicorp.com/transparent-proxy: "true"

Create a service resolver that will be used as the upstream.

apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
  name: upstream
spec:
  redirect:
    service: other-svc

Check the Envoy admin config dump and observe that no listeners are spawned.

PR Checklist

• updated test coverage
• external facing docs updated
• not a security concern

[freddygv]

I think this is a good start! Though there is a gotcha here because there are assumptions in the code that discovery chain watches for tproxy only get managed in one place.

I left a comment below explaining.

[freddygv]

What if instead we modify the check for cross-datacenter upstreams to instead check !CentrallyConfigured? That way we avoid allocating a new map. We're already checking UpstreamConfig in the reconciliation.

if upstream, ok := snap.ConnectProxy.UpstreamConfig[uid]; ok && upstream.Datacenter != "" && upstream.Datacenter != s.source.Datacenter {
	continue
}

Could become:

if upstream, ok := snap.ConnectProxy.UpstreamConfig[uid]; ok && !upstream.CentrallyConfigured {
	continue
}

This works because a cross-DC watch can only be done explicitly, and not via service-defaults/CentrallyConfigured.

[freddygv]

(Applies through L549))

[freddygv]

LGTM