When using containerd, binding a port to localhost also binds the port to 0.0.0.0, making it accessible on all network interfaces of the host. This occurs because the iptables scanner creates port bindings using the wildcard IP, also, when containerd's CNI plugin publishes the port via the API, it is immediately forwarded to the host switch's expose API simultaneously.
However, the iptables scanner also uses the GetPorts function from Lima, which contributes to the core of this issue. When the scanner inspects the iptables, if a port is not associated with any specific IP address, it defaults to using 0.0.0.0 to represent the entry.
To prevent this we would need to 1) only run the iptable scanner when kubernetes is enabled to reduce the duplications, 2) expose the port storage across both containerd event API and iptables scanner to lookup port's existence prior to sending it to the host switch API.
When using containerd, binding a port to localhost also binds the port to 0.0.0.0, making it accessible on all network interfaces of the host. This occurs because the iptables scanner creates port bindings using the wildcard IP, also, when containerd's CNI plugin publishes the port via the API, it is immediately forwarded to the host switch's expose API simultaneously.
However, the iptables scanner also uses the GetPorts function from Lima, which contributes to the core of this issue. When the scanner inspects the iptables, if a port is not associated with any specific IP address, it defaults to using 0.0.0.0 to represent the entry.
To prevent this we would need to 1) only run the iptable scanner when kubernetes is enabled to reduce the duplications, 2) expose the port storage across both containerd event API and iptables scanner to lookup port's existence prior to sending it to the host switch API.