Cilium: Consider dropping ephermeral port range check in NodePort

[brb]

Currently, we check whether a NodePort port range does not overlap with an ephemeral port range, and that the former precedes the latter. This might complicate some deployments, as we recently started enabling NodePort by default, and some users will see the compilation errors (until #10260 is backported).

The check is needed to ensure that a reply to a host-local application which established a connection to outside (= the host-local app's port is within the ephemeral port range) cannot be hijacked by a previously provisioned NodePort service. For this case we have recently introduced a measure - https://github.com/cilium/cilium/pull/9880.

However, there is still one case which we cannot prevent when dropping the constraint - a service might hijack an application traffic, if the application's connection was opened before the service provisioning. This is the case for kube-proxy too, see https://github.com/cilium/cilium/pull/9880#issuecomment-576593664.

Opinions? @borkmann @aanm @gandro

[brb]

Discussed with @gandro offline that implementing the check before provisioning the svc would be quite a hurdle, so #10260 should be enough.

[aanm]

agreed.

However, there is still one case which we cannot prevent when dropping the constraint - a service might hijack an application traffic, if the application's connection was opened before the service provisioning.

we should at least warn the user if this happens.

[jcrowthe]

It appears like PR #10260 does not respect net.ipv4.ip_local_reserved_ports. At scale, especially on a "proxy" type node, it can be necessary to add additional ports for the system to egress on. Something like the following would be needed:

net.ipv4.ip_local_port_range=1024 65535
net.ipv4.ip_local_reserved_ports=2379,2380,2579,3000,4240,4242,6443,8080,8503,8504,8523,8524,8543,8544,9090,9091,9100,9101,10248,10250,10251,10252,10257,10259,30000-32767

IIUC this PR would not allow this configuration, and in fact would fail kubeProxyReplacement: "strict" entirely. Is this something this ticket will also address?

[brb]

@jcrowthe We are going to fix this in v1.7.2. Also, the fix will auto-configure the ip_local_reserved_ports if there is an overlap between the NodePort and the ephemeral ranges.