Cybersecurity glossary
What is a Container Runtime?
Learn what a container runtime is, how CRI, containerd, CRI-O, and runc start pods, and which runtime settings decide isolation, logging, and escape risk.
Definition
A container runtime is the node software that pulls images, creates isolated processes (namespaces, cgroups, filesystems), and starts containers on behalf of an orchestrator—typically through the Kubernetes Container Runtime Interface (CRI).
Why the container runtime matters
Kubernetes YAML does not create processes. The container runtime on each node pulls bytes, sets up namespaces, and execs the entrypoint. If that software is outdated, misconfigured, or exposed via a Unix socket, every pod on the node inherits the weakness.
Treat the runtime as production infrastructure: versioned, patched, and unwilling to honor privileged requests that admission should have blocked.
What happens when a pod starts
kubelet accepts the Pod spec
After the API server and scheduler, kubelet asks the CRI runtime to create the pod sandbox and containers.
The high-level runtime pulls the image
containerd or CRI-O authenticates to the registry, verifies the digest, and unpacks layers.
A pod sandbox is created
Shared network and IPC namespaces for the pod are set up before application containers start.
The low-level OCI runtime execs
runc or crun applies namespaces, cgroups, mounts, seccomp, and the user from the spec.
Streams and probes attach
Logs, exec, and liveness probes go through the runtime. That API is privileged on the node.
Runtime layers you will hear named
CRI (kubelet API)
The contract Kubernetes uses so the orchestrator does not embed Docker.
High-level runtime
containerd or CRI-O: image management, sandboxes, and CRI implementation.
Low-level OCI runtime
runc, crun, or a sandbox runtime that actually creates the container process.
Socket / API
Unix sockets used for debug. Mounting them into a pod is equivalent to node root.
Runtime choices and security trade-offs
| Choice | Typical use | Security note |
|---|---|---|
| containerd + runc | Most managed Kubernetes nodes | Patch both; disable unused features and exposed debug sockets |
| CRI-O + runc/crun | OpenShift and some Kubernetes distros | Same isolation model; follow the distro’s SELinux defaults |
| gVisor / Kata | Untrusted or multi-tenant workloads | Smaller kernel attack surface; not a substitute for admission policy |
| Docker Engine on a workstation | Local builds and compose | Do not expose docker.sock; do not copy that habit into production pods |
Container runtime hardening checklist
- Run a current, vendor-supported runtime and patch runc/containerd/CRI-O on the same cadence as the kernel.
- Never mount the runtime socket into application, CI, or debug pods.
- Configure default seccomp and SELinux/AppArmor; do not run Unconfined as the node default.
- Restrict who can kubelet exec and who can change RuntimeClass to a sandboxed or privileged class.
- Pin image pulls to digests and private registries; configure runtime auth without embedding pull secrets in every spec.
- Collect runtime and kubelet audit logs; alert on privileged sandboxes and unexpected RuntimeClass.
- Replace nodes rather than SSH-upgrading runtimes by hand when you practice immutable infrastructure.
- Pair runtime hardening with Pod Security so the runtime is not asked to start escape-friendly specs.
The practical takeaway
A container runtime is the node software that turns images into isolated processes via CRI and an OCI runtime. Kubernetes policy is a request; the runtime is the enforcement on the metal.
Keep it patched, keep its socket off mounts, and do not ask it for privileged. Runtime CVEs and runtime misconfig are cluster-wide events, not single-app bugs.
Related security terms
Container Image
The artifact the runtime pulls, unpacks, and executes.
Container Escape
A failure of runtime isolation or of the privileges the runtime was asked to grant.
Pod Security
Admission policy that limits which runtime features a pod may request.
Immutable Infrastructure
Nodes and runtimes should be replaced, not SSH-patched in place.
Image Registry
Where the runtime authenticates and fetches layers from.
Frequently asked questions
What is a container runtime in simple terms?
It is the program on the machine that actually starts containers: pull the image, set up isolation, run the process. Kubernetes asks; the runtime does the work.
What is the difference between Docker, containerd, and runc?
Docker is a developer UX and former Kubernetes runtime. containerd and CRI-O are high-level runtimes that talk CRI. runc (or crun) is the low-level OCI runtime that creates the process.
What is CRI?
The Container Runtime Interface is Kubernetes’ gRPC API between kubelet and a runtime. It lets clusters swap containerd or CRI-O without changing the control plane.
Does the runtime provide security by itself?
It implements namespaces, cgroups, and seccomp if asked. Privileged specs, extra capabilities, and an old runc CVE can still undo isolation. Policy plus patches both matter.
Should production nodes still run Docker Engine?
Kubernetes removed dockershim. Production clusters generally use containerd or CRI-O. Docker may still exist on developer workstations.
What is a sandboxed runtime?
gVisor, Kata, or Firecracker wrap or replace the usual runc path with a stronger guest boundary for hostile multi-tenancy.
Why patch the runtime if images are scanned?
Image scans do not cover runc, containerd, or the kernel. Runtime CVEs are node CVEs; they affect every pod on that machine.
References
Explore authoritative guidance and frameworks related to container runtime.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.