Re: [lxc-users] Unprivileged networking option?
Thanks very much to all and sorry for the delay. > The /etc/lxc/lxc-usernet file was designed to be flexible > enough to one day support other types. It's just noone has done it > because noone's needed it. That very much answers my question to the point. While you mentioned plain lxc instead of lxd earlier, lxd might be more suitable for you needs. Does https://stgraber.org/2017/06/15/custom-user-mappings-in-lxd-containers/ fit the bill? Look for "isolated" Reading the link provided, I do not really see any difference to lxc at all? And in addition it does not seem to mention nonprivileged networking. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On Thu, Mar 05, 2020 at 06:46:06PM +0100, Ede Wolf wrote: > Am 05.03.20 um 03:20 schrieb Serge E. Hallyn: > > and you currently > > need a privileged lxc-user-nic to setup network. > > Thanks, as that basically sums up my question, as this lxc-user nic only > seems to work with a standard bridge. Currently. The /etc/lxc/lxc-usernet file was designed to be flexible enough to one day support other types. It's just noone has done it because noone's needed it. > Unless I am misinformed, which was > actually my hope. Or maybe there is something in the make to make this > lxc-user nic play along with macvlan or ipvlan. Not yet. > > By intercepting network connection related syscalls, > > you can avoid the need for privileged lxc-user-nic. > > This sounds more like hackish thing or is this interception part of lxc that > can be utilized? Any mere mortal compatible documentation on this? It sounds hackish because it's not nicely wrapped up for you yet. The whole container runtime was a hackish thing not much more than 10 years ago. > And a correction to my former post: it's ipvlan layer 3, not level 3 of > course. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On Thu, Mar 5, 2020 at 11:43 PM Ede Wolf wrote: > > Hello Andrey, > > thanks for getting back to me. The reason for unpriviledged containers > is basically user id separation. > > I fancy the idea that each container has its own id (range) and the user > ids are not being shared between containers (and the host). > > So it is another level of isolation and administration - in its simplest > form be it just using "ps" where you can tell from the user id what > container (os) the process belongs to. While you mentioned plain lxc instead of lxd earlier, lxd might be more suitable for you needs. Does https://stgraber.org/2017/06/15/custom-user-mappings-in-lxd-containers/ fit the bill? Look for "isolated" > > > More into classical os level virtualisation (jails, openvz) than what > is usually associated these days with the term "container". > So there is no respawning, no stacked images, no orchestration, but a > proper (albeit minimal) os installation. Without the overhead of a > hypervisor. > > So lxc pretty much is the right tool. Would just be great if one could > use level3 ip-vlan for easier filtering. https://discuss.linuxcontainers.org/t/lxc-3-2-1-has-been-released/5322 Look for "ipvlan". You could also use nested lxd, so (for example) each user have access to their own lxd container, with isolated idmap. Inside each container, They can create and manage their own containers. -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
Am 05.03.20 um 03:20 schrieb Serge E. Hallyn: and you currently need a privileged lxc-user-nic to setup network. Thanks, as that basically sums up my question, as this lxc-user nic only seems to work with a standard bridge. Unless I am misinformed, which was actually my hope. Or maybe there is something in the make to make this lxc-user nic play along with macvlan or ipvlan. > By intercepting network connection related syscalls, > you can avoid the need for privileged lxc-user-nic. This sounds more like hackish thing or is this interception part of lxc that can be utilized? Any mere mortal compatible documentation on this? And a correction to my former post: it's ipvlan layer 3, not level 3 of course. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
Hello Andrey, thanks for getting back to me. The reason for unpriviledged containers is basically user id separation. I fancy the idea that each container has its own id (range) and the user ids are not being shared between containers (and the host). So it is another level of isolation and administration - in its simplest form be it just using "ps" where you can tell from the user id what container (os) the process belongs to. More into classical os level virtualisation (jails, openvz) than what is usually associated these days with the term "container". So there is no respawning, no stacked images, no orchestration, but a proper (albeit minimal) os installation. Without the overhead of a hypervisor. So lxc pretty much is the right tool. Would just be great if one could use level3 ip-vlan for easier filtering. Am 04.03.20 um 21:37 schrieb Andrey Repin: Greetings, Ede Wolf! So please let me rephrase my question: Is there any alternative to standard bridging for running unprivileged lxc containers? Is there a use case for unprivileged LXC containers? I fail to see one, and I'm using LXC for five-or-so years. If you are using bare LXC, you are likely spawning new ones infrequently and each have its own unique purpose. If that's not true, you're better off using LXD/docker-swarm/etc. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On Wed, Mar 04, 2020 at 11:37:32PM +0300, Andrey Repin wrote: > Greetings, Ede Wolf! > > > So please let me rephrase my question: Is there any alternative to > > standard bridging for running unprivileged lxc containers? > > Is there a use case for unprivileged LXC containers? > I fail to see one, and I'm using LXC for five-or-so years. If you are using > bare LXC, you are likely spawning new ones infrequently and each have its own > unique purpose. If that's not true, you're better off using > LXD/docker-swarm/etc. https://www.youtube.com/watch?v=J34UzHo4G5w For starters, awesome as lxd is, it doesn't qualify as fully unprivileged containers, because the containers are *started* by root. With lxc containers you can get very close. You need setuid-root newuidmap and newgidmap to create userid mappings, and you currently need a privileged lxc-user-nic to setup network. By intercepting network connection related syscalls, you can avoid the need for privileged lxc-user-nic. And yeah, while I use lxd for spawning containers on remote hosts, I use lxc on my own home server and my laptop. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
Greetings, Ede Wolf! > So please let me rephrase my question: Is there any alternative to > standard bridging for running unprivileged lxc containers? Is there a use case for unprivileged LXC containers? I fail to see one, and I'm using LXC for five-or-so years. If you are using bare LXC, you are likely spawning new ones infrequently and each have its own unique purpose. If that's not true, you're better off using LXD/docker-swarm/etc. -- With best regards, Andrey Repin Wednesday, March 4, 2020 23:35:10 Sorry for my terrible english... ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
Thanks for the heads up, I have missed to mention, that I have been talking about simple LXC containers. Somehow implied it as default due to the name of this list. Sorry for that. So please let me rephrase my question: Is there any alternative to standard bridging for running unprivileged lxc containers? Thanks Ede Am 28.02.20 um 19:57 schrieb Mike Wright: On 2/28/20 5:34 AM, Ede Wolf wrote: Hello, do we have any alternatives to classical bridging right now for connecting (to) unprivileged containers? Like macvlan or ipvlan? If so, I may haved missed the documentation, otherwise, are there any plans to incorporate those options? Or maybe there are sound reasons not do at all? Containers are unprivileged by default. https://lxd.readthedocs.io/en/latest/instances/#nictype-ipvlan https://lxd.readthedocs.io/en/latest/instances/#nictype-macvlan ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On Fri, Feb 28, 2020 at 08:12:17PM +0100, Christian Brauner wrote: > On February 28, 2020 8:09:45 PM GMT+01:00, "Serge E. Hallyn" > wrote: > >On Fri, Feb 28, 2020 at 02:34:25PM +0100, Ede Wolf wrote: > >> Hello, > >> > >> do we have any alternatives to classical bridging right now for > >connecting > >> (to) unprivileged containers? Like macvlan or ipvlan? > >> > >> If so, I may haved missed the documentation, otherwise, are there any > >plans > >> to incorporate those options? Or maybe there are sound reasons not do > >at > >> all? > > > >Hi, > > > > > >There are a few places where Dinesh has done presentations like > > > > https://ostconf.com/en/materials/2478 > > > >about the idea of intercepting some core networking calls in > >containers, > >from the container runtime. As a very barbaric example, you could run > >the container under ptrace, intercept connect() and bind() calls, do > >those > >actions on their behalf in the parent namespace, pass the sockets back, > >and allow the container to proceed as if it had done the connection > >itself. > >The somewhat recent seccomp-ptrace stuff should make that much more > >civilized. > > > >-serge > >___ > >lxc-users mailing list > >lxc-users@lists.linuxcontainers.org > >http://lists.linuxcontainers.org/listinfo/lxc-users > > You know I've landed pidfd_getfd() too, right? :) > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8649c322f75c96e7ced2fec201e123b2b073bf09 sweet. but have you put it all together and put a bow on it yet :) thanks, -serge ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On February 28, 2020 8:09:45 PM GMT+01:00, "Serge E. Hallyn" wrote: >On Fri, Feb 28, 2020 at 02:34:25PM +0100, Ede Wolf wrote: >> Hello, >> >> do we have any alternatives to classical bridging right now for >connecting >> (to) unprivileged containers? Like macvlan or ipvlan? >> >> If so, I may haved missed the documentation, otherwise, are there any >plans >> to incorporate those options? Or maybe there are sound reasons not do >at >> all? > >Hi, > > >There are a few places where Dinesh has done presentations like > > https://ostconf.com/en/materials/2478 > >about the idea of intercepting some core networking calls in >containers, >from the container runtime. As a very barbaric example, you could run >the container under ptrace, intercept connect() and bind() calls, do >those >actions on their behalf in the parent namespace, pass the sockets back, >and allow the container to proceed as if it had done the connection >itself. >The somewhat recent seccomp-ptrace stuff should make that much more >civilized. > >-serge >___ >lxc-users mailing list >lxc-users@lists.linuxcontainers.org >http://lists.linuxcontainers.org/listinfo/lxc-users You know I've landed pidfd_getfd() too, right? :) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8649c322f75c96e7ced2fec201e123b2b073bf09 ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On Fri, Feb 28, 2020 at 02:34:25PM +0100, Ede Wolf wrote: > Hello, > > do we have any alternatives to classical bridging right now for connecting > (to) unprivileged containers? Like macvlan or ipvlan? > > If so, I may haved missed the documentation, otherwise, are there any plans > to incorporate those options? Or maybe there are sound reasons not do at > all? Hi, There are a few places where Dinesh has done presentations like https://ostconf.com/en/materials/2478 about the idea of intercepting some core networking calls in containers, from the container runtime. As a very barbaric example, you could run the container under ptrace, intercept connect() and bind() calls, do those actions on their behalf in the parent namespace, pass the sockets back, and allow the container to proceed as if it had done the connection itself. The somewhat recent seccomp-ptrace stuff should make that much more civilized. -serge ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged networking option?
On 2/28/20 5:34 AM, Ede Wolf wrote: Hello, do we have any alternatives to classical bridging right now for connecting (to) unprivileged containers? Like macvlan or ipvlan? If so, I may haved missed the documentation, otherwise, are there any plans to incorporate those options? Or maybe there are sound reasons not do at all? Containers are unprivileged by default. https://lxd.readthedocs.io/en/latest/instances/#nictype-ipvlan https://lxd.readthedocs.io/en/latest/instances/#nictype-macvlan ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Unprivileged networking option?
Hello, do we have any alternatives to classical bridging right now for connecting (to) unprivileged containers? Like macvlan or ipvlan? If so, I may haved missed the documentation, otherwise, are there any plans to incorporate those options? Or maybe there are sound reasons not do at all? Thanks Ede ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
