Re: Port forwarding for Guix containers

[edk]

The trick is that guix being written in scheme, operating system
declarations can be written in a composable way, where the port N can be
a parameter.

The way I see it, it is when you compose all your services together on
one host that you decide which service gets which port, and declare all
that in a single operating system declaration (which is made up of
modular, task specific, smaller OS declarations).

I don't know if I'm being clear. I can't provide code because I did not
have the time to do it yet, but this was my understanding of how guix works.

Jason Conroy writes:

> 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
>>
>>