add support for a new option "isolate", a boolean that determines whether or not a network can send/recieve data outside of its bridge. This is done by creating a new chain "NETAVARK_ISOLATION" that drops external outgoing connections

resolves #154

Signed-off-by: cdoern [email protected]

Instead of using a packaged version of aardvark-dns, we grabbed the latest main branch zip copy and use it instead.

Signed-off-by: Brent Baude [email protected]

While releasing netavark binary lot of platform does not allows build process to pull deps from upstream repo.

Vendor and ship dependency locally in a vendor directory and point cargo to use local vendored deps.

Automatically uses vendor while doing make build or make

See: https://github.com/containers/netavark/issues/115

Error in creating container

➜  ~ cat /etc/redhat-release
Fedora release 36 (Thirty Six)
➜  ~ uname -r
5.18.17-200.fc36.x86_64
➜  ~ uname -a
Linux localhost.localdomain 5.18.17-200.fc36.x86_64 containers/podman#1 SMP PREEMPT_DYNAMIC Thu Aug 11 14:36:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

➜  ~ podman network ls
NETWORK ID    NAME        DRIVER
88c9b7b61afd  kind        bridge
2f259bab93aa  podman      bridge
➜  ~ podman inspect kind
[
     {
          "name": "kind",
          "id": "88c9b7b61afd09229a54869e7f3603416f588848f71343ee2706ca1dc21c1d49",
          "driver": "bridge",
          "network_interface": "podman1",
          "created": "2022-08-21T00:14:12.41086239+08:00",
          "subnets": [
               {
                    "subnet": "fc00:f853:ccd:e793::/64",
                    "gateway": "fc00:f853:ccd:e793::1"
               },
               {
                    "subnet": "10.89.0.0/24",
                    "gateway": "10.89.0.1"
               }
          ],
          "ipv6_enabled": true,
          "internal": false,
          "dns_enabled": true,
          "ipam_options": {
               "driver": "host-local"
          }
     }
]
➜  ~ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:03:5e:28 brd ff:ff:ff:ff:ff:ff
    inet 172.28.28.121/20 brd 172.28.31.255 scope global dynamic noprefixroute eth0
       valid_lft 85030sec preferred_lft 85030sec
5: podman1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 62:a5:c2:5f:89:9b brd ff:ff:ff:ff:ff:ff

➜  KIND_EXPERIMENTAL_PROVIDER=podman sudo kind create cluster --config ./config.yml
enabling experimental podman provider
Creating cluster "kind" ...
 ✓ Ensuring node image (localhost/kindest/node:22.10.20220801.1.24.3) 🖼
 ✗ Preparing nodes 📦 📦
ERROR: failed to create cluster: command "podman run --name kind-control-plane --hostname kind-control-plane --label io.x-k8s.kind.role=control-plane --privileged --tmpfs /tmp --tmpfs /run --volume 29eb75650a9b89f0032582a1d5930ac072f5dc8c4bd692a8a87255ebb184196b:/var:suid,exec,dev --volume /lib/modules:/lib/modules:ro -e KIND_EXPERIMENTAL_CONTAINERD_SNAPSHOTTER --detach --tty --net kind --label io.x-k8s.kind.cluster=kind -e container=podman --volume /dev/mapper:/dev/mapper --publish=127.0.0.1:43279:6443/tcp -e KUBECONFIG=/etc/kubernetes/admin.conf localhost/kindest/node:22.10.20220801.1.24.3" failed with error: exit status 126
Command Output: Error: netavark: failed to configure bridge and veth interface: failed while configuring network interface: failed to set ip address to podman1: Permission denied (os error 13)

I've taken a stab at a proof of concept first -- as said in the issue about port 53 shouldn't be used (link below) it seems simple enough to use DNAT for this.

This WIP version has at least two problems:

• I've hardcoded port 1153 as alternative port, we should either use an ephemeral port (problem: we can't know if it's free unless we try to bind to it, so we'd need some retry...) or simpler just make it configurable at network level as a driver-specific option. I'd favor the later.
• I'm not actually checking if dns settings are enabled to create the forward rule, that should obviously be checked.

Is there anything else I missed?

Fixes: https://github.com/containers/aardvark-dns/issues/13

Netavark now does not double-forks aardvark-dns's server instead it waits for aardvark-process to return back and success return means aardvark-dns is ready to serve requests and now forking happens at aardvark end.

