Doc: Rootless Podman networked via WireGuard Client

[bbros-dev]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

This arose in the course of preparing series on rootless Podman related documentation for Vultr.
The first part is How to Install and Use Podman on Ubuntu 20.04.

This is likely a documentation example/feature.

There are many blog posts showing how to connect a (rootful)Docker container to WireGuard via the WG client on the Docker host .

It is useful to direct rootless container traffic via the hosts WireGuard, without directing all the hosts traffic via WG.

The WireGuard home page addresses Docker containers (rootful).

However, that approach, i.e. --network=ns:/var/run/netns/container, does not work with podman rootless containers - or at least I couldn't get it to work, and at least one other person also could not.
For other's coming this way issue #4473 is related, and the document rootless.md
The result there is:

podman run --network=ns:/var/run/netns/gitea-drone -it --rm busybox sh
Error: container_linux.go:349: starting container process caused "process_linux.go:319: getting the final child's pid from pipe caused \"EOF\"": OCI runtime error

This partially works when the client has AllowedIP=0.0.0.0/0, i.e. works only when all host traffic is sent tvia WG:

wg-quick up wgclient.conf
podman run --network=slirp4netns:outbound_addr=wgclient -it --rm busybox sh

It does not seem possible to route only the container traffic via WG, e.g. when AllowedIP=10.0.0.0/10, etc.
If this is correct, it should be documented.
If it is possible the settings could be documented - given WG is now part of the kernel.

Steps to reproduce the issue:

1. Set up WG server:

[Interface]
PrivateKey = ....
Address = 10.200.200.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; iptables -t nat -A POSTROUTING
-s 10.200.200.0/24 -o ens3 -j MASQUERADE; ping -c1 10.200.200.1
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE; ip6tables-D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE; iptables -t nat -D POSTROUTING -s 10.200.200.0/24 -o ens3 -j MASQUERADE
SaveConfig = true

[Peer] # gitea
PublicKey = ....
AllowedIPs = 10.200.200.3/32

2. Setup WG client

[Interface]
Address = 10.200.200.3/32
PrivateKey = .....

[Peer]
PublicKey = .....
Endpoint = <i.p.a.d>:51820
#AllowedIPs = 10.0.0.0/10
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21

Describe the results you received:

Rootless podman can connect via WireGuard only if the client setting is AllowedIPs = 0.0.0.0/0, that is all internet traffic on the Podman host is directed via WG.

Describe the results you expected:

To be able to direct the only rootless Podman container traffic via WG.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:      2.1.0
API Version:  2.0.0
Go Version:   go1.15.2
Built:        Thu Jan  1 10:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

NA

Package info (e.g. output of rpm -q podman or apt list podman):

$ apt list podman
Listing... Done
podman/unknown,now 2.1.0~1 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes, I have checked the troubleshooting guide.

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical

[bbros-dev]

Hmm, IIUC, this functionality is added by this commit f82abc7

$ podman network create foo
$ podman run -d --name web --hostname web --network foo nginx:alpine
$ podman run --rm --network foo alpine wget -O - http://web.dns.podman

So it may be possible to move the WG interface into the rootless podman generated netns? As opposed to creating a netns by hand as the WireGuard documents describes.
However, there is no indication whether the requirement, set out in this comment still applies.

Either way there does seem to be some documentation required:

Commit f82abc7 removes the rootless.md note on the lack of CNI support but I can't see where any documentation is added.

[mheon]

I'm going to guess here that you're seeing up the Wireguard network namespace as root and then trying to join it with rootless Podman? That won't work - the kernel won't let us join network namespace that are not a child of the rootless user namespace. You could attempt to do the configuration of the new network namespace from within a 'podman unshare' shell but I suspect you will also run into permissions issues there.

…

On Tue, Sep 29, 2020, 01:37 Begley Brothers (Development) < ***@***.***> wrote: Hmm, IIUC, this functionality is added by this commit f82abc7 <f82abc7> So it may be possible to move the WG interface into this is netns? However, there is no indication whether the requirement, set out in this comment <#4473 (comment)> still applies. $ podman network create foo $ podman run -d --name web --hostname web --network foo nginx:alpine $ podman run --rm --network foo alpine wget -O - http://web.dns.podman Either way there does seem to be some documentation required: Commit f82abc7 <f82abc7> removes the rootless.md note on the lack of CNI support but I can't see where any documentation is added. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCHHT4EQQAF4H2SOAC3SIFXCXANCNFSM4R5IP7WA> .

[bbros-dev]

you're seeing up the Wireguard network namespace as root and then trying to join it with rootless Podman?

Correct.

You could attempt to do the configuration of the new network namespace from within a 'podman unshare' shell but I suspect you will also run into permissions issues there.

Will try that.

[bbros-dev]

@mheon, Correct there are permissions issues trying to create the network namespace with the rootless Podman user namespace:

$ podman unshare
# ip netns add gitea-drone
Cannot create namespace file "/var/run/netns/gitea-drone": Permission denied
# sudo ip netns add gitea-drone
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"
sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0
sudo: fatal error, unable to load plugins

Would also be useful to document what the sudo setup might need to look like?

[rhatdan]

The issue here is the permissions on /var/run/netns/gitea-drone It has to be accessible Perhaps read/write by the user that is logged in. If the socket is owned by root:root with permissions like 0600, then the rootless user can not use it. Whether they are in a user namespace or not. When you do podman unshare, you are still your user, you don't gain access to anything extra on the system. You do gain access to the UIDs and GIDs listed in /etc/subuid, that is about it.

[bbros-dev]

The issue here is the permissions on /var/run/netns/gitea-drone It has to be accessible Perhaps read/write by the user that is logged in.

Hmm, interesting. Tried chown and chmod and always get Operation not permitted.
Something more funky - need to dig in when have the time. Right now running rootful with --user.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I am going to close, since I don't believe this is a podman issue.

[SuitespaceDev]

Though this is closed; I'll note that someone has managed to run rootless using a namespace from a pod created with --network=none to get around permission issues in subsequent pods

https://github.com/jcarrano/wg-podman