From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id EMYuH3d/ul/lPwAA0tVLHw (envelope-from ) for ; Sun, 22 Nov 2020 15:10:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id OBl7Gnd/ul9tcQAAB5/wlQ (envelope-from ) for ; Sun, 22 Nov 2020 15:10:47 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7DC5594042C for ; Sun, 22 Nov 2020 15:10:46 +0000 (UTC) Received: from localhost ([::1]:50724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgr0n-0004fk-2g for larch@yhetil.org; Sun, 22 Nov 2020 10:10:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51270) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgr0O-0004ac-EY for help-guix@gnu.org; Sun, 22 Nov 2020 10:10:21 -0500 Received: from sender4-op-o13.zoho.com ([136.143.188.13]:17396) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgr0M-00025K-5Q for help-guix@gnu.org; Sun, 22 Nov 2020 10:10:20 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1606057812; cv=none; d=zohomail.com; s=zohoarc; b=Dnyb+UZiNOYJ91Td8IbV/mbexgCqonNrLjeDyhXmiG9JUY0erPiImhf0e1ITZ0m3JTle3QAWmX+vvwwdYJA7Pe8t2cwkTHVhrp5wcZ5e5ZvL4vhG+97hU19z2azx4qqEUzUfOfR8XIHnRWA3dSR1fPS6GM+vrpoGaB2shHAPhIA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1606057812; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=GllV2VHAT2VK8huER9cH5ekm1v+fR6Gpi+Ep3hUlx2M=; b=MX5tZDnTVgzpEGsgCjZnvB1HgsOirsYP99N2Ym4efRYrfVZMDpV/r39fcSKLzzeCoHM84QGTIeGWzkpyo10TrJbyZmPj6QrdsiDl2tAnpZPajddNKXfrwB6yXTbmMVJ2eoWM9utxcSJQMLfbq//oyrnlafygpMD3gWD3Q4BFl4Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=beaver-labs.com; spf=pass smtp.mailfrom=edk@beaver-labs.com; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1606057812; s=zoho; d=beaver-labs.com; i=edk@beaver-labs.com; h=References:From:To:Subject:In-reply-to:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=GllV2VHAT2VK8huER9cH5ekm1v+fR6Gpi+Ep3hUlx2M=; b=gHdfav2UhZPPpsZ6yDn0AWbeU3UyndkzgHTw8NbOdYrh7uAsOwDHzsAOkmTlALDI U0tDiEkjGafZEnTpvKe2x47dnyUq8iecaZm0gZewu+PwNt/IKZCjcwgIKRoPkO/5Mr8 qrjL//ptaW8uvGXBiSoTcUeI7g9oKnehkNq/FDeU= Received: from Rasoir (lfbn-idf3-1-205-14.w90-22.abo.wanadoo.fr [90.22.204.14]) by mx.zohomail.com with SMTPS id 1606057809986180.93866543140882; Sun, 22 Nov 2020 07:10:09 -0800 (PST) References: <28690cfe.8dc4.175e13a4596.Coremail.all_but_last@163.com> <871rgnltiv.fsf@cbaines.net> <86r1omkbgk.fsf@gmail.com> User-agent: mu4e 1.4.4; emacs 27.1 From: edk@beaver-labs.com To: help-guix@gnu.org Subject: Re: Port forwarding for Guix containers In-reply-to: Message-ID: <87y2itqvgl.fsf@rdklein.fr> Date: Sun, 22 Nov 2020 16:09:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.13; envelope-from=edk@beaver-labs.com; helo=sender4-op-o13.zoho.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none (invalid DKIM record) header.d=beaver-labs.com header.s=zoho header.b=gHdfav2U; arc=pass (zohomail.com:s=zohoarc:i=1); dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-Spam-Score: -2.01 X-TUID: wWbXg6t8SOmk 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 t= he > container host itself). > > Aside from the risk that one container's port bindings will prevent anoth= er > 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 > > 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 t= he > -N flag, its services will bind to the virtual interface inside the netwo= rk > 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 a= re > a couple of options. One is to enable port forwarding from the host's > external interface to the container's IP address 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 wrote: > >> Hi, >> >> On Fri, 20 Nov 2020 at 19:26, Christopher Baines wrot= e: >> > Zhu Zihao 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 whatev= er >> > 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 =E2=80=9Cguix environment=E2=80=9D. On= e point is that >> Docker [1] provides a way to specify the firewall rules. Well, somehow, >> something similar as =E2=80=99--share=E2=80=99 but for network. >> >> >> 1: >> >> All the best, >> simon >> >>