Kubernetes Pod Security Context Checker

A Kubernetes workload can run successfully while holding far more host privilege than its application needs. Root execution, host namespaces, broad Linux capabilities, writable system files, and unconfined kernel profiles all widen the damage possible after a container escape or application compromise. Security context review makes those permissions explicit before the manifest reaches a cluster.

Pod security context

Defaults that can apply across containers in one Pod, including user identity and seccomp settings.

Container security context

Settings for one regular, init, or ephemeral container. Container values can override inherited Pod values for supported fields.

Pod Security Standards

Kubernetes policy levels named Privileged, Baseline, and Restricted. Baseline blocks known privilege escalations; Restricted adds current hardening requirements.

Inheritance matters because an unset container field is not always missing. A Pod-level runAsNonRoot: true or seccompProfile.type: RuntimeDefault may protect every container, while a container-level identity value can replace the Pod default. Conversely, fields such as allowPrivilegeEscalation and capability changes normally need inspection on each container.

Policy profiles are useful comparison targets, not proof that a workload will be accepted. Admission behavior depends on the cluster's Kubernetes version, namespace labels, operating system, exemptions, and additional policies. Image contents and runtime behavior also matter: a non-root declaration can still fail at startup if the image expects to write privileged paths, and a generated hardening change can break an application that has not been prepared for it.

The safest review separates two questions. First, does the manifest express the expected security restrictions for every container path? Second, will the cluster enforce those restrictions and will the workload still function? Static manifest inspection answers the first question and prepares evidence for a server-side dry run, admission test, and runtime verification.

How to Use This Tool:

Choose the policy posture before reviewing the manifest because the same unset field can have different severity under Baseline, Restricted, and hardened review.

1. Select Target profile. Use Pod Security Baseline for a minimally restrictive check, Pod Security Restricted for the stricter Kubernetes posture, or Hardened workload review when read-only filesystems and service-account token mounting also need attention.
2. Paste or load the workload into Manifest YAML or JSON. Multi-document input and List resources are supported, along with Pods and common workload controllers that contain Pod templates.
3. Resolve a parse error or “no workload pod spec” finding before reading the score. A parsed ConfigMap or unrelated object is not evidence that any container was reviewed.
4. Inspect Critical and High findings first, then compare the container ledger with intended Pod-level inheritance. Review the generated patch as a starting point and test every change against the real image and workload.
5. Run a cluster-side dry run or admission check with the target namespace and policy version. Static review cannot see namespace exemptions, image metadata, runtime defaults, or other admission controllers.

Interpreting Results:

Critical and High findings are treated as blockers in the summary. Start with the evidence for privileged, host access, UID 0, privilege escalation, unconfined profiles, and dangerous capabilities. The total score helps prioritize one manifest or compare repeated reviews under the same profile, but it is not a compliance percentage and should not be compared across different profile settings.

• Confirm whether an apparent value comes from the Pod or the individual container before adding a duplicate setting.
• A clear result means no modeled finding was produced. It does not certify the image, cluster, network policy, RBAC, secrets, or runtime behavior.
• Read coverage values as the share of parsed containers with the named declaration, not proof that the declaration works for the image.
• Apply remediation only after reviewing application write paths, required ports, service-account API use, and kernel capability needs.

Technical Details:

Workload discovery follows Pod specs in Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, ReplicationControllers, Jobs, CronJobs, multi-document YAML, and List items. Regular, init, and ephemeral containers are reviewed separately. Linux-specific checks are skipped when spec.os.name is Windows, while Windows HostProcess remains a critical host-access signal.

Rule Core:

Pod-level defaults are resolved for runAsNonRoot, runAsUser, runAsGroup, seccomp, AppArmor, and Windows HostProcess. A value explicitly present on a container wins over the Pod value. Privileged mode, privilege escalation, root-filesystem mode, process mount, capability changes, and host ports are read from each container.

The unsafe-sysctl check allows a small explicit set including shared-memory cleanup, local port ranges, TCP syncookies, ping group range, and reserved local ports. Capability review treats ALL, SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, and several broad filesystem or kernel capabilities as dangerous.

Formula Core:

The risk score is the unbounded sum of finding weights. Critical, High, Medium, Low, and Info findings contribute 34, 18, 8, 3, and 1 point respectively. Multiple findings for one container all contribute, so the score can exceed 100.

These weights and bands are a local triage model, not part of the Kubernetes Pod Security Standards. The generated overlay proposes Pod-level non-root execution and RuntimeDefault seccomp plus per-container privilege-escalation denial, read-only root filesystems, and dropping all capabilities. It is intentionally broad and does not preserve workload-specific exceptions.

Limitations and Privacy:

Manifest text is parsed in the browser and is not uploaded for analysis. The source is limited to 256 KiB. Review the following limits before using the output as approval evidence.

• Static YAML cannot reveal the image's default user, filesystem needs, installed binaries, runtime syscalls, effective admission mutations, or node configuration.
• Pod Security Standards are versioned. The selected profile is a review model and may not match a cluster pinned to another Kubernetes release.
• The hardening patch is a review aid, not a safe automatic patch. It can remove a required capability, block a write path, or omit policy-specific fields.
• A successful client-side parse does not prove that the API server will accept the resource. Run a server-side dry run in the target cluster and namespace.

Worked Examples:

References:

• Pod Security Standards, Kubernetes Documentation.
• Configure a Security Context for a Pod or Container, Kubernetes Documentation.
• Linux kernel security constraints for Pods and containers, Kubernetes Documentation.
• How to enforce Kubernetes Pod Security Standards, Simplified Guide.