Why does no one talk about IPv6 this day and age?
Came here to say this. ULA would have been stacks better than this.
Container networking is simple (2020)
31–40 of 68 posts
Re: Container networking is simple (2020)
#32I 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 increased, but his enthusiasm for talking about them has gone up, so I guess that's a win.
Re: Container networking is simple (2020)
#33Earlier quoted context omitted.
Which defeats the purpose of containerization because now the container can sniff traffic on the host, hijack TCP connections, etc.
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 better secured than a VM (e.g. minimal Zones/jails env + correct MAC config vs. general Qemu/VMware VM with many default legacy devices and bad/no MAC config).
Motivated attackers can escape even these VMs. So they are not a magical solution.
Common hypervisors are too big and buggy to be pronounced as security panacea. 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.
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.
> 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.
Joyent does - via SmartOS zones.
Re: Container networking is simple (2020)
#34This 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…
> 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)
Re: Container networking is simple (2020)
#35This is a very good article.
Container networking is as simple as linux networking, which isn't.
Its as much of a faff now as it was when I was doing KVM virtualisation professionally (don't, pay and use VMware. You'll be much happier, and have lots of free time)
To debug its a massive arse and lacks any useful and friendly debugging tools.
One thing that does help is either to use VLANs or a second adaptor to separate container traffic from control. It makes debugging slightly easier. By easier, I mean that when you accidentally misconfigure it, there is a better chance that you'll be able to get control of the host still.
Re: Container networking is simple (2020)
#36This 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…
> 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)
Docker's custom iptables chains, upon restart of network or docker, can and most likely WILL clobber rules that used to work. Docker adds the DOCKER-USER user chain for the purpose of readding rules back after docker has set up its rules. Most engineers never have to deal with it unless they are deploying to production boxes.
Re: Container networking is simple (2020)
#37This 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…
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!
Re: Container networking is simple (2020)
#38This is a very good article. Container networking is as simple as linux networking, which isn't. Its as much of a faff now as it was when I was doing KVM virtualisation professionally (don't, pay and use VMware. You'll be much happier, and have lots of free time) To debug its a massive arse and lacks any useful and friendly debugging tools. One thing that does help is either to use VLANs or a second adaptor to separa…
Besides VLANs, another way to separate control and data plane traffic is using VRFs.
Re: Container networking is simple (2020)
#39Why does no one talk about IPv6 this day and age?
Maybe they find it too cumbersome to memorize and type an ipv6 address. Or grew up and cut their teeth on v4.
Re: Container networking is simple (2020)
#40This 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…
A -- "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."
B -- "Linux networking conventions change every few years and simplying keeping up with the basics is a chore. netplan is the current flavor of the week but it's still new to plenty of people who've never had to worry about anything more than auto-configured DHCP or cloud-provider-default VPS networking."
My perspective has been that "A" is directly leading to "B" for similar reasons new javascript frameworks keep being released. Linux networking conventions don't change rapidly (5 - 10 years) but new management tooling does get created alongside to sit next to existing tooling, already abstracted out OS tools have new tooling to further abstract out system management which just creates further unnecessary complexity.