| ▲ | anygivnthursday 2 hours ago | ||||||||||||||||
Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance. | |||||||||||||||||
| ▲ | dwroberts an hour ago | parent | next [-] | ||||||||||||||||
I see the ‘not a security boundary’ thing repeated constantly, and while it makes sense (eg. they’re sharing the underlying kernel or at least some access to it) if you think about it a little more, VMs are not magically different: they are better isolated, but VMs on the same host still share the host in common. A CVE next week that allows corruption of host state that affects eg every VM under a particular hypervisor will be no less damaging than this CVE is to containers | |||||||||||||||||
| |||||||||||||||||
| ▲ | ButlerianJihad 2 hours ago | parent | prev [-] | ||||||||||||||||
Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but those containers are still dragging around legacy dependencies, by design. Is your backup system aware of containers and capable of creating backup images or files, that are suitable for restoring back to service? | |||||||||||||||||
| |||||||||||||||||