Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Container networking is simple (2020)

iximiuz.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Container networking is simple (2020)

#51

Post by still_grokking »

caymanjim wrote: post #43
kenniskrag wrote: post #34

Earlier quoted context omitted.

> through your firewall in non-obvious ways. People don't realize that with a default Docker configuration, containers are ignoring any normal firewall rules you may have setup with iptables or ufw. What do you mean by non-obvious? If I bind a port of the container to the host eg. -p 8080:80 only this port is a hole. Do you have something different in mind? (I'm a docker beginner)

That alone is non-obvious. Docker adds prerouting and masquerade changes. They don't show up in the default iptables rule list (iptables -L). If you don't know about it creating the other tables it adds, and how to list them explicitly, you won't see these rules added. Docker binds to the public interface by default, rather than to much-safer private/localhost defaults. If you have an iptables INPUT DENY rule, it doe…

> The way Docker works is simply wrong.

And that's not only the networking. Everything about Docker is like that. It's a mess. Don't use.

Re: Container networking is simple (2020)

#53

Post by musicale »

It's not rocket science, but it's not entirely simple because there are a lot of moving parts, because IP networking is annoyingly complicated, and because we are stuck with IP addresses and interfaces that they are attached to, with many of these low-level details percolating up to user code. I like Linux's a-la-carte container APIs but their flexibility seems to increase complexity, as you end up dealing with multiple namespaces as well as cgroups, etc..

Then there are Kubernetes and Docker which add a lot of complexity on top, while providing some levels of abstraction which don't entirely eliminate the need for understanding the underlying internals.

Having some more mid-level container and networking APIs would be nice, but I'm not sure it would solve the complexity problem.

Guaranteed employment for networking/container/linux experts I guess.

Re: Container networking is simple (2020)

#55

Post by otterley »

zekica wrote: post #24

Why does no one talk about IPv6 this day and age?

IPv6 doesn't solve the difficulties of container networking. Containers have private network namespaces, which means that a container can't communicate with other hosts without (1) a dedicated interface or (2) a bridge (basically a software switch) for host-to-container communication.

These problems are Layer 2 problems, while IPv4 and IPv6 are at layer 3.

Re: Container networking is simple (2020)

#56

Post by mongol »

pnutjam wrote: post #23
stonesweep wrote: post #15

Earlier quoted context omitted.

> netplan is the current flavor of the week ... for Ubuntu, and Ubuntu only. It is an invention of Canonical not adopted by the rest of Linux distros (except Ubuntu derivatives), generally speaking.

Long live wicked, easily managed with Yast on OpenSuse.

Yes, but how do you manage it without yast?

Re: Container networking is simple (2020)

#58

Post by psibi »

skrtskrt wrote: post #22
caymanjim wrote: post #12

This is...not simple. I agree that container networking is not all that much different from other Linux networking, but that doesn't make it simple. A lot of application developers are switching to working with containers and haven't historically had to do any manual network configuration. It's all new to them. Linux networking conventions change every few years and simplying keeping up with the basics is a chore. ne…

Any good books on Linux networking? I have started spinning up “bare metal” k8s on a cloud VM and it’s not that hard to get going until you get to anything networking related then I feel like I’ve just jumped off a cliff. I have no knowledge there and the online resources seem to be nonexistent because you’re expected to just use a prebaked solution from cloud providers. I ended up just installing k3s but I have yet…

I was in the same boat and I found Michael Lucas book quite good for getting the practical working knowledge: https://books.google.co.in/books/about/Networking_for_System...

It tries to address the concepts and the book covers for multiple operating system like Windows, Linux, BSD and even has Some Solaris tidbits. :-)

Re: Container networking is simple (2020)

#59

Post by ohnemint »

__turbobrew__ wrote: post #46
tiew9Vii wrote: post #44

Earlier quoted context omitted.

I agree. I've had years of Linux experience and decided my home network + router was quite poor and I'd set up my own home network router and use OpenBSD to do it as an excuse to look at a BSD and fix my network issues. OpenBSD has been an absolute pleasure to work with. The man pages are well written and complete, the filesystem is well organized, having no issues that people have with Systemd the simplicity of Open…

I was amazed when my OpenBSD network config worked on the first try using only the man pages as reference. On the other hand it took me the better part of an hour to figure out how to change the DNS server used by an Ubuntu install.

> On the other hand it took me the better part of an hour to figure out how to change the DNS server used by an Ubuntu install.

Might I ask why/how exactly?

Re: Container networking is simple (2020)

#60

Post by MaxBarraclough »

effie wrote: post #33
MaxBarraclough wrote: post #21

Earlier quoted context omitted.

If you're running untrusted code in your container, you've pretty much already lost. Containers are useful for deployment and configuration, they are not a robustly secure sandbox. For that you still need to go with a VM. No cloud provider will offer to run your containers alongside other customer's containers, on a shared kernel. Your containers always run within your own VM.

No, it is levels of security, not a white/black issue. For some customers and providers, containered processes are enough isolation. For many small businesses, even shared hosting with chroot is enough. Generally speaking, Xen or Firecracker VMs do have smaller attack surface than containered processes on a shared Linux kernel. But configuration and exposed capabilities matter - it is possible to have container bette…

> From time to time, VM escapes resurface to public but most are probably guarded and being exploited in quiet. As we know after Spectre and Meltdown, standard computing technology is buggy/bugged all the way down to hardware.

To my knowledge there has never been a successful escape from the VMs offered by AWS, GCP, or Azure. That would be a pretty big story.

> If you want really "robustly secure" server environment, such do exist: for example, separation kernels like the L4 family or the Green Hills INTEGRITY systems. But for web apps, almost nobody bothers.

What's the reason none of the major cloud providers use seL4? Missing features? By seL4's own account their performance is exceptional, but perhaps its performance can't compete against a hardware-assisted system like AWS Nitro?

> Joyent does - via SmartOS zones.

Thanks I'd not heard of that.

Post reply on HN