Docker isn't magic, it's these 5 Linux kernel features strapped together

Published Nov 7, 2026, 7:00 AM EST Andrew Heinzman is a seasoned tech writer with over half a decade of experience. He specializes in delivering insightful tech news and detailed product reviews, particularly focusing on audio and video technology, as well as computers and smartphones. His journey in tech writing includes a two-year stint as the News Editor at Review Geek, the former sister site of How-To Geek. Throughout his career, Andrew has consistently provided readers with valuable insights and up-to-date information on the latest developments in the tech world, earning recognition for his clarity, depth, and relevance. In his free time, Andrew likes to explore music and read books, just as he did when earning his bachelor's degree in English literature. Docker's explosive adoption and dominance over the tech industry is incredible, to say the least. But because Docker's rise was so meteoric, a lot of people tend to mistake it for some kind of mystical, groundbreaking, all-new way of doing things. But the reality is much more simple: Linux set the groundwork for containers decades ago, and Docker found an appealing way to use it. All Docker containers share the host machine's Linux kernel and rely on five core kernel features to function properly. Once you understand these five features, it's much easier to grasp how Docker works and how to use it both effectively and securely. Note: Docker on macOS or Windows uses a Linux VM to provide a kernel for Linux containers. Namespaces put blinders on your containers Nothing to see here Apps running directly on the Linux desktop can, with the right permissions, access your filesystem, connected devices, network interface, active processes, and other parts of your operating system. This may make certain tasks convenient, but it isn't always practical. It also raises some security concerns for applications that are exposed to LAN or WAN. The Linux kernel's Namespaces feature prevents apps and processes from seeing the main system view. It can also be used to define what a process has access to. If you've used Docker for more than a few minutes, you probably know where this is going; Docker leverages Namespaces to isolate containers from the host and set boundaries, such as mount points in the filesystem. But there are limits to this separation that you should be aware of. All of your containers still share the host's kernel, for one, so kernel vulnerabilities can be exploited through a container. Cgroups help control resource use Containers still crash often enough, but whatever Namespaces simply isolate containers; they don't limit the amount of resources that a container can chew up. So, Docker uses the "cgroups" kernel feature to set limits on containers' CPU and RAM usage. These limits can be explicit, but they may also vary based on available resources, effectively giving containers the ability to run as fast as reasonably possible without crashing anything. There are a bevy of different cgroup subsystems that control how containers can access varying resources, including some things that would never cross your mind, like the maximum number of concurrent processes a container can run (this is the PIDs subsystem, it helps prevent some malicious exploits). Though it's worth noting that Docker does not limit resources automatically. You have to manually set the boundaries at runtime. OverlayFS keeps away bloat No duplicate files here, boss A kernel can't run apps on its own, and Docker containers can't access the OS-level libraries or tools in your desktop's operating system. So, Docker images are packaged with whatever user-space tools, binaries, and libraries they need to run. This creates the opportunity for a lot of inefficiency and wasted space, because most Docker images will contain the same basic set of common files. But Docker curbs the problem through the use of Overlay Filesystems (OverlayFS). The idea is kind of complicated at first blush, but it's pretty intuitive when broken down. Basically, Docker images are split into a set of layers that allow common files to be shared without compromising the integrity of container-specific files. First, there's the read-only LowerDir, which contains those essential user-space tools and libraries. Containers share the LowerDir to avoid the problem of duplicate files, which would otherwise eat up storage and increase load times. Then there's the read-write UpperDir, which houses all the things that are unique to a single container. A clever MergedDir brings the LowerDir and UpperDir into what a container sees as its root folder, effectively maintaining the best part of "isolation" without burdening your system. (There's also a WorkDir that serves as temporary storage for container processes). OverlayFS isn't the only storage backend that Docker can use, but it's the most common, and it helps to explain some of the inefficient-looking quirks that you might find while digging through Docker files. Capabilities keep root privileges in check You don't want Docker containers going all willy-nilly, right? Root privileges are one of Linux's most dangerous (and occasionally funny) quirks. In a standard Linux environment, the root user can change anything they want at any time, without any pushback from pesky security gateways or file permissions. Some distros put up guardrails, but generally speaking, Linux won't stop you from making stupid choices that break things. It won't stop malicious processes that have root access, either. Docker containers, and especially those that are exposed on a network, shouldn't have full-fat root privileges. So, Docker uses the Linux kernel's "capabilities" feature to chop up and limit a container's power in a way that's fairly secure but also pretty convenient. The default profile for Docker containers blocks a ton of high-risk capabilities, including the ability to mount filesystems and screw around with system configs. But it leaves a lot of the harmless or convenient stuff in place, like network binding services for ports under 1024. You can also fine-tune Docker's capabilities, though you really shouldn't add or drop any capabilities unless you know what you're doing. Seccomp stops containers from making bad system calls The last line of defense Most of the kernel features utilized by Docker, like the aforementioned "capabilities" feature, prevent compromised or malicious containers from screwing up your machine or attacking other devices on your network. But these features aren't always enough, which is why Docker relies on "seccomp" as its final, ultimate line of defense. Seccomp is basically a firewall that blocks a predefined set of system calls. There are a lot of ways to configure it, but Docker's default seccomp profile is designed to prevent containers from making syscalls that attackers or malware may use to escalate privileges, such as ptrace or unshare. Again, it's best to stick with Docker's defaults here if you don't know what you're doing. But if a workload requires extra isolation, you may need to create a custom seccomp allowlist. Quiz 8 Questions · Test Your KnowledgeWhat do you know about Docker?Trivia challenge Containers, images, and orchestration — find out how much you really know about Docker. ContainersNetworkingCommandsHistoryConcepts Begin In what year was Docker first publicly released? A2010B2011C2013D2015 Correct! Docker was first released to the public in March 2013 at PyCon by Solomon Hykes. It quickly became one of the most influential open-source projects in modern software development. Not quite. Docker made its public debut in March 2013 when Solomon Hykes demonstrated it at PyCon. Within just a few years, it transformed how developers build and ship software. Continue What is the key difference between a Docker image and a Docker container? AAn image is a running instance, while a container is a static templateBAn image is a read-only template, while a container is a running instance of that imageCAn image stores persistent data, while a container holds only application codeDThere is no difference — the terms are used interchangeably Correct! A Docker image is a read-only blueprint that defines the environment, while a container is a live, runnable instance created from that image. You can spin up many containers from a single image. Not quite. The image is the static, read-only template, and the container is what you actually run. Think of the image as a recipe and the container as the meal you cooked from it. Continue Which command would you use to list all currently running Docker containers? Adocker listBdocker container showCdocker psDdocker status Correct! The `docker ps` command displays all currently running containers. Adding the `-a` flag shows all containers, including stopped ones — a very handy trick to know. Not quite. The correct command is `docker ps`, which lists running containers. The name comes from the Unix `ps` command used to list processes, reflecting Docker's container-as-process philosophy. Continue What file is used to define the instructions for building a Docker image? Adocker-compose.ymlBContainerfileCDockerfileD.dockerignore Correct! A Dockerfile is a plain text file containing a series of instructions that Docker uses to build an image. Each instruction creates a new layer in the image, making builds efficient and cacheable. Not quite. The file used to build a Docker image is called a Dockerfile. While docker-compose.yml is also an important Docker file, it defines multi-container application setups rather than image build steps. Continue What is the default network driver used by Docker when you create a new container without specifying a network? AhostBoverlayCnoneDbridge Correct! Docker uses the bridge network driver by default. It creates a private internal network on the host, and containers on the same bridge network can communicate with each other while remaining isolated from the outside. Not quite. The default network driver is bridge. This creates an isolated network on your machine where containers can talk to each other, but outside traffic must be explicitly routed in via port mapping. Continue Which Docker command is used to download an image from a registry such as Docker Hub? Adocker fetchBdocker pullCdocker getDdocker download Correct! `docker pull` downloads an image from a registry to your local machine. If you don't specify a tag, Docker will automatically pull the image tagged `latest` by default. Not quite. The correct command is `docker pull`. It fetches an image from a registry like Docker Hub, storing it locally so you can create containers from it. The counterpart command, `docker push`, uploads images to a registry. Continue What does Docker use under the hood on Linux to isolate containers from each other and from the host system? AVirtual machines and hypervisorsBFull OS kernel copiesCLinux namespaces and cgroupsDBSD jails and Zones Correct! Docker leverages Linux namespaces for isolation (keeping processes, filesystems, and networks separate) and cgroups (control groups) to limit resource usage like CPU and memory. This is why containers are so lightweight compared to VMs. Not quite. Docker relies on Linux namespaces and cgroups for isolation. Unlike virtual machines, containers share the host OS kernel, which is what makes them so fast to start and efficient with resources. Continue What is Docker Compose primarily used for? ABuilding optimized production Docker imagesBManaging and orchestrating multi-container applications with a single configuration fileCReplacing Kubernetes in large-scale production clustersDMonitoring CPU and memory usage of individual containers Correct! Docker Compose lets you define and run multi-container applications using a YAML file called docker-compose.yml. With a single `docker compose up` command, you can spin up an entire application stack including databases, APIs, and frontends. Not quite. Docker Compose is designed to define and manage multi-container applications through a single YAML configuration file. It's especially popular for local development environments where you need several services running together. See My Score Challenge CompleteYour Score / 8 Thanks for playing! Try Again Yes, this is a bit of a simplification Docker containers rely on more than just a handful of Linux kernel features. There are a lot of other things under the hood, too, like user-space components, networking tools, and a daemon. Still, understanding the five core kernel features that power Docker really puts things into perspective. Your containers aren't independent systems running in complete isolation, they're a collection of processes that rely on a single kernel. The boundaries between these processes, as well as the security of your system in the event that a container is exploited, is only as strong as your Docker configuration.