Container

A Linux container is not a kernel object but a convention: an ordinary process tree started with a particular combination of isolation and resource-control primitives. Namespaces give the process its own view of a global resource - mount (filesystem tree), PID (process numbering, with the entrypoint as PID 1), network (interfaces, routes, iptables/nftables rules), UTS (hostname), IPC, user (UID/GID mapping), cgroup and, since Linux 5.6, time. Control groups (cgroups, today usually the unified v2 hierarchy) cap and account for CPU, memory, PIDs and block I/O; a container that exceeds its memory limit is killed by the kernel's OOM killer rather than slowing the host down. The root filesystem is typically an overlay (overlayfs) of the image's read-only layers plus a thin writable layer that disappears with the container.

Namespaces and cgroups alone are a weak boundary, so runtimes layer further restrictions on top: dropping most Linux capabilities (a container "root" usually lacks CAP_SYS_ADMIN, CAP_NET_ADMIN and similar), a seccomp-bpf filter that blocks rarely needed or dangerous system calls, a mandatory access control profile from AppArmor or SELinux, no_new_privs, and read-only mounts of sensitive parts of /proc and /sys. User namespaces can additionally map container UID 0 to an unprivileged host UID, so that a process that escapes is still unprivileged on the host; this is the default in rootless Podman and Docker rootless mode, but not in a typical Docker or Kubernetes setup.

The format and lifecycle are standardised by the Open Container Initiative (OCI, founded 2015): the runtime specification describes a "bundle" (a root filesystem plus a config.json listing namespaces, mounts, capabilities, cgroup limits and the process to run), and the image specification describes how that bundle is distributed. Windows has its own containers built on job objects and silos, with an optional Hyper-V isolation mode; they run Windows images only.

The main contrast with a virtual machine is the trust boundary. A VM is separated by a hypervisor and hardware virtualisation and runs its own kernel, so a guest kernel exploit stays in the guest. Every container on a host shares one kernel, so a kernel bug reachable through the allowed syscall surface - or a misconfiguration such as --privileged, a mounted Docker socket or a hostPath mount of / - can become a container escape. Where tenants do not trust each other, sandboxed runtimes such as gVisor (a user-space kernel) or Kata Containers (a lightweight VM per pod) are used to put a stronger boundary back. NIST SP 800-190 organises container risk into image, registry, orchestrator, container and host OS countermeasures, and treats the shared kernel as the reason to group containers on hosts by sensitivity.