Container

A container is a process — or a group of processes — running on a host with a restricted view of the system and a cap on what it may consume. On Linux the view is restricted by namespaces and the cap is enforced by control groups, and the kernel’s manual page for the former notes the connection plainly: “one use of namespaces is to implement containers.”

Both mechanisms are described below from the kernel documentation, read in September 2026. The number of namespace types grows over time, so treat the list as current-as-of rather than fixed.

Namespaces: what it can see

The kernel’s definition is worth reading for its precision: “a namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.”

A global system resource — singular. A namespace does not isolate a process in general; it isolates one named kind of thing, and there is one type per kind.

Namespace	Isolates	Why it matters
User	“User and group IDs”	The most consequential. Without it, root inside is root the host recognizes
PID	“Process IDs”	Whether the container can see and signal host processes
Network	“Network devices, stacks, ports, etc.”	Whether it has its own addresses and ports or the host’s
Mount	“Mount points”	What filesystem it sees as its own
IPC	“System V IPC, POSIX message queues”	Whether it can reach other processes’ shared memory and queues
UTS	“Hostname and NIS domain name”	Mostly cosmetic, occasionally load-bearing for software that keys on hostname
Time	“Boot and monotonic clocks”	Lets a container see a different uptime
Cgroup	“Cgroup root directory”	Hides where in the resource hierarchy it sits

Each is requested separately, as a CLONE_NEW* flag when the process is created. Which is the fact that reframes the whole subject: isolation is not a property a container has, it is a list of specific things you asked for. A container created without a user namespace is not “less secure” in a vague way — it specifically shares user identity with the host, and a root process inside is root outside.

A terminology note that prevents real confusion: this namespace is a kernel isolation mechanism. Kubernetes also has a thing called a namespace, which is a logical grouping of objects for organization and policy. They are unrelated, and it is worth saying which you mean when both are in the room.

Cgroups: how much it can use

Limits are a separate mechanism. Control groups are “a Linux kernel feature which allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored,” where “a cgroup is a collection of processes that are bound to a set of limits or parameters defined via the cgroup filesystem.”

The enforcement is done by per-resource subsystems, which make it possible “to do things such as limiting the amount of CPU time and memory available to a cgroup, accounting for the CPU time used by a cgroup, and freezing and resuming execution of the processes in a cgroup.” Note that accounting is in the same list as limiting — cgroups are also where per-container resource usage figures come from.

The division of labour is worth holding onto because the two failures are different. Namespaces decide what a process can see; cgroups decide how much it can consume. A container with namespaces and no memory limit is invisible to its neighbours and entirely capable of starving them — which is the failure usually reported as “a container took down the host.”

What it shares, and what that decides

Containers on one host share one kernel. That single fact is the whole structural difference from a virtual machine, and the weight-and-startup-speed comparison is a consequence of it rather than the point.

• A kernel vulnerability affects every container on the host.
• A kernel panic takes all of them down together.
• Kernel tunables are, with narrow exceptions, host-wide.
• The quality of the boundary is the quality of the kernel’s enforcement of these namespace and cgroup rules — strong in practice, and a different kind of boundary from a hypervisor’s.

Which yields a usable rule rather than a preference. Containers are a good boundary between things you operate; they are a weak boundary against things you do not trust. Running your own services side by side is ordinary and sensible — workload isolation at reasonable cost. Running untrusted third-party code in a plain container is loading a boundary that was not built for adversaries; where that is the requirement the answer is a stronger sandbox, and the same caution applies to tenant isolation in a multi-tenant product.

Useful nuance: the specifications do not frame these as opposites. The OCI runtime specification’s list of defined platforms includes linux and windows and also vm — so “container” names a packaging and lifecycle contract, and some runtimes satisfy that contract using virtual-machine isolation underneath. The question is never “container or VM” but what the isolation boundary actually is.

Four things it does not give you

• Correct dependencies. Packaging a broken set reproducibly produces a reliably broken system.
• Patching. Libraries inside age from the build date onward, and nothing in the container updates them; currency comes from rebuilding and replacing.
• Reduced privilege. Containerizing does not apply least privilege for you — the user the process runs as, and whether a user namespace maps it, are choices made at launch.
• Durability. The filesystem is disposable by design, so anything that must survive belongs on mounted storage.

The asymmetry to notice is that none of the security properties come from the container image. An image contains a filesystem and defaults; namespaces, limits, and the effective user are arguments to the act of running. So the same image is safe or unsafe depending on how it was launched, and four questions settle it for any container in your estate: which namespaces does it have, what are its cgroup limits, what user does it run as, and what is on the other side of that boundary. The formats and the runtime contract are standardized by the OCI; how the pieces fit together is worked through in Isolated From What, Exactly.

References: Linux manual page, namespaces(7); Linux manual page, cgroups(7); OCI Runtime Specification. All read September 2026.