Kubernetes Pod Security Context Checker

Workload label:

Name the pod, deployment, chart, or pull request being reviewed.

Target profile:

Choose how strict the local manifest review should be before applying or opening a pull request.

Manifest YAML or JSON:

Paste the workload manifest. The checker evaluates pod-level and container-level securityContext inheritance across all containers.

Review manifest input

{{ error }}

Manifest review notes

{{ warning }}

Finding row limit:

Use a compact value for screenshots or a larger value for review handoffs.

rows

{{ header }}	Copy
{{ cell }}
No rows for the current manifest input.

{{ result.patch }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Kubernetes workload hardening often turns on fields that are small in YAML but large in runtime effect. A pod that shares host namespaces, runs as UID 0, adds broad Linux capabilities, or disables syscall filtering gives its containers more access to the node and kernel than an ordinary application workload should have.

A security context is the Kubernetes place for declaring those runtime guardrails. Some settings live at the pod level and can apply to every container. Others live on individual containers and override pod defaults when both are present. Init containers and ephemeral containers need the same review because they can mount files, run commands, and carry their own privilege settings even when they do not run for the full application lifetime.

Pod Security Standards give reviewers a shared vocabulary. Baseline is compatibility-oriented and focuses on obvious host access and privilege escalation. Restricted expects a tighter posture for Linux workloads, including non-root execution, privilege-escalation denial, runtime-default or local seccomp, and narrow capability additions. A stricter organization review may add expectations such as read-only root filesystems and disabling automatic service-account token mounting.

Kubernetes security context review terms
Review area	Typical fields	Practical question
Identity	`runAsUser`, `runAsNonRoot`, group IDs	Can the process run without root identity inside the container?
Privilege	`privileged`, `allowPrivilegeEscalation`	Can the container gain more power than it starts with?
Kernel controls	Seccomp, AppArmor, capabilities, proc mounts, sysctls	Which kernel actions remain available after the container starts?
Host exposure	Host namespaces, host ports, hostPath volumes, Windows HostProcess	Does the workload cross normal pod isolation boundaries?

Pod defaults and container overrides resolve into guardrail checks for privilege, capabilities, and host access.

The common mistake is treating any visible securityContext block as enough. A pod-level runAsNonRoot does not cancel a container override that runs as UID 0, and a safe application image can still be deployed with host access or privilege escalation settings that widen the blast radius of a compromise.

How to Use This Tool:

Use the checker before applying a workload, reviewing a Helm render, or sending a manifest to a platform team. It is most useful with the rendered Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob, or List that will reach the cluster.

Enter a Workload label that ties copied rows, patch cues, and JSON output to a chart, pull request, ticket, or deployment name.
Choose the Target profile. Pod Security Baseline focuses on compatibility-oriented blockers, Pod Security Restricted raises stricter hardening gaps, and Hardened workload review adds read-only root filesystem and service-account token expectations.
Paste or browse Manifest YAML or JSON. Multi-document YAML and Kubernetes List inputs are supported when they contain workload pod specs.
Use Risky sample or Hardened sample to learn the result shape, and use Normalize YAML only when the pasted manifest needs cleaner formatting before review.
Check Manifest review notes before relying on the tables.
A parse error or "no workload pod spec" warning means the findings are not a valid security context review yet. Fix the YAML or paste a supported workload object first.
Start with Context Snapshot, then inspect Container Context Ledger and Hardening Findings. The snapshot gives totals, the ledger shows effective per-container settings, and the findings name the control, evidence, and remediation cue.
Use Security Context Risk Map to see which review area drives the risk score, then treat Remediation Patch as a starting fragment that still needs application and platform review.

Interpreting Results:

Read the highest-severity findings before the total score. One critical row such as privileged mode, Windows HostProcess, root execution under a strict profile, or unconfined seccomp can outweigh a longer list of low hardening reminders.

Risk score is a prioritization number derived from finding weights. It is not a Kubernetes severity standard.
Container Context Ledger shows whether a value was inherited from the pod or set on the container that owns the finding.
Target profile changes the standard being applied. Keep the same profile when comparing two versions of a workload.
Security Context Risk Map points to the review area that needs attention, such as Host access, Privilege escalation, Capabilities, or Seccomp/AppArmor.
Remediation Patch is review guidance. Test user IDs, write paths, low-port binding, service-account needs, and startup behavior before applying a fragment.

A clean result means no covered findings were detected for the selected profile. It does not prove that the cluster will admit the pod, that every Pod Security Standard control was modeled, or that the image, RBAC, network policy, and surrounding objects are safe.

Technical Details:

Kubernetes security context review has to resolve effective values before severity can be assigned. Pod-level settings provide defaults for overlapping fields, while container settings are more specific and override pod values. Regular containers, init containers, and ephemeral containers all matter because each can request runtime power that changes the workload's isolation.

The review is static. It reads declared manifest values from supported workload pod specs and does not inspect live pods, image users, namespace labels, admission exemptions, runtime class behavior, or node support for individual kernel features. That boundary is important when a manifest appears clean but a cluster policy, image default, or platform exception changes the real deployment decision.

Profile Behavior

Kubernetes pod security context target profile behavior
Profile	Posture	Finding behavior
Pod Security Baseline	Compatibility-oriented review for obvious host and privilege risks.	Flags critical host or privilege controls, with lower-severity reminders for unset hardening fields.
Pod Security Restricted	Stricter Linux workload posture aligned with common Restricted expectations.	Raises missing non-root guarantees, missing seccomp, unset privilege-escalation denial, and capability gaps.
Hardened workload review	Restricted-style review plus organization-style hardening prompts.	Adds service-account token review and treats missing read-only root filesystem as a stronger finding.

Rule Families

Security context rule families and covered signals
Family	Covered signals	Review meaning
Host access	`hostPID`, `hostNetwork`, `hostIPC`, shared process namespace, hostPath volumes, unsafe sysctls, `procMount: Unmasked`, host ports, Windows HostProcess	The workload may reach node namespaces, host files, host ports, or low-level kernel interfaces.
Privilege escalation	`privileged`, `allowPrivilegeEscalation`	The container may bypass normal isolation or gain more privileges after it starts.
Identity	`runAsUser: 0`, `runAsNonRoot: false`, or no effective non-root guarantee in stricter profiles	Root identity expands the impact of writable paths, mounted volumes, and process behavior.
Capabilities	Dangerous additions such as `SYS_ADMIN`, additions outside the Restricted allowance, and missing `capabilities.drop: [ALL]`	Linux capabilities grant slices of root-like power and should stay narrow.
Seccomp/AppArmor	Unconfined profiles, missing `RuntimeDefault` or `Localhost` seccomp in stricter profiles, unconfined AppArmor	Kernel syscall and mandatory-access-control profiles reduce what an exploited process can ask the kernel to do.
Filesystem and service account	Missing read-only root filesystem and automatic service-account token mounting under hardened review	These checks separate baseline policy compliance from tighter production hardening.

Risk Score

The score is a weighted sum of findings. Severity rows carry the actual decision, while the score helps sort containers and chart which review family is driving attention.

RiskScore = 34 C + 18 H + 8 M + 3 L + I

Here C, H, M, L, and I are counts of critical, high, medium, low, and informational findings. One critical, two high, three medium, and one low finding produce 34 + 36 + 24 + 3 = 97, which lands in the critical score band.

Security context risk score bands
Band	Score	Interpretation
Clear	0	No covered findings were detected.
Low	1 to 15	Hardening cleanup or advisory rows are present.
Medium	16 to 39	One or more meaningful gaps need attention before routine approval.
High	40 to 79	Blocker-level findings or several medium risks are likely.
Critical	80+	Multiple serious findings, or a very high-risk combination, should stop ordinary deployment flow.

The safe-sysctl review recognizes a fixed list: kernel.shm_rmid_forced, net.ipv4.ip_local_port_range, net.ipv4.ip_unprivileged_port_start, net.ipv4.tcp_syncookies, net.ipv4.ping_group_range, and net.ipv4.ip_local_reserved_ports. Confirm version-specific sysctl policy changes against the Kubernetes version and admission controls your cluster actually runs.

Limitations and Privacy:

The checker performs a browser-side manifest review. It does not contact a Kubernetes API server, inspect live pods, read container images, or ask an admission controller whether the cluster would accept the workload. Pasted manifests can include namespace names, image locations, mount paths, service-account choices, and internal topology, so handle copied output as sensitive review material.

It covers high-signal security context fields, but it is not a complete Pod Security Admission emulator for every Kubernetes version and policy control.
It cannot know whether a risky setting is justified for a node agent, storage plugin, network plugin, or break-glass debug workload.
It does not validate RBAC, network policy, image provenance, image users, secret content, runtime class behavior, namespace labels, policy-controller exemptions, or actual node support for seccomp and AppArmor.
Generated fixes should be tested with the application, especially when changing user IDs, read-only filesystem behavior, low-port binding, or service-account token mounting.

Advanced Tips:

Use Pod Security Baseline for early compatibility triage, then rerun with Pod Security Restricted before approving production Linux workloads.
Compare two manifest revisions with the same Target profile; otherwise severity changes may come from the profile rather than the workload.
Sort Hardening Findings by severity before acting on the patch cues. Critical host and privilege rows should be handled before low cleanup rows.
Use Container Context Ledger to find whether a risky effective value came from the pod default or a single container override.
Keep Finding row limit compact for screenshots and larger for security review handoffs where more rows need to stay visible.

Worked Examples:

Privileged node-style workload

A Deployment that sets hostNetwork: true, mounts a hostPath volume, and runs an init container with privileged: true should produce high or critical findings. The risk map should concentrate under Host access and Privilege escalation because the manifest crosses normal pod isolation before the application container starts.

Sidecar override under Restricted review

A web API may have pod-level runAsNonRoot: true and seccompProfile.type: RuntimeDefault, but one sidecar can still add SYS_ADMIN or omit allowPrivilegeEscalation: false. The ledger shows whether the safe value was inherited and which container still needs its own setting.

Parse warning before security review

A pasted values file, Service, or ConfigMap may trigger a no-workload warning because it does not contain a pod spec with containers. Render the chart or paste the workload object first; otherwise the absence of findings says nothing about the workload's security context.

FAQ:

Does a clean result mean Kubernetes will admit the pod?

No. Admission depends on namespace labels, cluster version, policy controllers, exemptions, and the exact object sent to the API server. A clean result only means the covered manifest signals did not produce findings for the selected profile.

Why does Restricted flag fields that Baseline allows?

Restricted expects tighter runtime isolation. Missing non-root guarantees, missing seccomp coverage, unset privilege-escalation denial, and capability gaps become stronger findings because they weaken container isolation.

Why are init containers and ephemeral containers included?

They can run commands, mount files, and set their own security context. A short-lived init container with host access or privileged mode can still create real node and workload risk.

Why is read-only root filesystem reported when it is not always required?

A writable root filesystem is treated as a hardening concern. It becomes stronger in the Hardened profile, but even lower-severity rows can be useful when reviewing production application containers.

What should I do with a parse error or no-workload warning?

Fix the YAML or JSON first, or paste the rendered workload instead of a Service, ConfigMap, Secret, or values file. Security context findings are meaningful only after a workload pod spec and at least one container are found.

Glossary:

Pod Security Standards: Kubernetes-defined policy levels that describe pod isolation expectations, commonly discussed as Privileged, Baseline, and Restricted.
Pod Security Admission: The built-in admission controller that can enforce, audit, or warn on Pod Security Standards at namespace scope.
Security context: A pod or container setting block that controls runtime identity, privilege, kernel filtering, and related isolation behavior.
Seccomp: A Linux syscall filtering feature commonly set through RuntimeDefault or a reviewed local profile for containers.
Linux capability: A narrower privilege grant than full root that can still give a process sensitive kernel or node-level powers.
Host namespace: A node-level namespace such as network, process, or IPC that a pod normally should not share unless it is a reviewed system workload.
Service-account token: A credential mounted into a pod so the workload can call the Kubernetes API. It should be disabled when the workload does not need API access.

References:

Pod Security Standards, Kubernetes Documentation.
Configure a Security Context for a Pod or Container, Kubernetes Documentation.
Pod Security Admission, Kubernetes Documentation.
Seccomp and Kubernetes, Kubernetes Documentation.
Linux kernel security constraints for Pods and containers, Kubernetes Documentation.