endless loop with unspecified port when using fallthrough

[ckcd]

Bug description

If pod defines a port (assumed port-1) but service do NOT defines this port-1, then for a single request to POD_IP:port-1, we can see very very much logs of this single request, and it makes a loop between sidecar and iptables which will final use all 1024 connection-pool of envoy.

for example, for this service and deployment:

apiVersion: v1
kind: Service
metadata:
  name: ubuntu-svc
spec:
  type: ClusterIP
  selector:
    app: ubuntu
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http-ubuntu
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: ubuntu
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: ubuntu
    spec:
      containers:
      - name: ubuntu
        image: ubuntu:xxx
        ports:
        - containerPort: 80
          name: http-ubuntu1
        - containerPort: 2334
          name: http-ubuntu2

the pod defines port 80 and port 2334 but the service only defines 80, and if we do a request from another service to POD_IP:2334, i see plenty of logs in envoy:

[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47804 10.2.245.146:2334 10.2.245.146:47802 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47806 10.2.245.146:2334 10.2.245.146:47804 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47808 10.2.245.146:2334 10.2.245.146:47806 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47810 10.2.245.146:2334 10.2.245.146:47808 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47812 10.2.245.146:2334 10.2.245.146:47810 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47814 10.2.245.146:2334 10.2.245.146:47812 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47816 10.2.245.146:2334 10.2.245.146:47814 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47818 10.2.245.146:2334 10.2.245.146:47816 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47820 10.2.245.146:2334 10.2.245.146:47818 -
[2019-05-30T05:26:48.098Z] "- - -" 0 - "-" 81 0 89 - "-" "-" "-" "-" "10.2.245.146:2334" PassthroughCluster 10.2.245.146:47822 10.2.245.146:2334 10.2.245.146:47820 - 
...
...
...

which means somewhere makes a bad loop !

the reason, i guess, because of this commit and this commit add a default passthrough cluster , all traffic will be fallthrough, and in this case, the request to POD_IP:2334 will be fallthrough and go to iptables, and it will go to OUTPUT table because it's dst_ip is itself, and got this chain:

Chain ISTIO_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
 2049  123K ISTIO_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1

and then go back to envoy, and be fallthrough, and go to iptables ... so the loop became.

Expected behavior

I think the correct behavior should be 404 or 502, but maybe we can find some perfect answer.

Steps to reproduce the bug

as shown above.

Version (include the output of istioctl version --remote and kubectl version)

istio 1.1.7
kubernetes 1.12.7

How was Istio installed?

helm template ./install/kubernetes/helm/istio \
    --set global.mtls.enabled=false \
    --set global.enableTracing=false \
    --set global.proxy.accessLogFile="/dev/stdout" \
    --set gateways.istio-ingressgateway.type=NodePort \
    --set gateways.istio-egressgateway.enabled=false \
    --set grafana.enabled=true \
    --set prometheus.enabled=false \
    --name istio \
    --namespace istio-system \
    > ./istio.yaml

Environment where bug was observed (cloud vendor, OS, etc)

aws, ubuntu 16.04

[howardjohn]

I confirmed I can reproduce the issue, seems to only happen with pod IP

[ckcd]

@howardjohn

Thanks for your reply!

seems to only happen with pod IP

yes, it only happen with request to POD_IP:Port when this Port is NOT in service.

And i think it's because the PassthroughCluster in virtual listener. maybe we should add some special judge in it to avoid this bad case.

[hzxuzhonghu]

Can we set iptables not to intercept these packet?

[ckcd]

Can we set iptables not to intercept these packet?

It's hard to split these packet with others in this chain:

Chain ISTIO_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
 2049  123K ISTIO_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1

btw, i really don't know the meaning of this chain, in normal situation, what kind of packets will go through lo with a !127.0.0.1 address ? can we just delete this chain ?

[hzxuzhonghu]

There is a ENV 'DISABLE_REDIRECTION_ON_LOCAL_LOOPBACK', set this will disable redirect on loopback

[hzxuzhonghu]

#12110

[ckcd]

@hzxuzhonghu

Thanks for your reply !

#12110

I have tested this function, but there are several questions that confused me:

Q1: I cannot find any place to set the ENV, how can i set the DISABLE_REDIRECTION_ON_LOCAL_LOOPBACK in any deployment or any configmap ? And can it be universal that affect all istio-proxy ?

Q2: I delete this chain manually and do some test: it can actually prevent the infinite loop with POD_IP:2334 and the http response is OK; However, with this action, a pod can NOT calls to back itself: POD_IP:port or SVC:port all failed, and this is the purpose of the deleted chain.

So i think maybe we should find some fine-grained solutions to solve this infinite loop.

[hzxuzhonghu]

for Q1, i think it need to edit the configmap that sidecar-injector used, i can not remember its name, but you can check the pod yaml.

For question2, i donot think too much

[ckcd]

@hzxuzhonghu

This problem became more dangerous in 1.2.0 ...

In out cluster, with the containerPort defined but no related svc port as shown above, in 1.2.0, when sending requests to POD_IP:port, envoy will take up more and more memory immediately and be OOM killed because it got the limit (1G); actually in my test, just send 2 requests from other pod to this POD_IP:port, then envoy memory will got 1G immediately.

and the logs of envoy is very big than before:

[2019-06-25T06:58:20.991Z] "GET /metrics HTTP/1.1" 431 - "-" "-" 0 0 2272 2271 "10.2.190.183,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81,10.2.139.81" "Prometheus/2.9.2" "aa757221-a219-4087-897c-3257a013ecd6" "10.2.139.81:23333" "10.2.139.81:23333" PassthroughCluster - 10.2.139.81:23333 10.2.139.81:38536

So i'm wondering that does we do something in istio 1.2.0 or envoy than makes things worse ?

And this infinite loop problem exists from 1.1.1 to now, is there any wonderful solutions we can made ?

[ckcd]

can we just exchange the order of first chain with second(and third) chain ?

e.g. for now the ISTIO_OUTPUT looks like:

Chain ISTIO_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ISTIO_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1
 1269 76140 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1337
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner GID match 1337
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.1
    0     0 ISTIO_REDIRECT  all  --  *      *       0.0.0.0/0            100.64.0.0/10
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

and the first chain(let's call it chain-0) may causes infinite loop as we talk in this issue and in:
#12110
#14242

And in my opinion, the purpose of chain-0 is for a pod requests itself using POD_IP or SVC_IP;

So if we modify the ISTIO_OUTPUT chains to:

Chain ISTIO_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
 1269 76140 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1337
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner GID match 1337
    0     0 ISTIO_REDIRECT  all  --  *      lo      0.0.0.0/0           !127.0.0.1
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.1
    0     0 ISTIO_REDIRECT  all  --  *      *       0.0.0.0/0            100.64.0.0/10
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

that move chain-0 to line 3. And i have do some test to confirm that in this situation:

1. the infinite loop problem is RESOLVED (http 200);
2. requests to itself using POD_IP:port is OK;

So I think it can solve these problems.

@hzxuzhonghu @howardjohn ideas welcome ~

[hzxuzhonghu]

It seems not feasible, i have previously opened #14779 to change something, but i found all the rules orders are intended.

[howardjohn]

the problem is introduced in 1.1.4

You can "fix" it by setting outbound Traffic policy to registry only or set the env var PILOT_ENABLE_FALLTHROUGH_ROUTE=0. (maybe not exactly that, on phone right now I can send the docs later if you need)

[ckcd]

@hzxuzhonghu

Thanks for your opinion, I read #14779 and got your point. I will take a deep look into it.

[ckcd]

@howardjohn

yes it's actually PILOT_ENABLE_FALLTHROUGH_ROUTE. But in my cluster I need it be ALLOW_ANY mode, so this "fix" may not work for me.

[costinm]

@rshriram @louiscryan @duderino

[costinm]

Current plan (tentative):
For 1.3, @silentdai will try to add a new filter in the inbound filter chain, matching "src=MYIP" ( dst is allways localhost for the inbound filter chain ). If this matches - we would blackhole.
Connections that are matched by an explicit filter chain by port, as well as inbound requests from a different machine will work as expected and not be affected. This only works if we have split filter chains.
Outbound filter chain is not involved anymore.

For 1.2 - the options are:

• turn off PILOT_ENABLE_FALLTHROUGH_ROUTE - this is probably the least desirable
• add an easy option to DISABLE_REDIRECTION_ON_LOCAL_LOOPBACK - will break pods talking with themselves.
• easy option to turn on split chains (which we'll use for 1.3), with the 1.3 fix backported.

[costinm]

In addition @fpesce is looking for 1.2 to add an extra iptables rule, to check:

• if sender_uid != envoy
• src ip = MYIP
• dst ip = MYIP
  -- return

This will let pod talk with itself without going trough envoy, when DISABLE_REDIRECTION_ON_LOCAL_LOOPBACK is set. Will not help for pod talking with itself using the VIP - this is where we don't have yet a solution.

[costinm]

Moving back to 1.2 since that's the critical target.

[rshriram]

Why do we need to set DISABLE_REDIRECTION_ON_LOCAL_LOOPBACK ? Why can’t it always be set ?

[rshriram]

Here is a permanent fix. Add an option in envoy orig dst cluster to reuse orig dst port but rewrite the ip alone (call it orig_port). Then we could have a default inbound passthrough cluster for the VirtualInbound listener that will forward all traffic to 127.0.0.1:orig_port. This will permanently fix the issue without having to tweak iptables. It will also eliminate all inbound clusters as we now simply can use the inbound-passthrough cluster.

It’s easy to add this feature to envoy. Cluster already has an options field for orig dst lb.

[costinm]

We can't rewrite to 127.0.0.1:orig_port - would be a huge security vulnerability. Apps bind to 127 to prevent traffic from external addresses - this would automatically make all localhost-bound listeners exposed as if they were bound on 0.0.0.0

Regarding DISABLE_REDIRECTION - the reason it exists is to handle the case of app talking to the cluster VIP, which gets captured by Envoy and sent to a cluster with TLS enabled. If the EDS returns an endpoint running on the same pod, the request needs to be bounced trough envoy on the inbound path to handle the TLS decryption. Once we disable redirection we break this case.

[costinm]

Also would be good to make clear the version - for 1.3 with split chains I believe the proposed solution handles all use cases. Traffic from local IP to local IP will bypass envoy at iptables level, and traffic sent to the VIP that is resolved to local IP will match an explicit filter in the inbound chain.
What the extra filter will do is block traffic sent by the outbound 'original dst' to local IP ( the loop cause ).

So outbound chain will match VIP or send to original DST - which can be an external IP, or one of the container ports on the local IP. Same as today.

Inbound chain will capture all traffic - from external IPs or from envoy sending to local IP.
If it matches a filter with one of the ports - it'll use it.
If it doesn't match any other port in the inbound chain, and the SOURCE is local IP - it will drop. It means it's a looping packet.
Otherwise - will use original DST, which is localIP:port - and will go trough iptablesbe handled by the app if a socket is listening. If no socket is listening - this will still

[rshriram]

We can't rewrite to 127.0.0.1:orig_port - would be a huge security vulnerability. Apps bind to 127 to prevent traffic from external addresses

We are already routing to 127.0.0.1:port from podIP:port for container ports. This has been how things have operating since beginning. So what’s the new issue we have here? Why isn’t this an issue today with existing inbound clusters

[lambdai]

@rshriram
containerPort config act as a whitelist to capture since it is guarded by iptables.
With default networking by removing containerPort, sidecar proxy default would capture every port. It's too risky capture on each port and forward to 127.0.0.1:{thatPort}

[costinm]

I guess it's similar with UDS support: obviously you can't connect from the network to a UDS socket, but user can configure Istio to expose the UDS socket to the network. If user has an explicit config defining a service and container port for a 127.0.0.1 - it is considered intent to expose it.

But with 'magic' automatic config for ports - i.e. the originalDst in the input chain - we can't automatically expose all 127.0.0.1.

In original Istio 0.1 - before the containerPort requirement - we still used the Service definition, so
user explicitly told us to expose a 127.0.0.1 service via Istio ( with mtls, etc).

[howardjohn]

This is fixed by #15833, to be backported to 1.2 and 1.1, and a duplicate (in terms of root cause -- thanks for all the details you provided @ckcd) of #14242.

For future split listener plans we will need a better solution, but for now I think its best to close this and consolidate conversation in #14242 as we have two discussions going on here