Skip to content
Calcrivo

Container Escape Risk Calculator

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

Inputs

containers
containers
containers
containers
containers
containers
days

Container Escape Risk Score

92.3/ 100

Risk Level

Critical

Weighted Escape Vector Points

490points

Escape Points per 1000 Containers

408.3

Workload Configuration Penalty

61.3points

Host Hardening Penalty

31.0points

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. Values used

    Containers running in the fleet = 1,200 containers; Containers running privileged = 18 containers; Containers mounting the container runtime socket = 6 containers; Containers holding CAP_SYS_ADMIN = 11 containers; Containers sharing the host PID namespace = 9 containers; Containers with a writable hostPath mount = 24 containers; Container runtime = containerd with runc on a patched kernel — 6; Seccomp profile = Unconfined — 12; SELinux or AppArmor = Permissive — 6; Age of the running kernel patch level = 140 days

  2. 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.

  3. 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.

  4. Container Escape Risk Score

    = 92.3 / 100

  5. Risk Level

    = Critical

  6. Weighted Escape Vector Points

    = 490 points

  7. Escape Points per 1000 Containers

    = 408.3

  8. Workload Configuration Penalty

    = 61.3 points

  9. Host Hardening Penalty

    = 31.0 points

How it works

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

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.

You might also need