Live data from Hacker News

Container networking is simple (2020)

iximiuz.com

61–68 of 68 posts

Re: Container networking is simple (2020)

#61
post #25

Earlier quoted context omitted.

I have to say, it would be cool if they did. If I could get a dirt-cheap rate for running batch workloads in a potentially antagonistic environment, I could make use of that. Not all data is sensitive.

It is how Heroku has operated since forever. Containers can be secure.

I didn't know that about Heroku. They give you a choice:

> Performance and Private dynos do not share the underlying compute instance with other dynos

https://devcenter.heroku.com/articles/dynos#isolation-and-se...

Re: Container networking is simple (2020)

#62
post #33

Earlier quoted context omitted.

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,…

You won't hear much about the VM escapes in those clouds because there is strong incentive for almost everyone to be quiet about them and patch as soon as possible so there "isn't a story". Some researchers do want to make a name for themselves and publish before the patch, but those are minority. And publicly attacking a big corporation is quite risky so they prefer presenting the bug as general problem in the technology. But the bugs in hypervisors exist, see CVE's for Xen for the past decade.

See also

https://security.stackexchange.com/questions/130274/how-do-b...

https://nakedsecurity.sophos.com/2015/05/14/the-venom-virtua...

Regarding L4, I do not know. Probably it is very different and cumbersome to work with compared to linux.

Re: Container networking is simple (2020)

#63
post #62

Earlier quoted context omitted.

> 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,…

You won't hear much about the VM escapes in those clouds because there is strong incentive for almost everyone to be quiet about them and patch as soon as possible so there "isn't a story". Some researchers do want to make a name for themselves and publish before the patch, but those are minority. And publicly attacking a big corporation is quite risky so they prefer presenting the bug as general problem in the techn…

> Some researchers do want to make a name for themselves and publish before the patch, but those are minority. And publicly attacking a big corporation is quite risky so they prefer presenting the bug as general problem in the technology.

That doesn't sound right to me. The industry norm for security research is 'responsible disclosure', which is intended to give the vendor reasonable time to implement the fix, while eventually publishing the knowledge for all to know.

Unless they're simply being paid for their silence, I can't imagine a security researcher wanting to keep quiet about a major achievement like that.

> bugs in hypervisors exist, see CVE's for Xen for the past decade

Sure, but I'm talking specifically about the big 3 cloud providers, not vanilla Xen. Amazon in particular have gone to pretty extreme lengths with their Nitro system.

Re: Container networking is simple (2020)

#64

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…

Strangely there is no current books for the state of the art Linux networking.

Here are a few and far between books on Linux networking but they are seriously outdated [1][2]. I think it's about time someone write an authoritative book on Linux networking in the light of the recent changes on Netfilter, bpfilter, eBPF and LXC container.

[1] Linux Kernel Networking: Implementation and Theory, 2013

[2] Linux Routers: A Primer for Network Administrators, 2nd Edition, 2002

Re: Container networking is simple (2020)

#65
post #37

Earlier quoted context omitted.

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…

https://access.redhat.com/documentation/en-us/red_hat_enterp... though it's a bit task based http://policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html but chapter 4 which introduces/explains how to use the ip command never got written!

Correction: chapter 4 is in the printed book. On the web site, it's found at http://policyrouting.org/iproute2-toc.html. The links from the other chapters of the web site don't work but browsing the ToC of the book, it looks like this link on the web site has all the info from the book plus a bit more...

Re: Container networking is simple (2020)

#66
post #56
post #23

Earlier quoted context omitted.

Long live wicked, easily managed with Yast on OpenSuse.

Yes, but how do you manage it without yast?

try: wicked --help

... but the beautiful thing about yast, is you get the interface via gui or console and it's largely identical.

Re: Container networking is simple (2020)

#67

Earlier quoted context omitted.

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?

Well, I first checked /etc/resolv.conf which told me to change the dns settings in systemd. So I read up on the systemd documentation and tried to change the dns setting using systemd-resolved but got a permissions error. So I did a bunch of reading online and found out that netplan is actually used to configure the dns so I spent some time reading the netplan documentation on how to change the dns server. This process took me about an hour.

Re: Container networking is simple (2020)

#68
post #32

I know a guy, he hated networking, so he decided to set up a kubernetes cluster on his home server to abstract all his networking difficulties away. Now he occasionally complains that the network inside the network inside the network is annoying because it doesn't play nicely with the network outside the network on top of the main network. Overall I feel the rate at which he talks about networking issues has increase…

Yeah, I feel cursed by the same habit. I get to about a 75% understanding of a domain and feel like I'm about to run out of things to learn...so I expand the domain and continue until I'm at that 75% mark again...and repeat...
Post reply on HN