Re: Port forwarding for Guix containers

[Jason Conroy]

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.toutoune@gmail.com> wrote:

> Hi,
>
> On Fri, 20 Nov 2020 at 19:26, Christopher Baines <mail@cbaines.net> wrote:
> > Zhu Zihao <all_but_last@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
>
>