podman machine improve port forwarding

[Luap99]

What this PR does / why we need it:

This commits adds port forwarding logic directly into podman. The
podman-machine cni plugin is no longer needed.

The following new features are supported:

• works with cni, netavark and slirp4netns
• ports can use the hostIP to bind instead of hard coding 0.0.0.0
• gvproxy no longer listens on 0.0.0.0:7777 (requires a new gvproxy
  version), the API is only reachable from within the VM via gateway.containers.internal
• support the udp protocol

With this we no longer need podman-machine-cni and should remove it from
the packaging. There is also a change to make sure we are backwards
compatible with old config which include this plugin.

How to verify it

We have no podman machine test at the moment.
Please test this manually on your system.
Make sure to copy the new podman and rootlessport binary into the vm
because the server needs the fix. Also make sure your gvproxy is new enough.

Which issue(s) this PR fixes:

Fixes #11528
Fixes #11728

Special notes for your reviewer:

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Luap99]

@baude @ashley-cui @guillaumerose PTAL

[guillaumerose]

lgtm

removing the podman-machine-cni binary is a great idea!

[rhatdan]

@baude @mheon @flouthoc PTAL

[TomSweeneyRedHat]

LGTM
but definitely want some of the others noted in prior comments to throw in an opinion, @jwhonce too

[guillaumerose]

Is there a chance having an old VM with a recent podman on the host won't work?
For instance, the old machine will try to connect to port 7777.

If the VM image with newer podman is released after podman on the Mac, could it happen?

[afbjorklund]

It's not so obvious how to tunnel an arbitrary port (e.g. 9090) over to the VM, like which podman command to use.

[Luap99]

It's not so obvious how to tunnel an arbitrary port (e.g. 9090) over to the VM, like which podman command to use.

Port forwarding is done automatically for your containers. There is no podman command for that. If you need to expose arbitrary ports you need to talk directly to gvproxy.

[Luap99]

Is there a chance having an old VM with a recent podman on the host won't work? For instance, the old machine will try to connect to port 7777.

If the VM image with newer podman is released after podman on the Mac, could it happen?

Yes this will be a problem. Given that this is a 4.0 change we have to update both at the same time otherwise you run into many issues, the libpod API is not compatible.

[flouthoc]

My two-cents

• I think PR should have a label of breaking-change as we discussed and would be also nice if we could add a PR where support for :7777 was removed from gv_proxy and a small description of how do we communicate with API now.

• Although i'd like to suggested @guillaumerose @Luap99 . Couldn't we check gvproxy version in podman using helper function and add support for :7777 for cases where gv_proxy is still pointing to older version while new logic for newer version.
  My only concern is podman is breaking compatibility with loosely handled component like gvproxy. But if we are going to do a force update with podman 4.0 then i guess its fine.

[Luap99]

I think PR should have a label of breaking-change as we discussed and would be also nice if we could add a PR where support for :7777 was removed from gv_proxy and a small description of how do we communicate with API now.

Added labels and more info to the PR description.

Although i'd like to suggested @guillaumerose @Luap99 . Couldn't we check gvproxy version in podman using helper function and add support for :7777 for cases where gv_proxy is still pointing to older version while new logic for newer version.
My only concern is podman is breaking compatibility with loosely handled component like gvproxy. But if we are going to do a force update with podman 4.0 then i guess its fine.

There is no point in supporting that, the 4.X client should/will refuse to work with an 3.X server. The API is not compatible so there is no point is supporting the the 7777 port for the old server. The latest gvproxy release already contains this feature so we should be good, podman 4.0 will not be released for another 2-3 months.

[rhatdan]

/lgtm

[p-rog]

This PR contains a fix to the CVE-2021-4024

Vulnerability description:
The gvproxy API is being accessible on port 7777 on all IP addresses on the host. If that port is open on the host's firewall, an attacker can potentially use gvproxy API to forward ports on the host to ports in the VM, making private services on the VM accessible to the network. This issue could be also used to interrupt the host's services by forwarding all ports to the VM.