I agree with Zihao that containers have certain use cases where it's important to use separate network namespaces for each instance, with traffic forwarded selectively between host and guest. Security (and hence firewalling) is part of the issue, but it's also about the container's maintainability and reproducibility.
Supposing that we've developed some system container that starts a service on port N. If we want to run another instance of the same container, we first need to override the port number for the service in our operating-system, otherwise the service in the second container will fail to bind to port N in the shared network namespace. With a couple of one-service containers this may not be so hard, but system containers in general could have lots of services, and the authors of individual containers may not want to worry about choosing port numbers that are mutually disjoint from those in all other containers (and those used by the container host itself). Aside from the risk that one container's port bindings will prevent another container from working, there's also the risk of unintended dependencies: we might start a container thinking that it's self-contained, when really it depends on a service belonging to the container's host or to another container. This is why I consider the shared namespace a reproducibility problem. Lately I've been experimenting with a modified version of this script <https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99#file-ns-inet-sh> to set up a network namespace with its own interface and routes, and then run a guix system container inside. Because the container is built with the -N flag, its services will bind to the virtual interface inside the network namespace. Processes inside the container can access the internet, while processes on the host (but outside the container) can access the container services via the IP address bound to the container's interface. Next, to make the container's services accessible to other hosts, there are a couple of options. One is to enable port forwarding from the host's external interface to the container's IP address using iptables <https://www.systutorials.com/port-forwarding-using-iptables/>. If the container is hosting a web service, another choice (as Edouard mentions) is for the host to run some sort of reverse proxy that forwards incoming requests to the container's port. For example, nginx and Apache can both do this. It would be really nice if guix system containers had this namespacing ability built in, but it sounds complex. On Sat, Nov 21, 2020 at 10:03 AM zimoun <zimon.touto...@gmail.com> wrote: > Hi, > > On Fri, 20 Nov 2020 at 19:26, Christopher Baines <m...@cbaines.net> wrote: > > Zhu Zihao <all_but_l...@163.com> writes: > > > >> I found guix container "created by `guix environment --container` or > >> `guix system container`" is very useful to isolate some service. But > >> it only supports fully isolated network namespace or just share with > >> host, it's not so safe IMO. > > > > I'll assume that a fully isolated network namespace is safer in whatever > > way you're referring to than a shared network namespace. However, for a > > shared network namespace, what threats is that not safe in respect to? > > > > In the shared network namespace scenario, you are free to use a > > firewall, which could help protect against threats coming from other > > machines, for example by creating a list of IP addresses which are > > allowed to connect, and dropping any other traffic. > > I do not know about the initial motivation and I do not know either if > it makes sense in the context of “guix environment”. One point is that > Docker [1] provides a way to specify the firewall rules. Well, somehow, > something similar as ’--share’ but for network. > > > 1: <https://docs.docker.com/config/containers/container-networking/> > > All the best, > simon > >