From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aD7RADPOu1/0AQAA0tVLHw (envelope-from ) for ; Mon, 23 Nov 2020 14:58:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id EKM8ODLOu19bRwAAbx9fmQ (envelope-from ) for ; Mon, 23 Nov 2020 14:58:58 +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 740ED9402A0 for ; Mon, 23 Nov 2020 14:58:58 +0000 (UTC) Received: from localhost ([::1]:48550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khDIv-0008Pt-9b for larch@yhetil.org; Mon, 23 Nov 2020 09:58:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khDIn-0008Pf-BY for help-guix@gnu.org; Mon, 23 Nov 2020 09:58:49 -0500 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:36246) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1khDIk-00076e-Mn for help-guix@gnu.org; Mon, 23 Nov 2020 09:58:49 -0500 Received: by mail-ej1-x633.google.com with SMTP id o21so23688421ejb.3 for ; Mon, 23 Nov 2020 06:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/2ow5OUyTHJtakeaSpyreCkQsJaPqjWI1yU9RTVkCi4=; b=k3khtuwqgSVmp2U7xRA6JfvPOvUZomctPo0zIyntIAjuknEpg3IGNdlfRfthAlGe2S 08r2errXwm4kYxpGJmJxLYY72n4TAZlP7AOIlkx707JKNNwG8lhA3FDxXMO0Ur3Znis+ 7sngNJ8Y7SCijChryis+tkCAeswJDCzOnAioVdyuVjBQMeY1/sA6rYk+MczQVE/wixCl 8M2anK0NTApqtNaqYfml9zz36/B155C9lv14nbPoo12LbCx4qX/U6N1fn/Hvl5qei9PX 12EUu2/+wTxfxhTRlXdbbveys/6RTAoKwDUF2sjgX91YJa5UFLcZWNDtDD8OAAw8yG+h Jk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/2ow5OUyTHJtakeaSpyreCkQsJaPqjWI1yU9RTVkCi4=; b=olcMyWX1d3U6zvmyZv7iNoX7MhC73Fxs80EjE0swSBoqW9jspzU18XRPlhL+DphKMf qEBcUZH0aLNZV4jqA63Zfdi4RyUKzSWpxx+of1WTyr4dqZ1Q1Yo3GjAMW2bynqzpgSEW Dl19in4w8pKf/IPijDrzi+fbpLN6ceFXDE7kqRofK550yd5uIQ03SlqVwBeBWlqKN5Vg ir4v1EKytJbRlwb3xyBYBa2/3D0V71axm9SiFnP2RUlfIm6L52Zh3I54gj/ge8FQeYsV wT18Y6zNQMm4xMQMc4JrsBlrsPyHQ9WI2atvUPoUXhU26+MznY8K5g4zHgtbw/Ry9hxL Qgcw== X-Gm-Message-State: AOAM531yo4zZOaNQCOTG9KFx6hrMIsNb4Av5UOTJDFWK6fLB6zWJ5ViR 7FIFdd/+jkQ+RlaFCmgqJ3qCWI8WzlC1HzF4zeA= X-Google-Smtp-Source: ABdhPJwyl6eUTds4htJ+ieiYgstUisTcHeE2yB6wtNmiPzWj2acw5O4woEg8LRkdGyFXSZjeN1A2/D8dRTG0F88NjXs= X-Received: by 2002:a17:906:179a:: with SMTP id t26mr17427037eje.49.1606143524657; Mon, 23 Nov 2020 06:58:44 -0800 (PST) MIME-Version: 1.0 References: <28690cfe.8dc4.175e13a4596.Coremail.all_but_last@163.com> <871rgnltiv.fsf@cbaines.net> <86r1omkbgk.fsf@gmail.com> <87y2itqvgl.fsf@rdklein.fr> In-Reply-To: <87y2itqvgl.fsf@rdklein.fr> From: Jason Conroy Date: Mon, 23 Nov 2020 09:58:08 -0500 Message-ID: Subject: Re: Port forwarding for Guix containers To: edk@beaver-labs.com Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=conjaroy@gmail.com; helo=mail-ej1-x633.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: , Cc: help-guix@gnu.org 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=fail (body hash did not verify) header.d=gmail.com header.s=20161025 header.b=k3khtuwq; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 0.09 X-TUID: 29J7Xah1b/gM Hi Edouard, I completely agree that this sort of composition is convenient for a group of services that share a single dependency graph. For example, when deploying a web application in a container, one could also provide an nginx server there for its exclusive use, and maybe even a database server (if the db doesn't have other clients). But when it comes to deploying separate, unrelated applications (or isolated instances of an app, like Production and Testing), I believe that development, testing, and maintenance are all simplified by keeping the containers separate. For example, after a `guix pull` with a major package update, I might want to rebuild a single application container and test the new package there. The alternative is to bring down all applications, upgrade them all, test them all, and roll back everything if there's at least one issue. When there are many applications, this doesn't scale well. I guess I see `guix system container` as analogous to `guix environment` in this regard: a single environment may contain many binaries that work together, but users are encouraged to set up different environments for Project A and Project B. I'm not sure whether Zihao's situation is similar, but that's my perspective. :) Jason On Sun, Nov 22, 2020 at 10:10 AM wrote: > > 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 hen= ce > > 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 fa= il > > 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 i= n > > 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 dependencie= s: > > we might start a container thinking that it's self-contained, when real= ly > > it depends on a service belonging to the container's host or to another > > container. This is why I consider the shared namespace a reproducibilit= y > > problem. > > > > Lately I've been experimenting with a modified version of this script > > < > https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99#file-ns-in= et-sh > > > > to set up a network namespace with its own interface and routes, and th= en > > 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, whil= e > > 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 > > . 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 bot= h > 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 > wrote: > >> > Zhu Zihao writes: > >> > > >> >> I found guix container "created by `guix environment --container` o= r > >> >> `guix system container`" is very useful to isolate some service. Bu= t > >> >> it only supports fully isolated network namespace or just share wit= h > >> >> 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, fo= r > a > >> > shared network namespace, what threats is that not safe in respect t= o? > >> > > >> > 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. = One point is that > >> Docker [1] provides a way to specify the firewall rules. Well, someho= w, > >> something similar as =E2=80=99--share=E2=80=99 but for network. > >> > >> > >> 1: > >> > >> All the best, > >> simon > >> > >> > > >