Pod Security Risk Calculator

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

Inputs

Pods in the clusterpods

Pods running privileged: truepods

Pods using hostNetwork, hostPID or hostIPCpods

Pods mounting a hostPath volumepods

Pods running as UID 0pods

Pods adding Linux capabilitiespods

Pods with a read-only root filesystem%

Pods with a seccomp profile applied%

Pod Security Admission mode

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,090points

Violation Points per 100 Pods

90.8

Pods That Would Pass Restricted

890pods

Restricted-Ready Share

74.2%

Highest-Value Fix

Remove privileged: true — grant the one capability the workload actually needs instead

Step by step

Values used
Pods in the cluster = 1,200 pods; Pods running privileged: true = 18 pods; Pods using hostNetwork, hostPID or hostIPC = 34 pods; Pods mounting a hostPath volume = 76 pods; Pods running as UID 0 = 310 pods; Pods adding Linux capabilities = 42 pods; Pods with a read-only root filesystem = 38 %; Pods with a seccomp profile applied = 52 %; Pod Security Admission mode = Audit and warn only — 16
Pod Security Risk
Violation points = 10 × privileged + 5 × host-namespace + 4 × hostPath + 3 × added-capability + 1 × runAsRoot pods, normalised per 100 pods.
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.
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

How it works

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

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.

You might also need

Kubernetes RBAC Risk Calculator Container Escape Risk Calculator Admission Controller Coverage Calculator