Skip to content
ENExplore Calculators

Container Escape Risk Calculator

Score container escape risk from privileged containers, mounted runtime sockets, host namespaces, capabilities, runtime class and kernel patch age.

About Container Escape Risk Calculator

Escape risk has two independent halves: what the workload is allowed to ask for, and what the host would let it get away with. A mounted runtime socket scores highest because it needs no exploit at all — you simply ask the daemon to start a privileged container — while seccomp, SELinux and a current kernel are the controls that turn a published kernel CVE into a failed syscall. Container escape converts one compromised application into a compromised node, and from there into every secret and token that node has ever mounted, which is why the multi-tenancy assumption behind most clusters depends on this number staying low.

Formulas

Container Escape Risk

Escape points = 12 × runtime-socket mounts + 10 × privileged + 8 × CAP_SYS_ADMIN + 6 × host-PID + 4 × writable hostPath containers, normalised per 1000 containers.

escapePoints
Weighted escape vector total
vectorsPer1000
Escape points ÷ containers × 1000
workloadPenalty
min(70, 0.15 × escape points per 1000 containers)

Host hardening

Host hardening penalty = runtime class + seccomp + SELinux/AppArmor points + min(15, 0.05 × kernel patch age in days). Total risk = workload penalty + host penalty, clamped to 0–100.

hostPenalty
Points for the runtime, syscall filtering, MAC and kernel currency
kernelPenalty
Penalty growing with how stale the node kernel is

Worked example

With the default values below, Container Escape Risk Calculator returns Container Escape Risk Score of 92.3. Change any input above and every figure here is recalculated in your browser.

Inputs used

Containers running in the fleetaccepts 1–500,000 containers
1,200 containers
Containers running privilegedaccepts 0–500,000 containers
18 containers
Containers mounting the container runtime socketaccepts 0–500,000 containers
6 containers
Containers holding CAP_SYS_ADMINaccepts 0–500,000 containers
11 containers
Containers sharing the host PID namespaceaccepts 0–500,000 containers
9 containers
Containers with a writable hostPath mountaccepts 0–500,000 containers
24 containers
Container runtimeone of gVisor or Kata sandboxed runtime — 0, containerd with runc on a patched kernel — 6, runc on an unpatched kernel — 14, Legacy Docker with dockershim — 18
containerd with runc on a patched kernel — 6
Seccomp profileone of RuntimeDefault on every workload — 0, Custom profile on some workloads — 4, Unconfined — 12
Unconfined — 12
SELinux or AppArmorone of Enforcing — 0, Permissive — 6, Disabled — 10
Permissive — 6
Age of the running kernel patch levelaccepts 0–5,000 days
140 days

Results

Container Escape Risk Score
92.3 / 100
Risk Level
Critical
Weighted Escape Vector Points
490 points
Escape Points per 1000 Containers
408.3
Workload Configuration Penalty
61.3 points
Host Hardening Penalty
31.0 points
Primary Escape Vector
Privileged containers — full host device and kernel access
Highest-Value Fix
Remove the runtime socket mount — use a build service or rootless builder instead

Step by step

  1. 1Values used
  2. 2Container Escape Risk
  3. 3Host hardening
  4. 4Container Escape Risk Score= 92.3 / 100
  5. 5Risk Level= Critical
  6. 6Weighted Escape Vector Points= 490 points
  7. 7Escape Points per 1000 Containers= 408.3
  8. 8Workload Configuration Penalty= 61.3 points
  9. 9Host Hardening Penalty= 31.0 points

Assumptions and limits

  • The result is derived only from the 10 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Container Escape Risk calculated?

Escape points = 12 × runtime-socket mounts + 10 × privileged + 8 × CAP_SYS_ADMIN + 6 × host-PID + 4 × writable hostPath containers, normalised per 1000 containers. Escape risk has two independent halves: what the workload is allowed to ask for, and what the host would let it get away with. A mounted runtime socket scores highest because it needs no exploit at all — you simply ask the daemon to start a privileged container — while seccomp, SELinux and a current kernel are the controls that turn a published kernel CVE into a failed syscall.

Why does Container Escape Risk matter?

Container escape converts one compromised application into a compromised node, and from there into every secret and token that node has ever mounted, which is why the multi-tenancy assumption behind most clusters depends on this number staying low.

What values do I need to enter?

This calculator takes 10 inputs: Containers running in the fleet, Containers running privileged, Containers mounting the container runtime socket, Containers holding CAP_SYS_ADMIN, Containers sharing the host PID namespace, Containers with a writable hostPath mount, Container runtime, Seccomp profile, SELinux or AppArmor, Age of the running kernel patch level. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Is a mounted Docker socket really that bad?

It is equivalent to giving the container root on the host. Anything that can talk to the runtime socket can create a new container with the host filesystem mounted and no restrictions, then chroot into it. There is no configuration that makes it safe — use a rootless builder such as Kaniko or Buildah, or a separate build service.

Do sandboxed runtimes remove the risk?

They substantially reduce it. gVisor intercepts syscalls in userspace and Kata gives each pod its own kernel in a lightweight VM, so a kernel bug in the guest does not reach the host. The cost is syscall latency and some incompatibility, which is why they are usually reserved for untrusted or multi-tenant workloads.

Related Calculators

Container Escape Risk Calculator | Calcrivo