Skip to content
ENExplore Calculators

Pod Security Risk Calculator

Score pods against the Pod Security Standards using privileged, hostPath, hostNetwork, runAsRoot and capability findings plus the admission mode.

About Pod Security Risk Calculator

The weights follow the Pod Security Standards themselves: privileged containers are outside every profile and score 10, host namespaces and hostPath are baseline breaches, and runAsRoot only breaks restricted so it scores 1 — common but not by itself an escape. The admission mode is added as a flat penalty because audit-only enforcement stops nothing. A privileged pod is a root shell on the node with extra steps, and the reason clusters have eighteen of them is that audit-mode admission produced a warning nobody read.

Formulas

Pod Security Risk

Violation points = 10 × privileged + 5 × host-namespace + 4 × hostPath + 3 × added-capability + 1 × runAsRoot pods, normalised per 100 pods.

violationPoints
Weighted count of Pod Security Standard breaches
violationsPer100Pods
Violation points ÷ pods × 100
pssMode
0–25 penalty for how weakly Pod Security Admission is applied

Risk scoring

Risk = 0.6 × violations per 100 pods + admission-mode penalty + 0.1 × missing read-only root filesystem share + 0.08 × missing seccomp share, clamped to 0–100.

hardeningGap
Points lost to missing read-only root filesystems and seccomp profiles
riskScore
0–100 pod security risk

Worked example

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

Inputs used

Pods in the clusteraccepts 1–500,000 pods
1,200 pods
Pods running privileged: trueaccepts 0–500,000 pods
18 pods
Pods using hostNetwork, hostPID or hostIPCaccepts 0–500,000 pods
34 pods
Pods mounting a hostPath volumeaccepts 0–500,000 pods
76 pods
Pods running as UID 0accepts 0–500,000 pods
310 pods
Pods adding Linux capabilitiesaccepts 0–500,000 pods
42 pods
Pods with a read-only root filesystemaccepts 0–100 %
38 %
Pods with a seccomp profile appliedaccepts 0–100 %
52 %
Pod Security Admission modeone of Enforce restricted — 0, Enforce baseline — 8, Audit and warn only — 16, No Pod Security Admission — 25
Audit and warn only — 16

Results

Pod Security Risk Score
80.5 / 100
Risk Level
Critical
Effective Pod Security Tier
Privileged — the cluster runs pods no standard would admit
Weighted Violation Points
1,090 points
Violation Points per 100 Pods
90.8
Pods That Would Pass Restricted
890 pods
Restricted-Ready Share
74.2%
Highest-Value Fix
Remove privileged: true — grant the one capability the workload actually needs instead

Step by step

  1. 1Values used
  2. 2Pod Security Risk
  3. 3Risk scoring
  4. 4Pod Security Risk Score= 80.5 / 100
  5. 5Risk Level= Critical
  6. 6Effective Pod Security Tier= Privileged — the cluster runs pods no standard would admit
  7. 7Weighted Violation Points= 1,090 points
  8. 8Violation Points per 100 Pods= 90.8
  9. 9Pods That Would Pass Restricted= 890 pods

Assumptions and limits

  • The result is derived only from the 9 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 Pod Security Risk calculated?

Violation points = 10 × privileged + 5 × host-namespace + 4 × hostPath + 3 × added-capability + 1 × runAsRoot pods, normalised per 100 pods. The weights follow the Pod Security Standards themselves: privileged containers are outside every profile and score 10, host namespaces and hostPath are baseline breaches, and runAsRoot only breaks restricted so it scores 1 — common but not by itself an escape. The admission mode is added as a flat penalty because audit-only enforcement stops nothing.

Why does Pod Security Risk matter?

A privileged pod is a root shell on the node with extra steps, and the reason clusters have eighteen of them is that audit-mode admission produced a warning nobody read.

What values do I need to enter?

This calculator takes 9 inputs: Pods in the cluster, Pods running privileged: true, Pods using hostNetwork, hostPID or hostIPC, Pods mounting a hostPath volume, Pods running as UID 0, Pods adding Linux capabilities, Pods with a read-only root filesystem, Pods with a seccomp profile applied, Pod Security Admission mode. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

What is the difference between baseline and restricted?

Baseline blocks known privilege escalations: privileged mode, host namespaces, hostPath, most added capabilities. Restricted goes further and requires non-root execution, a seccomp profile, dropped capabilities and no privilege escalation. Baseline is what you enforce first; restricted is where new workloads should start.

How do I handle workloads that genuinely need host access?

Give them their own namespace with a documented exemption, not a cluster-wide relaxation. CNI plugins, node exporters and CSI drivers legitimately need host access; your application does not. Pod Security Admission is configured per namespace precisely so the exception stays contained.

Related Calculators

Pod Security Risk Calculator | Calcrivo