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