rootless containers should have dedicated netns&veth under the singleton slirp4netns instance

[AkihiroSuda]

Is this a BUG REPORT or FEATURE REQUEST?:

[//]: # kind feature

Description

Rootless containers should use a singleton slirp4netns instance, and create dedicated netns (and veth) under the slirp4netns netns

Steps to reproduce the issue:

1. Create a rootless container

2. Create the second one

Describe the results you received:

Dedicated slirp4netns is created for each of the containers. i.e. the two containers cannot communicate to each other.

Describe the results you expected:

Only single slirp4netns should be launched, and dedicated network namespaces and vEths under the slirp4netns should be created for each of the containers.
The containers should be able to communicate via vEths.

[rhatdan]

@AkihiroSuda @giuseppe Any movement on this?

[giuseppe]

no, I am not sure about the design here and if having a single instance of slirp4netns is what we want

[AkihiroSuda]

Any other idea for supporting inter-container communication?

[giuseppe]

I think they should be set to run in the same pod

[mgoltzsche]

I agree when two containers should communicate on the same host ideally they should run in a pod. However the ability to make multiple pods communicate with each other provides more flexibility: Picture a Docker Compose project where multiple services use the same port and still communicate with each other. Now if you want to run this with podman you have to change the configuration or you even have to change the image.
Basically it means to lower the isolation between containers although you may not want to do this in every case or it just becomes cumbersome: You cannot simply add any new container/service and make it communicate with your existing ones without touching the latter.

I am facing the same problem in ctnr (I am thinking about stopping development in favour of podman):
Moving the whole container execution into a shared netns doesn't seem to be ideal since, while it just concerns rootless networking, it has a huge impact on the whole container engine design and may result in unnecessary complexity.
Thus I thought about implementing such a feature as a CNI plugin that executes other nested plugins within a shared, slirped netns - it is a network concern after all. This approach also has some drawbacks as the CNI plugin would need to implement some container engine specific features and manage one or multiple of such shared netns/containers implicitly. However it encapsulates this network-related logic behind CNI. lt would allow easy exchange in the future in case of new kernel features that may simplify everything. Also it would provide consistent usability with plain runc (since it can ensure that resources like a bridge's veth are released from the shared netns when a container is terminated using plain runc outside the shared netns). Correspondingly multiple projects could benefit from such a CNI plugin.

[giuseppe]

@AkihiroSuda is already working on exposing network ports to the slirp4netns network. Once that lands, we will be able to expose ports from the host to the network namespace of each pod/container we wish to. This is the way, IMO, for different containers/pods to communicate, only by a selected and controlled set of ports.

Said so, I agree on the CNI idea. It would be nice to enable support for CNI in rootless mode, so that these more complex configurations can be addressed as plugins.

[rhatdan]

@giuseppe Is this fixed, can't we close this?

[rhatdan]

Fixed in master.

[tmds]

@AkihiroSuda is already working on exposing network ports to the slirp4netns network. Once that lands, we will be able to expose ports from the host to the network namespace of each pod/container we wish to.

@AkihiroSuda Is there a way to expose a host port to a container? For example, I have nginx running on the host at localhost:80, can I make it accessible to a specific container?

[AkihiroSuda]

slirp4netns can expose localhost:80 on the host as 10.0.2.2:80 in the container, when slirp4netns process is not launched with --disable-host-loopback.
But Podman does not provide a way to launch slirp4netns without --disable-host-loopback AFAIK.

A hacky way would be like this (untested)

$ mv slirp4netns slirp4netns.real
$ cat > slirp4netns <<EOF
#!/bin/sh
set -eu
exec slirp4netns.real "$(echo $@ | sed -e s/--disable-host-loopback//g)"
EOF
$ chmod +x slirp4netns

[tmds]

@AkihiroSuda thank you for the info. I guess podman disables this by default for security. It would be nice to have a flag to expose the host loopback.

[AkihiroSuda]

PR: #7460