Containers have security problems and flexibility issues. VMs will make them viable
(2021/06/22)
- Reference: 1624363211
- News link: https://www.theregister.co.uk/2021/06/22/containers_vs_vm_against_tue/
- Source link:
Register Debate Welcome to the latest Register Debate in which writers discuss technology topics, and you – the reader – choose the winning argument. The format is simple: we propose a motion, the arguments for the motion will run this Monday and Wednesday, and the arguments against on Tuesday and Thursday.
During the week you can cast your vote on which side you support using the embedded poll, choosing whether you're in favor or against the motion. The final score will be announced on Friday, revealing whether the for or against argument was most popular. It's up to our writers to convince you to vote for their side.
This week's motion is: [1]Containers will kill virtual machines
[2]
And now, today, arguing AGAINST the motion is DARREN YATES, a research scientist who just completed a PhD in machine learning and data science, and is a veteran technology journalist...
[3]
[4]
Remember when the PC was going to vanish if Microsoft didn't nail the next release of Windows? It turns out Global PC sales actually [5]rose 4.8% in 2020 . Write this off as a pandemic-induced aberration if you want, but as the global workforce gets a taste of working from home and likes it, this sort of ‘aberration’ proves yet again that once a good technology matures, it takes something revolutionary to replace it.
Now, it’s the turn of Virtual Machines (VMs) to supposedly fall at the hands of containers. The only trouble is, VMs go back even further than the PC to the early-1960s, which shows they have enduring value. Containers may well be here to stay, but it doesn’t mean you’ll be saying good-bye to VMs any time soon.
[6]
Why? Consider VMs’ versatility, for a start. By lifting the abstraction from the hardware layer up to the app layer, containers can be moved and distributed without worrying about the hardware they’re running on. That same abstraction also allows for deeper server utilisation because you don’t have the setup overheads of a VM with its full-blown guest OS. That much is given.
One compromised container endangers all of the other containers sharing the host kernel
However, abstracting at the app layer reduces versatility, since all containers on the host server are limited to sharing the same host OS kernel. Need to cross-develop for a different hardware platform or require a custom kernel? Containers on their own won’t help.
Abstracting only the lower hardware layer allows VMs to run a mix of different OSes and kernels on the same server. Sure, you lose some versatility in terms of server utilisation by siloing resources, but you gain it back by having greater control over the applications, kernels and OSes your server can run. (Then again, if you use Kubernetes, you might tap [7]KubeVirt to run your VM with your containers, provided your host supports nested virtualisation, but not all do).
In other words, it’s ‘swings and roundabouts’.
However, there’s another important benefit of VMs' lower-level abstraction: security.
[8]
Since containers share the resources of the host system, this makes them vulnerable to attack. One compromised container endangers all of the other containers sharing the host kernel, or those built from the same container image. In fact, several attack vectors have been identified by researchers –containers attacking each other, hosts attacked by malicious containers and vice versa. Even containers attacked by its own apps. It sounds like an Aliens movie.
Yet, by incorporating the OS layer in the virtual silo, VMs inherently add an extra barrier that isolates one VM from another, as well as from the host. Should a VM be attacked, that attack ends at the VM border – the system host and other VMs remain unaffected (notwithstanding some nasty side-channel attacks).
Nevertheless, it’s not surprising that one of the more active areas of industry and university research right now is improving container security.
For example, researchers at Cornell University developed [9]X-Containers to improve container isolation and performance by incorporating a Linux-based ‘library’ OS (LibOS), that bundles all of the OS services required by the container application into a library. This is then wrapped around by an exokernel, a lean, low-attack-surface kernel that isolates the containers from each other. Published performance results show good scalability, but an X-Container currently has a larger memory load and is slower to boot than a Docker container (but still faster than a full VM).
In the context of this debate, one of the more interesting solutions lining up to solve the container isolation issue is hypervisor-controlled containers or ‘microVMs’, where each container runs inside a lightweight VM with its own kernel. What you end up with is the security of a VM, but with the fast boot-times and lower resource requirements of a container.
Once a good technology matures, it takes something revolutionary to replace it
[10]Kata Containers are an OCI- and CRI-compliant open-source example evolved from Intel’s Clear Containers platform using QEMU/KVM VMs. Launched in 2018, Kata Containers can also claim some big-name players in their corner, including Apple, Intel and Red Hat. Version 2.2.1 was released just two weeks ago. Based on that alone, there’s not a lot to be gained trying to prove containers will wipe the floor with VMs, because even if you think you’re using a container, there’s a good chance you’re actually using a container inside a VM.
So this doesn’t need to be a fight to the death. Containers complement VMs and where containers fall short, VMs can save the day. So, far from ending up on the scrap heap, VMs are simply evolving to meet the needs of the current ‘as-a-service’ landscape. Just like the PC, VMs have proven themselves over decades – too long for them to disappear now. ®
Cast your vote below. We'll close the poll on Thursday night and publish the final result on Friday. You can track the debate's progress [11]here .
JavaScript Disabled Please Enable JavaScript to use this feature.
Get our [12]Tech Resources
[1] https://www.theregister.com/Debates/2021/06/21/containers_virtual_machines/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.gartner.com/en/newsroom/press-releases/2021-01-11-gartner-says-worldwide-pc-shipments-grew-10-point-7-percent-in-the-fourth-quarter-of-2020-and-4-point-8-percent-for-the-year
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://kubevirt.io/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] http://www.x-containers.org/
[10] https://katacontainers.io/
[11] https://www.theregister.com/Debates/2021/06/21/containers_virtual_machines/
[12] https://whitepapers.theregister.com/
During the week you can cast your vote on which side you support using the embedded poll, choosing whether you're in favor or against the motion. The final score will be announced on Friday, revealing whether the for or against argument was most popular. It's up to our writers to convince you to vote for their side.
This week's motion is: [1]Containers will kill virtual machines
[2]
And now, today, arguing AGAINST the motion is DARREN YATES, a research scientist who just completed a PhD in machine learning and data science, and is a veteran technology journalist...
[3]
[4]
Remember when the PC was going to vanish if Microsoft didn't nail the next release of Windows? It turns out Global PC sales actually [5]rose 4.8% in 2020 . Write this off as a pandemic-induced aberration if you want, but as the global workforce gets a taste of working from home and likes it, this sort of ‘aberration’ proves yet again that once a good technology matures, it takes something revolutionary to replace it.
Now, it’s the turn of Virtual Machines (VMs) to supposedly fall at the hands of containers. The only trouble is, VMs go back even further than the PC to the early-1960s, which shows they have enduring value. Containers may well be here to stay, but it doesn’t mean you’ll be saying good-bye to VMs any time soon.
[6]
Why? Consider VMs’ versatility, for a start. By lifting the abstraction from the hardware layer up to the app layer, containers can be moved and distributed without worrying about the hardware they’re running on. That same abstraction also allows for deeper server utilisation because you don’t have the setup overheads of a VM with its full-blown guest OS. That much is given.
One compromised container endangers all of the other containers sharing the host kernel
However, abstracting at the app layer reduces versatility, since all containers on the host server are limited to sharing the same host OS kernel. Need to cross-develop for a different hardware platform or require a custom kernel? Containers on their own won’t help.
Abstracting only the lower hardware layer allows VMs to run a mix of different OSes and kernels on the same server. Sure, you lose some versatility in terms of server utilisation by siloing resources, but you gain it back by having greater control over the applications, kernels and OSes your server can run. (Then again, if you use Kubernetes, you might tap [7]KubeVirt to run your VM with your containers, provided your host supports nested virtualisation, but not all do).
In other words, it’s ‘swings and roundabouts’.
However, there’s another important benefit of VMs' lower-level abstraction: security.
[8]
Since containers share the resources of the host system, this makes them vulnerable to attack. One compromised container endangers all of the other containers sharing the host kernel, or those built from the same container image. In fact, several attack vectors have been identified by researchers –containers attacking each other, hosts attacked by malicious containers and vice versa. Even containers attacked by its own apps. It sounds like an Aliens movie.
Yet, by incorporating the OS layer in the virtual silo, VMs inherently add an extra barrier that isolates one VM from another, as well as from the host. Should a VM be attacked, that attack ends at the VM border – the system host and other VMs remain unaffected (notwithstanding some nasty side-channel attacks).
Nevertheless, it’s not surprising that one of the more active areas of industry and university research right now is improving container security.
For example, researchers at Cornell University developed [9]X-Containers to improve container isolation and performance by incorporating a Linux-based ‘library’ OS (LibOS), that bundles all of the OS services required by the container application into a library. This is then wrapped around by an exokernel, a lean, low-attack-surface kernel that isolates the containers from each other. Published performance results show good scalability, but an X-Container currently has a larger memory load and is slower to boot than a Docker container (but still faster than a full VM).
In the context of this debate, one of the more interesting solutions lining up to solve the container isolation issue is hypervisor-controlled containers or ‘microVMs’, where each container runs inside a lightweight VM with its own kernel. What you end up with is the security of a VM, but with the fast boot-times and lower resource requirements of a container.
Once a good technology matures, it takes something revolutionary to replace it
[10]Kata Containers are an OCI- and CRI-compliant open-source example evolved from Intel’s Clear Containers platform using QEMU/KVM VMs. Launched in 2018, Kata Containers can also claim some big-name players in their corner, including Apple, Intel and Red Hat. Version 2.2.1 was released just two weeks ago. Based on that alone, there’s not a lot to be gained trying to prove containers will wipe the floor with VMs, because even if you think you’re using a container, there’s a good chance you’re actually using a container inside a VM.
So this doesn’t need to be a fight to the death. Containers complement VMs and where containers fall short, VMs can save the day. So, far from ending up on the scrap heap, VMs are simply evolving to meet the needs of the current ‘as-a-service’ landscape. Just like the PC, VMs have proven themselves over decades – too long for them to disappear now. ®
Cast your vote below. We'll close the poll on Thursday night and publish the final result on Friday. You can track the debate's progress [11]here .
JavaScript Disabled Please Enable JavaScript to use this feature.
Get our [12]Tech Resources
[1] https://www.theregister.com/Debates/2021/06/21/containers_virtual_machines/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.gartner.com/en/newsroom/press-releases/2021-01-11-gartner-says-worldwide-pc-shipments-grew-10-point-7-percent-in-the-fourth-quarter-of-2020-and-4-point-8-percent-for-the-year
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://kubevirt.io/
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/virtualization&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YNIJIUCZn1CXGKMeV@zkVQAAABQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] http://www.x-containers.org/
[10] https://katacontainers.io/
[11] https://www.theregister.com/Debates/2021/06/21/containers_virtual_machines/
[12] https://whitepapers.theregister.com/
Re: Vi or emacs?
Ben Tasker
We always took the approach that using containers (well, specifically Docker) was fine *if* you could provide a sane justification for it.
It makes deployment much easier, sure - but in a network where deployments are relatively rare, that's outweighed by having to get the support team/ops comfortable with managing and troubleshooting Docker.
The result is that (in terms of projects) VMs have tended to be more common than containers.
Containers vs VMs - probably a false dichotomy
raesene
For me containers make most sense when defined as a way to package and distribute software irrespective of the isolation mechanism used. If you deploy containers on Google Cloud Run they're isolated using a gVisor sandbox, if you deploy on ECS Fargate, it uses a micro-VM with Fargate.
So it's not one or the other, it's getting the right isolation mechanism for the deployment. I'd say that, if you're doing something like multi-tenant Kubernetes clusters, you want a VM/Sandbox isolation setup, rather than runc based things like ContainerD and CRI-O as the attack surface of a shared Linux kernel is pretty big and there's a steady stream of vulnerabilities to try and exploit.
However if you've got a set of relatively trusted applications, runc based isolation may be fine and it's going to be lower overhead than using a Sandbox or MicroVM
Vi or emacs?
This sounds like the eternal vi-emacs argument.
Personally I'm vi - simple, available everywhere. Like VMs.
One thing I particularly don't like about containers is the relative lack of storage or persistence.
However nothing I'm working on needs me to do the cost-benifit analysis. VMs let anyone administer the solution, its a known quantity, good enough for me.