See: https://doc.rust-lang.org/std/process/struct.Command.html#method.spawn

This needs: https://github.com/containers/aardvark-dns/pull/148

Should help in:

• https://github.com/containers/podman/issues/14173
• https://github.com/containers/podman/issues/14171

Alternative to: https://github.com/containers/netavark/pull/300

repro:

sudo podman network create macvtest -d macvlan --subnet=fd22::/16
sudo podman run --net=macvtest:ip=fd22::3 docker.io/nginx 

In a second window run:

sudo nsenter -t $(pgrep nginx | tail -n1) -p -n ip -6 a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
27: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 censored-slaac-address/64 scope global tentative dynamic mngtmpaddr 
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 fd22::3/16 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 fe80::28a7:41ff:feb3:9497/64 scope link 
       valid_lft forever preferred_lft forever

looks ok, now ctrl+c the nginx and start it again. sudo nsenter -t $(pgrep nginx | tail -n1) -p -n ip -6 a now shows:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
28: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 censored-slaac-address/64 scope global dynamic mngtmpaddr 
       valid_lft 2591990sec preferred_lft 604790sec
    inet6 fd22::3/16 scope global dadfailed tentative 
       valid_lft forever preferred_lft forever
    inet6 fe80::54c8:36ff:fe70:2b5b/64 scope link 
       valid_lft forever preferred_lft forever

Notice the dadfailed on eth0. Does this need to be released somehow?

Prior to this commit, CI ran entirely in a container environment. This was very much less than ideal, since actual network/firewall manipulations could not be exercised. With this commit, everything will execute on the same VM images and image-build workflow used by all the other containers-org project automations.

Note: Given all other projects generally use golang, the VM images here are NOT tailored to a rust project. Unfortunately that means performing runtime updates/installs and using cache to reduce the dnf repo. Metadata/package downloading. These aspects can be removed once dedicated netavark VM images are realized and implemented in a future commit.

Implements teardown which is responsible for removing container interfaces and performing cleanups.

Usage

netavark -f <config> teardown <networknamespace>

Explicitly required kernel parameters like accept_ra and accept_dad are only needed for interface when we are using ipv6 not ipv4.

Standard netavark configuration has a field ipv6_enabled which should be enough for us to propagate configuration to lower utility functions in the stack.

• We should avoid overriding configs when another instance of aardvark is trying to commit configs on the same path.

• On certain system a race exists where more than one aardvark instance are started in the frame where one instance has not yet completed updating its aardvark.pid causing more than one instance to get started and eventually causing conflits on the requested ports.

Some conditions are reported on low power hardware which tries to start a significant amount of containers and it looks like the case matches with what is described in the second point.

Bumps tokio from 1.23.0 to 1.24.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps zbus from 3.6.2 to 3.7.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

After reporting a problem with podman-compose (https://github.com/containers/podman-compose/issues/609) that outputs error:

Error: unable to start container 945f51fa502fc70dfc60ea2b05a2497d6fc0b09506641eadd68cd7e1d6b740a7: netavark: No such file or directory (os error 2)

I have found with strace that the missing file was iptables. Debian podman package (https://packages.debian.org/bookworm/podman) only suggests iptables package therefore it is not installed by default.

My suggestion is to append the missing file/directory name to the netavark error for easier debugging.

Bumps netavark_proxy from e38a730 to dccc2db.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps clap from 3.2.23 to 4.0.32.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hi,

I am not sure this is the right place to ask nor do I know whether this is unexpected for you, but I would like to get your point of view on the following problem I encountered:

I am in the middle of moving Docker container workloads to podman 4.3.1 using netavark as network backend. Some containers are still running in docker, while another one, a postgresql database that for dubious reasons exposes its database to the host port and to another container on its own network, has been moved to podman. When Docker is not running, assigning the database container to the network, while publishing port 5432 on the host using -p 5432:5432 works exactly as expected (meaning: pointing an external postgresql client to the host works as if the database is running on the host). However, when I start Docker, the port forward on the host to the podman container stops working. Connecting directly to the database container still works. None of the containers still running in Docker publish to the host's port (not to port 5432 nor to any other one).

My guess is that Docker overwrites the port forward in the firewall to the podman container. I do not know how to debug this further or fix this though. Do you have ideas/remarks/workarounds that could support this hybrid situation until all of them have been moved to podman?