Subscribe to container engine API for published ports

[Nino-K]

This PR aims to capture the published ports within the VM for various container engines. It directly subscribes to the corresponding container engine APIs (Docker, containerd and Kubernetes) to detect published ports immediately as a container is created.

I'm also planning to move the iptables and procnet settings under the portMonitor property; however, that will be addressed in a follow-up PR.

[AkihiroSuda]

Seems overengineering.
What is the problem with the existing event watcher?

[AkihiroSuda]

Too many new dependencies

[Nino-K]

Unfortunately, there are many indirect dependencies being used for just a few direct ones. However, I went ahead and compared the guest agent sizes from the master build and my PR, and I’m happy to share the results below:

total 231384
-rw-r--r--  1 ninok  wheel    55M Sep 11 10:27 guestagent_master
-rw-r--r--  1 ninok  wheel    58M Sep 11 10:26 guestagent_pr

[AkihiroSuda]

This file isn't expected to be parsed externally

[jandubois]

I think the issue is that since containerd/nerdctl#4290 the information is no longer available via labels. How are you expected to get the port mapping information?

[AkihiroSuda]

The expectation is not to depend on container engine implementations; audit events or eBPF should work (see my comments below)

[jandubois]

Seems overengineering. What is the problem with the existing event watcher?

There are no event watchers for docker or containerd; we rely on polling /proc/net/tcp every couple of seconds (3?), so there is always a delay between the container opening a port and it being forwarded to the host.

See e.g. abiosoft/colima#71

This PR is basically a port of the event watchers from Rancher Desktop on Windows, which does not suffer from this issue.

[AkihiroSuda]

we rely on polling /proc/net/tcp every couple of seconds (3?), so there is always a delay between the container opening a port and it being forwarded to the host.

We also monitor audit events:

lima/pkg/guestagent/guestagent_linux.go

Line 33 in 69538a7

auditClient, err := libaudit.NewMulticastAuditClient(nil)

Maybe the audit monitor has a bug ?

[AkihiroSuda]

There is also a proposal to use eBPF to monitor ports

• Support for eBPF based port forwarding #3067

cc @balajiv113

[Nino-K]

Seems overengineering. What is the problem with the existing event watcher?

In addition to what @jandubois also pointed out, the current implementation
of the port collection mechanism uses a 3-second polling ticker, although this is configurable. However, this PR subscribes directly to the APIs, allowing port exposure events to be handled more immediately.

[jandubois]

This PR is in response to #2536

I thought I read a note from @balajiv113 that the audit approach didn't work out because most cloud images did not have the required kernel modules for it installed, but can't find the reference right now.

And #3067 also sounds like it doesn't work anymore for Kubernetes.

[jandubois]

#1855 may explain why audit monitoring doesn't seem to work.