I wanted a better answer to a deceptively simple security question:

How does the security boundary of a virtual machine differ from the security boundary of a container?

The short version is that a conventional container isolates processes within a shared host kernel, while a virtual machine normally isolates an entire guest operating system behind virtual hardware and a hypervisor.

That makes a VM a stronger default boundary for mutually untrusted workloads. But it does not mean that containers are inherently insecure or that VMs are automatically safe. The real answer depends on the whole stack: configuration, privileges, management access, patching, identity, networking, and what happens if one layer fails.

The Core Mental Model

A container is not a miniature VM.

On Linux, containers are processes whose view of the system is constrained by kernel features such as:

  • namespaces, which limit what processes, networks, mounts, and users a workload can see
  • cgroups, which account for and limit resources
  • capabilities, which split root privileges into smaller units
  • seccomp, which filters system calls
  • AppArmor or SELinux, which add mandatory access controls

Those controls can produce strong practical isolation. The important limitation is that the containers on a node still rely on the same host kernel. A kernel vulnerability, container-runtime flaw, or dangerous configuration can cross the intended boundary.

A VM puts another layer in between. Each VM normally runs its own guest kernel and sees virtualized hardware presented by a hypervisor. An attacker escaping the guest must cross the virtualization boundary before reaching the host or another guest.

That boundary is usually harder to cross, but it creates its own attack surface: the hypervisor, virtual devices, host-to-guest integrations, and the virtualization management plane.

VM versus Container

Aspect Virtual machine Conventional container
Primary isolation mechanism Hypervisor and virtual hardware Host-kernel isolation features
Kernel Normally has its own guest kernel Shares the host kernel
Default boundary Generally stronger for mutually untrusted workloads Depends more heavily on kernel and runtime hardening
Startup and resource cost Higher Lower
Main attack surface Hypervisor, management plane, virtual devices, guest OS Host kernel, runtime, privileges, mounts, images, and orchestrator
Common reason to use it Tenant isolation, different operating systems, stronger separation Portable packaging, fast startup, high-density application deployment
Common production pattern VM hosts one or more workloads Container runs inside a VM

The table is useful, but the last row is the one I want to remember. In cloud environments, this is often not a choice between VMs and containers. Containers commonly run inside VMs, so the boundaries form layers.

What Weakens a Container Boundary

A well-restricted container and a privileged container are very different security objects.

The configurations that make me most cautious are:

  • privileged mode
  • running as root when it is unnecessary
  • broad Linux capabilities such as CAP_SYS_ADMIN
  • access to the host network, process namespace, or filesystem
  • writable host-path mounts
  • access to the Docker or container-runtime socket
  • unconfined seccomp, AppArmor, or SELinux settings
  • weak Kubernetes RBAC or service-account permissions

Kubernetes’ own Linux kernel security guidance notes that privileged containers override several important protections and receive all Linux capabilities. Its Pod Security Standards provide a useful baseline for preventing many of these configurations.

This is why saying “it runs in a container” is not enough to establish a meaningful boundary. I also need to know what the container can ask the kernel to do, what host resources it can reach, and what credentials it carries.

What Weakens a VM Boundary

VM isolation can also be undermined.

The important risks move toward a different set of components:

  • an unpatched hypervisor
  • exposed or overprivileged management interfaces
  • vulnerable virtual devices
  • insecure clipboard, file-sharing, or device-passthrough features
  • flat management, storage, and workload networks
  • weak guest hardening
  • credentials that allow an attacker to control other VMs through the management plane

The guest kernel creates separation from the host kernel, but it also becomes another operating system that must be configured, monitored, and patched.

This leads to a broader lesson: the strength of the low-level isolation mechanism matters, but attackers frequently take the easier route through credentials, control planes, exposed sockets, or unsafe configuration.

The Boundary Is Layered in Kubernetes

A production Kubernetes workload may sit on top of:

  1. a cloud provider’s physical infrastructure
  2. a hypervisor or other tenant-isolation mechanism
  3. a node VM and its operating system
  4. a container runtime
  5. Kubernetes node and control-plane components
  6. pods, containers, identities, secrets, and application code

Each layer has a different failure mode. A container escape is only one possibility. An overly powerful service account, compromised image, exposed control plane, or stolen cloud credential may bypass the isolation question entirely.

That is why Kubernetes’ cloud-native security model treats security as multiple layers rather than one feature. The practical goal is defense in depth: least privilege, restricted workloads, strong identity, network isolation, trusted images, observable runtime behavior, and a limited blast radius when something fails.

The Books I Would Start With

1. Container Security, Second Edition by Liz Rice

This is the closest match to the question. The second edition was published in October 2025 and covers the Linux primitives beneath containers, threat models, security boundaries, modern tooling, Kubernetes, and practical mitigations.

I would start here because it builds the systems-level mental model. Instead of treating a container as a black box, it explains what the kernel and runtime are actually doing.

2. Cloud Native Security by Chris Dotson

Cloud Native Security zooms out from container internals to infrastructure, identities, applications, orchestration, supply chains, and runtime environments.

This is useful for answering the architectural version of the question: when should I use a VM, a container, or both, and which controls are still necessary around them?

3. Kubernetes Security and Observability by Brendan Creane and Amit Gupta

Kubernetes Security and Observability connects hardening with network policy, runtime protection, detection, and operations.

That matters because security is not only about preventing escape. I also want to know whether I can see suspicious behavior, investigate it, and contain it.

4. Virtualization Security by Dave Shackleford

Virtualization Security: Protecting Virtualized Environments is the VM-side counterpart. Its platform examples are dated, but its architectural concerns remain useful: protect the hypervisor, restrict administrative access, separate sensitive networks, secure virtual devices, and treat host-to-guest integrations as part of the attack surface.

I would read it for the principles, not as a guide to today’s cloud products.

The Primary Guidance I Would Read Alongside Them

Books build intuition; standards make the threat model more concrete.

The two NIST guides are especially useful together. They make it easier to compare which layer enforces isolation and which components have to be included in each threat model.

My Reading Order

If I wanted to turn this into working knowledge, I would go in this order:

  1. Read Liz Rice to understand what containers actually are.
  2. Use NIST SP 800-190 to build a container threat model.
  3. Read the virtualization book for the VM and hypervisor perspective.
  4. Compare that model against NIST SP 800-125.
  5. Move into Kubernetes security and observability for production practice.

The lasting insight is not simply “VMs are secure and containers are fast.”

It is that every isolation boundary is implemented by something, administered through something, and surrounded by other layers. For a container, the shared kernel and runtime deserve special attention. For a VM, it is the hypervisor, virtual hardware, and management plane. In modern cloud systems, I usually want both boundaries working together, with the privileges and blast radius at every layer kept as small as possible.