Podman: Pasta User-Mode Networking
github.com
Podman: Pasta User-Mode Networking
1–10 of 28 posts
Re: Podman: Pasta User-Mode Networking
#2Re: Podman: Pasta User-Mode Networking
#3Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
Re: Podman: Pasta User-Mode Networking
#4Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
Because you want containers to be able to allocate ports that are already in use on your host. Or at least you don't want that to be a source of errors.
See https://medium.com/nttlabs/dont-use-host-network-namespace-f... for just an example of what can go wrong otherwise.
Re: Podman: Pasta User-Mode Networking
#5Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
SLIRP is mainly useful when you don't have (or don't want) root permissions to send raw packets. I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose: You have dial up access to a shared SunOS terminal login, how do you turn that into a full network connection for your local Linux PC? SLIRP (+ expect, SLIP and some scripting) solved this exact problem.
Passt (https://passt.top/passt/about/) is a more modern replacement for SLIRP that amongst other things fully supports IPv6 and is more secure architecturally (runs in a separate process, uses modern Linux mechanisms for isolation etc). There was a talk about it here: https://kvmforum2022.sched.com/event/15jJY/slirp-is-dead-lon...
This pull request is using Pasta which is something on top of Passt that does something with network namespaces which I'm not entirely clear on, but some docs here: https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...
Re: Podman: Pasta User-Mode Networking
#6Re: Podman: Pasta User-Mode Networking
#7Re: Podman: Pasta User-Mode Networking
#8This looks like a replacement for something called slirp4netns which is "User-mode networking for unprivileged network namespaces." I wasn't familiar with this or libslirp. Can someone say what the practical use-case is for User-mode networking? Is this just to complements Podman's existing security posture or something else?
To my understanding, yes. You can run Podman containers as non-root, but containers often have their own network namespace which would require root privileges to create without slirp4netns. I don't believe there are really practical reasons to use it beyond that pretty big one. It does (used to?) incur some performance hit even (but only at some multi-gb rate and even then only a fractional penalty IIRC). e: I was thinking about rootlesskit here, which is somehow combined with slirp4netns in some cases.
I remember looking into Pasta a while back when I wanted to get client-ip-addresses in a container and the current Podman implementation for user-networks obscures that value. I think this might fix that along with IPv6 and other improvements.
Re: Podman: Pasta User-Mode Networking
#9Re: Podman: Pasta User-Mode Networking
#10As an opensource lover, you gotta appreciate redhat registering a "containers" organisation with rh-only maintained projects. True OSS philosophy at work here!