Containers Explained: Images, Layers, and How They Differ From VMs

A container packages an application with its dependencies and runs it as an isolated process on a shared kernel. That last part — shared kernel — is the single most important fact about containers, because everything about their speed, their density and their security limits follows from it.

What provides the isolation

Containers are not a virtualization technology. They are ordinary processes with kernel features applied to restrict what they can see and use.

Namespaces control visibility. A process in its own PID namespace sees only its own processes and believes it is process 1. A network namespace gives it its own interfaces and routing table. Mount, user, UTS and IPC namespaces do the equivalent for filesystems, user identity, hostname and interprocess communication. The process is not hidden from the host — the host sees it as a normal process — it simply cannot see out.

Control groups limit consumption: CPU, memory, disk and network bandwidth. Without them a single container can starve everything else on the host, and memory limits in particular are the difference between one failing container and a failing node.

Capabilities split root's powers into individual privileges, so a container can be granted only what it needs. Seccomp filters which system calls it may make, and mandatory access control profiles add another layer — the model described under SELinux.

Because there is no guest kernel to boot, a container starts in milliseconds and consumes only the resources of its process. That is the whole performance argument.

Images and layers

An image is a stack of read-only filesystem layers, each recording the changes made by one build step. A running container adds a thin writable layer on top, and everything it writes goes there.

Layering is why builds are fast — unchanged layers are cached and reused — and why images are efficient to distribute, since hosts already holding a base layer download only what differs.

It also has a security consequence people repeatedly miss: deleting a file in a later layer does not remove it from the image. The earlier layer still contains it and anyone who pulls the image can read it. A secret added in one build step and deleted in the next is still there, which is the finding described under container image scanning.

The writable layer is discarded when the container is removed, which is what makes containers ephemeral. Anything that must persist — data, logs, uploaded files — goes in a mounted volume or an external service. Treating a container as a small server that can be logged into and modified defeats the model, because the next deployment replaces it.

Immutability, and why it helps security

The intended pattern is that containers are never modified in place. To change anything, you build a new image and replace the running container.

That removes configuration drift entirely — every instance is identical because they came from the same image — and it means an attacker's changes do not survive the next deployment. It also makes rollback trivial: deploy the previous image.

The corresponding hardening is to run with a read-only root filesystem, which is straightforward once the application writes only to designated volumes, and which blocks a large share of post-exploitation activity.

Containers and virtual machines

The comparison the exam wants. A virtual machine includes a full guest operating system with its own kernel, isolated by a hypervisor — heavier, slower to start, and a stronger boundary. A container shares the host kernel, isolated by kernel features — lighter, faster, denser, and a weaker boundary.

The security implication is direct: a kernel vulnerability reachable from a container is a container escape, and the shared kernel is a far larger interface than a hypervisor. Where workloads of very different trust levels must be isolated, virtual machines or sandboxed runtimes are the answer — the reasoning under VM escape and hypervisor security.

They are also complementary in practice: most container platforms run on virtual machines, using the hypervisor for tenant separation and containers for density within a tenant.

The hardening that follows

Run as a non-root user, drop all capabilities and add back only what is needed, use a read-only root filesystem, apply a seccomp profile, and never run privileged containers — a privileged container is effectively root on the host.

Use a minimal base image so there is less inside to exploit, and rebuild regularly so the base stays current. Where runtime traffic policy and identity are needed between services, that sits above the container itself, as described under the sidecar pattern.

Exam angles

Know containers as processes isolated by namespaces (visibility) and control groups (resource limits), sharing the host kernel. Contrast with virtual machines, which include a guest kernel and are isolated by a hypervisor, providing stronger isolation at higher cost. Know images as stacked read-only layers with a writable container layer, that deleted files persist in earlier layers, and that containers are ephemeral and immutable by design with persistent data in volumes.