Skip to main content
This lesson covers Docker security fundamentals that are useful background for Kubernetes security. If you’re already familiar with Docker security (namespaces, UIDs, and capabilities), you can skip ahead. Otherwise, the sections below walk through how containers are isolated from the host, how user IDs behave, and how Linux capabilities limit container root privileges.

​
Namespaces and process isolation

A host running Docker contains many processes (OS daemons, the Docker daemon, SSH, etc.). Containers run their processes on the same host kernel but inside isolated Linux namespaces (PID, mount, network, IPC, UTS, user, etc.). Namespaces give containers their own view of resources such as process IDs and network interfaces. Run a simple Ubuntu container that sleeps for an hour:
From inside the container the sleep process appears as PID 1 thanks to the PID namespace:
Example output inside the container:
On the host, the same process appears with a different PID and is listed among all host processes:
Example output on the host:
This demonstrates how PID namespaces provide process isolation: the container sees its own PID numbering while the host sees the container’s processes alongside other system processes.

​
Users and UIDs

By default Docker runs the container process as root (UID 0) inside the container. You can run container processes as a non-root UID at runtime with --user, or bake a default user into the image with the Dockerfile USER instruction. Run as a specific UID at runtime:
Example output inside the container:
Set the user at image build time with a Dockerfile:
Build and run the image:
Processes in that container will run as UID 1000 by default without passing --user at runtime.
A slide titled "Security – Users" showing a host box with nested namespace icons and a Docker logo on the left, and two simple user/person icons spaced on the right.

​
Is container root the same as host root?

A common question is whether root inside a container equals root on the host. The short answer is: not necessarily. Although a container process running as UID 0 is “root” inside the container’s namespaces, Docker and the Linux kernel reduce its effective power by dropping many Linux capabilities by default. Capabilities are fine-grained privileges defined by the kernel (see /usr/include/linux/capability.h for reference). Docker starts containers with a limited set of capabilities; this prevents the container root from performing many host-level actions (for example, manipulating host network devices or rebooting the host). Control capabilities and privileges with:
Running a container as UID 0 inside the container does not automatically grant full host root privileges because Docker limits capabilities by default. However, using --cap-add or --privileged can expand the container’s authority—use these sparingly and only when necessary.

​
Quick reference: namespaces, users, and capabilities

​
Summary

  • Containers share the host kernel but are isolated from the host and from each other using Linux namespaces (PID, network, mount, etc.).
  • By default, container processes run as root (UID 0) inside the container; use --user at runtime or USER in the Dockerfile to run as a non-root UID.
  • Docker reduces the power of in-container root by dropping many Linux capabilities by default. Use --cap-add / --cap-drop to adjust capabilities and avoid --privileged unless absolutely necessary.

Watch Video