Virtualization and containers: where the isolation boundary sits

The same workload, drawn four ways

Take one thing — Rideau Library's catalogue application — and deploy it four ways. For each, ask two questions: what is the isolation boundary, and what is the shared component that everything must trust?

Bare metal. The application runs on an operating system that runs on hardware. The boundary between this workload and any other is the operating system's own process and permission machinery; the shared trusted component is the kernel. This is the baseline.

On a type 1 hypervisor. A hypervisor is loaded as a software layer directly onto the physical server, much as an operating system would be, and controls the physical resources itself. This is called native virtualization. Above it, several complete guests run, each with its own kernel. The boundary is the hypervisor; the shared trusted component is the hypervisor.

On a type 2 hypervisor. The hypervisor runs as a software module on top of a host operating system and relies on that host to handle hardware interactions on its behalf — hosted virtualization. The boundary is still the hypervisor, but the shared trusted component is now the hypervisor and the host operating system beneath it, plus whatever else the user is running alongside it.

In a container. Here the isolating software sits above the host kernel rather than beneath a guest one, giving each application a walled-off execution environment. The defining contrast: a container makes no attempt to imitate a physical server. Every containerized application on the box runs against one shared kernel, so there is no per-application operating system to pay for; the supporting machinery is a small container engine that asks the host OS for resources per container and then lets each container use the host's resources directly. The boundary is the container engine and the kernel features it drives; the shared trusted component is the host kernel itself.

The sentence to carry out of this lesson: VM virtualization functions at the border of hardware and operating system, providing strong performance isolation and security guarantees through the narrow interface between guests and hypervisor; containerization sits between the operating system and the applications, incurring lower overhead but potentially introducing greater security vulnerabilities. Containers are not "lightweight VMs". They are a different boundary at a different height, and the height is the security story.

Type 1 against type 2, on three axes

1. Performance. Type 1 typically performs better, because it is not competing for resources with a host operating system — more of the machine is available, so more guests fit.
2. Security. Type 1 is considered the more secure of the two: a guest's resource requests are handled entirely outside the guest and cannot affect other guests or the hypervisor. That is not necessarily true of type 2, where a malicious guest may be able to affect more than itself, because there is a whole host operating system underneath with its own attack surface and its own other applications.
3. Convenience. Type 2 lets someone virtualize without dedicating a server to it — a developer runs three environments alongside their desktop — and images move readily between hypervisor environments, which cuts deployment time and improves the accuracy of what gets deployed.

That is why native virtualization is the server pattern and hosted virtualization the client one.

What a hypervisor actually does

Five functions, worth knowing as a list because they are also the list of things that can go wrong: execution management of VMs (scheduling, virtual memory management to keep guests isolated, context switching, emulating timers and interrupts); device emulation and access control (presenting the network and block devices the guests' native drivers expect, and mediating access to the physical ones); execution of privileged operations on behalf of guests (operations a guest OS invokes that, being privileged, the hypervisor must perform for it); VM lifecycle management (configuring guests, Start / Pause / Stop); and administration of the hypervisor platform itself.

One detail from device emulation carries more exam weight than the rest. A hypervisor commonly gives each guest a virtual NIC and bridges or routes between them using a virtual switch implemented in the hypervisor kernel. This is efficient — traffic between two guests on the same host never touches an external link. It is also the most-quoted security consequence in the chapter: that traffic is not subject to monitoring by probes attached to the physical network. Your IDS sees nothing, because there is nothing on the wire to see. The countermeasure is a virtual firewall or a hypervisor-resident inspection capability, not a better physical sensor.

Three concerns a virtualized deployment adds

NIST SP 800-125 and the literature it draws on name three:

1. Guest OS isolation — ensuring that programs in a guest may use only the resources allocated to that guest and cannot covertly interact with programs or data in other guests or in the hypervisor.
2. Guest OS monitoring by the hypervisor — the hypervisor has privileged access to the programs and data of every guest, so it must be trusted both to be free of subversion and not to have that access misused.
3. Virtualized environment security, particularly image and snapshot management — images and snapshots are files, and an attacker who can view or modify one has compromised the data and the programs inside it, at rest, with no need to attack a running system at all.

The balanced assessment is the shape of a good exam answer. A configuration vulnerable on bare hardware is most likely vulnerable in a VM too, and if compromised is at least as capable of attacking its neighbours — virtualization is not a mitigation for a bad configuration. It may improve security by isolating inter-guest traffic, but that same isolation is what hides the traffic from external monitoring. The hypervisor's transparent view of all guests can be turned into a virtual firewall or IDS, which is a genuine gain unavailable on bare metal. And the hypervisor can reduce security if it contains exploitable flaws: a guest program that covertly reaches the hypervisor, and thereby other guests' resources, has performed a VM escape. Because the hypervisor is a single component that every tenant depends on, it is the highest-value target on the machine — which is why NIST's recommendations are to plan the security of the virtualized system deliberately, secure every element of the solution (hypervisor, guests and virtualized infrastructure), secure the hypervisor properly in particular, and restrict and protect administrator access to the virtualization solution.

Securing the hypervisor means treating it as an operating system: install it in an isolated environment from known-clean media, patch it to current and configure it to stay current, disable unused services, disconnect unused hardware, use the introspection capabilities it offers, and monitor it for compromise. Administrator access deserves its own paragraph, because an administrator of the hypervisor can access and monitor activity in any guest — so authentication and encryption on both local and remote administration, and ideally a separate management network with very limited access from outside the organisation.