Kubernetes Pod Security Context Checker

Kubernetes pod security context review is the practice of checking whether a workload asks the container runtime for host access, root identity, extra Linux privileges, weak isolation, or writable runtime surfaces it does not need. The same application image can be much safer or much riskier depending on fields such as runAsNonRoot, allowPrivilegeEscalation, capabilities, seccompProfile, host namespace flags, hostPath volumes, and service-account token mounting.

The review matters before a manifest reaches a cluster because several risky settings are visible in source text. A Deployment that looks normal can still bind a host port, mount the node filesystem, run as UID 0, add NET_ADMIN, or leave seccomp unset. Those choices affect what a compromised container can see or change after it starts.

Pod security context is also easy to misread. Some fields can be set once at pod level and inherited by each container, while other fields belong only on a container. Init containers and ephemeral containers deserve the same attention as the main application container because they can run with their own privileges. A clean manifest review does not prove that the cluster will admit the pod, that the image is safe, or that a business exception is justified. It means the checked manifest does not show the risk signals covered by the review settings.

The strongest use is a pull-request or chart review before applying a workload. Treat the output as security evidence for one manifest snapshot, then pair it with cluster policy, image scanning, runtime testing, and any waiver process your team uses.

Technical Details:

A Kubernetes pod spec defines the runtime contract for all containers in the pod. Pod-level security context can supply defaults such as non-root identity and seccomp profile. A container-level security context can then provide fields that apply only to that container. Good review starts by resolving the effective setting for each container, not by reading pod fields and container fields as separate evidence.

The Kubernetes Pod Security Standards define Baseline and Restricted policy profiles for common hardening expectations. Baseline limits known privilege escalation paths while leaving room for common workloads. Restricted expects a tighter posture for Linux containers, including non-root execution, limited capability additions, a non-unconfined seccomp profile, and explicit privilege-escalation controls. The hardened review profile here keeps the Restricted checks and adds practical workload cues such as read-only root filesystem and service-account token review.

Rule Core

The review is deterministic and rule-based. It parses workload resources, extracts each pod spec, resolves selected inherited fields, and assigns a severity, category, evidence sentence, and remediation sentence for each matched signal.

Risk score is a sum of finding weights. The score is not capped, so one manifest with many critical and high findings can climb well past the critical threshold. The summary also counts critical and high findings as blockers because those rows usually need a fix or a deliberate exception before the manifest is applied.

The parser accepts pod specs nested under common controllers and jobs, including multi-document input and List resources. It does not contact the cluster, run admission control, expand Helm templates, fetch referenced policies, inspect image users, or validate whether a generated patch is ready to apply without review.

Everyday Use & Decision Guide:

Name the manifest in Workload label before sharing results. The label does not change the checks, but it keeps copied rows, JSON, and downloaded review artifacts tied to the pod, deployment, chart, or pull request under review.

Choose Target profile before reading the score. Pod Security Baseline is useful for a first look at obvious host and privilege risks. Pod Security Restricted is the better default for application workloads that should run with stronger Kubernetes Pod Security Standards expectations. Hardened workload review adds read-only root filesystem and service-account token checks for teams that want an extra handoff cue.

• Paste a Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob, List, or multi-document manifest into Manifest YAML or JSON.
• Use Browse YAML or drag a YAML, YML, JSON, or TXT file onto the textarea when copying from a repository is awkward. Files over 6 MiB are rejected before parsing.
• Use Risky sample and Hardened sample to see how the summary, finding rows, and risk map respond to very different security contexts.
• Use Normalize YAML after pasting from a chart render, terminal output, or editor buffer when whitespace or formatting makes review hard to scan.
• Use Finding row limit to keep screenshots compact or raise it when a pull-request handoff needs more rows. The control accepts 10 to 250 rows.

The safest reading path is summary, then Context Snapshot, then Hardening Findings. The summary gives the finding count, blocker count, container count, target profile, and score label. Context Snapshot checks whether the parser found the expected workloads and containers. Hardening Findings is where the evidence and remediation text live.

A low or clear score is not a cluster approval. It means the manifest text did not match the checked rules under the selected profile. Before merging, confirm that the rendered manifest matches the reviewed input, that any exceptions are documented, and that cluster admission policy still applies the intended controls.

Step-by-Step Guide:

Review one rendered workload set at a time so the score, container ledger, finding rows, and patch fragment describe the same manifest snapshot.

