Container Runtime Security Cheat Sheet

Updated 2026-08-01

Next Topic: Container Security Cheat Sheet

🧠Study flashcards on this topic89 cards · spaced repetition→

Container runtime security protects containerized workloads throughout their lifecycle by enforcing isolation, restricting privileges, and detecting threats. Containers share the host kernel, making the runtime layer (the interface between the kernel and container processes) a critical attack surface: a single kernel exploit or misconfigured mount can escape every policy layered on top of it. Modern container security combines Linux kernel primitives (namespaces, cgroups, capabilities), mandatory access control systems (AppArmor, SELinux, BPF-LSM), and runtime monitoring tools to prevent escapes, privilege escalation, and lateral movement. Kubernetes' User Namespaces reaching General Availability in v1.36 finally maps a container's root UID to an unprivileged host user by default, closing a gap that repeated runc container-escape CVEs have exploited, so teams still need defense-in-depth from build to runtime: image signing, vulnerability scanning, and behavior-based detection layered on top of that kernel-level isolation.

What This Cheat Sheet Covers

This topic spans 15 focused tables and 90 indexed concepts, 89 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: User and Privilege IsolationTable 2: Linux CapabilitiesTable 3: System Call Filtering and Mandatory Access ControlTable 4: Filesystem and Storage SecurityTable 5: Namespace IsolationTable 6: Resource Limits and DoS PreventionTable 7: ServiceAccount and Workload IdentityTable 8: Secrets ManagementTable 9: Container Image SecurityTable 10: Alternative Container RuntimesTable 11: Runtime Threat Detection and MonitoringTable 12: Network Security for ContainersTable 13: Supply Chain and Build SecurityTable 14: Container Escape PreventionTable 15: Compliance Scanning and Vulnerability Tracking

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: User and Privilege Isolation

The most impactful container security wins come from running processes as non-root, both inside the container and on the host. These controls ensure that even a compromised container yields minimal host-level power to an attacker.

Technique	Example	Description
Rootless Containers	`podman run --rm alpine whoami`	• Containers run as a non-root user on the host • Docker daemon runs without root privileges, eliminating root-level attack surface entirely.
runAsNonRoot	`securityContext:` `runAsNonRoot: true` `runAsUser: 1000`	• Kubernetes security context that forces containers to run as a non-root user • the pod fails to start if the image uses UID 0.
Pod Security Standards (PSS) Enforcement	`pod-security.kubernetes.io/enforce: restricted`	• Namespace-level label enforced by the built-in Pod Security Admission controller • the Restricted profile requires everything else in this table (non-root, no privilege escalation, dropped capabilities) by default.
User Namespaces	`hostUsers: false` (Pod spec, GA in Kubernetes v1.36)	• Maps container root (UID 0) to an unprivileged host user • even after a breakout, the attacker has no host root access; ID-mapped mounts (Linux 5.12+) make this practical for stateful volumes by remapping ownership at mount time instead of a slow recursive `chown`.
allowPrivilegeEscalation: false	`securityContext:` `allowPrivilegeEscalation: false`	• Prevents processes from gaining more privileges than their parent via setuid/setgid binaries • blocks common privilege escalation vectors.
no-new-privileges Flag	`docker run --security-opt=no-new-privileges nginx`	• Prevents container processes from acquiring new privileges through setuid executables or file capabilities • enforces privilege boundaries at the OS level

Table 2: Linux Capabilities

Linux capabilities break root's all-or-nothing power into granular privileges. Dropping all capabilities and adding back only what is needed is one of the most effective ways to limit blast radius when a container is compromised.

Technique	Example	Description
Drop All Capabilities	`securityContext:` `capabilities:` `drop: ["ALL"]`	• Removes all Linux capabilities from the container • start from zero and add only what is strictly needed, the gold standard for least privilege.

The rest of this section is part of the full cheat sheet

Table 3: System Call Filtering and Mandatory Access Control

Syscall filtering and mandatory access control (MAC) constrain what a container process can actually do at the kernel level, independent of capability grants. Together they form a critical second line of defense if a runtime exploit occurs.

Technique	Example	Description
Seccomp Profiles	`securityContext:` `seccompProfile:` `type: RuntimeDefault`	• Restricts system calls a container can make • `RuntimeDefault` blocks ~44 dangerous syscalls including `keyctl`, `bpf`, and `ptrace`.

The rest of this section is part of the full cheat sheet

Table 4: Filesystem and Storage Security

Immutable container filesystems eliminate an entire class of persistence and malware-drop attacks. Combining a read-only root with ephemeral writable mounts is the gold standard for production workloads.

Technique	Example	Description
Read-Only Root Filesystem	`securityContext:` `readOnlyRootFilesystem: true`	• Mounts container filesystem as read-only • prevents malware from writing to disk, modifying binaries, or persisting across restarts.

The rest of this section is part of the full cheat sheet

Table 1: User and Privilege Isolation

Technique	Example	Description
Rootless Containers	`podman run --rm alpine whoami`	• Containers run as a non-root user on the host • Docker daemon runs without root privileges, eliminating root-level attack surface entirely.
runAsNonRoot	`securityContext:` `runAsNonRoot: true` `runAsUser: 1000`	• Kubernetes security context that forces containers to run as a non-root user • the pod fails to start if the image uses UID 0.
Pod Security Standards (PSS) Enforcement	`pod-security.kubernetes.io/enforce: restricted`	• Namespace-level label enforced by the built-in Pod Security Admission controller • the Restricted profile requires everything else in this table (non-root, no privilege escalation, dropped capabilities) by default.
User Namespaces	`hostUsers: false` (Pod spec, GA in Kubernetes v1.36)	• Maps container root (UID 0) to an unprivileged host user • even after a breakout, the attacker has no host root access; ID-mapped mounts (Linux 5.12+) make this practical for stateful volumes by remapping ownership at mount time instead of a slow recursive `chown`.
allowPrivilegeEscalation: false	`securityContext:` `allowPrivilegeEscalation: false`	• Prevents processes from gaining more privileges than their parent via setuid/setgid binaries • blocks common privilege escalation vectors.
no-new-privileges Flag	`docker run --security-opt=no-new-privileges nginx`	• Prevents container processes from acquiring new privileges through setuid executables or file capabilities • enforces privilege boundaries at the OS level

Table 2: Linux Capabilities

Technique	Example	Description
Drop All Capabilities	`securityContext:` `capabilities:` `drop: ["ALL"]`	• Removes all Linux capabilities from the container • start from zero and add only what is strictly needed, the gold standard for least privilege.

Table 3: System Call Filtering and Mandatory Access Control

Technique	Example	Description
Seccomp Profiles	`securityContext:` `seccompProfile:` `type: RuntimeDefault`	• Restricts system calls a container can make • `RuntimeDefault` blocks ~44 dangerous syscalls including `keyctl`, `bpf`, and `ptrace`.

Table 4: Filesystem and Storage Security

Technique	Example	Description
Read-Only Root Filesystem	`securityContext:` `readOnlyRootFilesystem: true`	• Mounts container filesystem as read-only • prevents malware from writing to disk, modifying binaries, or persisting across restarts.