Theory: Containers and virtual machines

Before you use Docker, it helps to know what a container is not. It is not a smaller virtual machine. Both help you pack applications onto servers, but the isolation model is different.

What a virtual machine is

A virtual machine (VM) is a full computer simulated in software. A program called a hypervisor (for example VMware, KVM, Hyper-V) shares the physical CPU, memory, and disk between several guests.

Each VM usually boots its own guest operating system (another Linux or Windows kernel). Your application runs inside that guest. The hypervisor keeps VMs apart. If one guest kernel is compromised, other guests still have their own kernels, which adds a strong boundary.

Trade-offs: VMs are flexible and familiar. They also use more disk and RAM because each guest carries a full OS. Startup is often measured in tens of seconds or minutes.

What a container is

A container is a set of processes on one Linux (or Windows) host kernel. The kernel uses features such as namespaces (what the process can see) and cgroups (how much CPU or memory it may use) to make each container look like its own small environment. There is no second kernel inside the container for Linux containers on Linux.

Your app thinks it has its own filesystem and network. On the host, it is still normal processes managed by the same kernel.

Trade-offs: Containers start quickly and pack densely on a host. Many containers share one kernel. A serious kernel bug or a breakout from a container can affect the whole host and every container on it unless other defenses stop it.

Side-by-side intuition

flowchart TB
    subgraph VM["Virtual Machine"]
        VA["Your App"] --> VK["Guest OS Kernel"]
        VK --> HV["Hypervisor"]
    end
    subgraph CT["Container"]
        CA["Your App"] --> NS["Namespaces + cgroups"]
        NS --> HK["Host Kernel"]
    end
    HV --> HW["Physical Hardware"]
    HK --> HW

This table is a simplification. Windows containers and mixed setups exist. For this workshop, think Linux containers on a Linux host.

Why this matters for security work

Security teams care because the blast radius differs. A VM escape often targets the hypervisor. A container escape often ends up as root on the host kernel, which can affect every other container on that node.

That is why later modules talk about least privilege, scanning images, dropping capabilities, and platform hardening. Containers are convenient. They are not magic sandboxes.

Next: Theory: Images and running containers.