1. Enter a traceable name in Workload label, such as payments-api deployment, then confirm Context Snapshot shows the same label in the first row.
2. Select Target profile. Watch the profile badge change between Baseline, Restricted, and Hardened so the summary matches the release gate you mean to review.
3. Paste or load source in Manifest YAML or JSON. The status line should show character count or file-load status before you use the results.
4. If Review manifest input appears, fix the listed parse problem first. A YAML parse error, empty input, or JSON-only fallback warning can prevent reliable workload extraction.
5. Check Manifest review notes. If the manifest parsed but no pod spec was found, paste a supported workload resource with spec.containers or spec.template.spec.containers.
6. Open Context Snapshot and verify Parsed workload specs, Containers reviewed, Seccomp coverage, Non-root coverage, Drop ALL coverage, and Read-only root filesystem.
7. Open Container Context Ledger when a finding points to a specific container. Compare the effective runAsNonRoot, runAsUser, Seccomp, allowPrivilegeEscalation, Privileged, Capabilities, and Read-only rootfs columns.
8. Open Hardening Findings and fix rows in severity order. Use Control, Evidence, and Remediation as the review note for the pull request.
9. Use Security Context Risk Map to see whether remaining issues cluster around host access, identity, capabilities, seccomp, filesystem, service-account tokens, or manifest shape.
10. Read Remediation Patch as a starting overlay. It adds common hardening fields, but it still needs review against the real workload, writable paths, sidecar needs, and image user behavior.

A ready handoff has no critical or high rows in Hardening Findings, expected container counts in Context Snapshot, and coverage rows that match the profile your team intends to enforce.

Interpreting Results:

The first critical or high row in Hardening Findings matters more than the total score. A single privileged, hostPID, runAsUser, or seccompProfile finding can be enough to block a release review even when the rest of the manifest looks tidy.

Do not overread the patch fragment. It shows common security context additions, but it cannot know whether an application needs a writable directory, which UID the image supports, or whether an exception is accepted by the cluster. Test the changed manifest before closing the review.

Worked Examples:

Risky Deployment under Restricted review

The risky sample loads a Deployment with hostNetwork: true, a hostPath mount for /var/run/docker.sock, a privileged init container, an application container running as UID 0, allowPrivilegeEscalation: true, added NET_ADMIN, and a hostPort. With Target profile set to Pod Security Restricted, the summary reports 20 findings, 13 blockers, 3 containers, and score 307 (critical). Hardening Findings starts with critical rows before moving into high, medium, and low rows.

Hardened sample with inherited pod context

The hardened sample sets pod-level runAsNonRoot: true, runAsUser: 10001, and seccompProfile.type: RuntimeDefault, then gives each container allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, and capabilities.drop: [ALL]. Under Hardened workload review, the summary reports 0 findings, 2 containers, and score 0 (clear). Context Snapshot shows 100% coverage for seccomp, non-root, Drop ALL, and read-only root filesystem.

No workload pod spec in the input

A ConfigMap, Service, or unrelated YAML document can parse successfully while still having no pod spec. In that case, Manifest review notes says no workload pod spec was found, Context Snapshot shows Parsed workload specs as 0, and Hardening Findings adds a high Manifest shape row for Pod template. Paste a supported workload resource before using the score as review evidence.

Broken YAML paste

A manifest copied with missing indentation or an incomplete list item triggers Review manifest input with a YAML parse message. The summary changes to Check input, and the result tables should not be used for release review. Fix the syntax, use Normalize YAML if it helps clean formatting, and verify that Containers reviewed matches the expected workload before continuing.

Responsible Use Note:

Kubernetes manifests can reveal namespaces, service names, registry hosts, image names, node paths, ports, security exceptions, and internal architecture. Paste the smallest useful manifest for review when working with sensitive workloads, and treat copied rows, chart images, patch text, and JSON output as security evidence.

Manifest parsing and selected-file reading happen in the browser session. The result can still contain the same sensitive workload details, so handle shared outputs under the same rules as the source manifest.

FAQ:

Glossary:

securityContext

Pod or container settings that control runtime identity, privileges, Linux security options, and filesystem posture.

Pod Security Standards

Kubernetes policy profiles that describe Baseline and Restricted controls for pod security posture.

Restricted

A tighter Kubernetes profile that expects non-root execution, limited capabilities, seccomp, and explicit privilege-escalation controls for Linux workloads.

seccomp

A Linux syscall filter mechanism commonly set to RuntimeDefault or a reviewed Localhost profile.

Linux capabilities

Fine-grained privilege flags that can grant powers such as network administration without making every process fully privileged.

hostPath

A volume type that mounts a path from the Kubernetes node into a pod.

service-account token

A Kubernetes credential mounted into a pod when the workload needs to call the Kubernetes API.

Risk score

The sum of severity weights from all matched findings under the selected target profile.

References:

• Pod Security Standards, Kubernetes.
• Configure a Security Context for a Pod or Container, Kubernetes.
• Linux Kernel Security Constraints for Pods and Containers, Kubernetes.
• Pod Security Admission, Kubernetes.