Review Kubernetes Pod Security in Coding-Agent Patches

Last reviewed: November 6, 2026 (Asia/Shanghai); official references checked November 5 UTC.

Direct answer

Review Kubernetes Pod security in a coding-agent patch against the final rendered workload and the namespace’s admission policy. For a typical Linux application, require non-root execution, disabled privilege escalation, an explicit seccomp profile, and dropped Linux capabilities. Inspect every application container, init container, and proposed debugging container. Check host namespaces and volumes as well as securityContext fields.

Then prove enforcement with a valid Pod fixture and one deliberately invalid variant in an authorized test environment. A successful Deployment dry run is insufficient: Kubernetes applies Pod Security Admission’s enforce mode to the resulting Pods, while workload templates receive warn and audit checks. Treat warnings, admission rejection, and runtime behavior as separate evidence.

The Pod Security Standards define the policy requirements. The security-context guide explains how runtime settings apply and override one another. The Pod Security Admission reference defines enforcement modes and exemptions.

Who this is for

Use this workflow when a coding agent edits Kubernetes manifests, Helm charts, Kustomize overlays, or deployment generators for Linux application workloads. It suits maintainers reviewing a small deployment change before merge. Windows workloads, privileged infrastructure components, and custom runtime policies need their own platform-specific review.

Give the agent the approved runtime policy and relevant manifest paths. Ask it to render and propose a patch. Keep changes to namespace enforcement, admission exemptions, and production deployment authority under the platform team’s established approval process.

Key takeaways

• Inspect rendered Pod specifications, including init containers and container-level overrides.
• Restricted policy adds requirements beyond Baseline, including non-root execution and Linux-specific capability, seccomp, and privilege-escalation controls.
• Set container-only controls on each container; a Pod-level setting cannot supply fields that exist only in a container’s security context.
• readOnlyRootFilesystem is a useful additional requirement, but it is not required by the Restricted standard.
• warn and audit allow violations. Only enforce rejects a violating Pod, subject to configured exemptions.
• Pair admission checks with runtime checks; admission success does not prove that an image starts or that volume permissions work.

Sources checked

Four primary Kubernetes references were retrieved successfully on November 5, 2026 UTC:

• Pod Security Standards defines Baseline and Restricted controls, their field paths, permitted values, and operating-system qualifications.
• Configure a Security Context for a Pod or Container documents Pod and container scope, container overrides, process identities, capabilities, seccomp, and read-only root filesystems.
• Pod Security Admission documents namespace labels, policy versions, enforcement modes, workload-template behavior, and exemption dimensions.
• kubectl create documents server-side dry runs and strict validation. A server dry run submits the request without persisting the resource.

These maintained technical references support an evergreen review task. Match the documentation and policy version to the target cluster’s minor release before adopting individual controls. The workflow below is a recommendation; this article reports no executed cluster tests or deployment results.

Contract details to verify

Write the review contract before asking the agent to fix a deployment failure. Otherwise, a request to make a container start can turn into an unexplained privilege increase.

Keep image identity and Kubernetes API permissions in their own review records. Use Pin Container Images by Digest When Coding Agents Edit Deployments to establish what runs. Use Review Kubernetes RBAC in Coding-Agent Patches to establish what its service account can request from the API server.

Resolve Pod defaults and container overrides

Pod-level settings apply across containers where supported. When the same setting exists at both levels, the container’s value overrides the Pod’s value. An agent can therefore preserve a reassuring Pod-level runAsUser while introducing a root override in one container.

For a Linux application intended to meet Restricted policy, inspect these controls together:

This table covers common review points, not the complete Restricted specification. Check the remaining fields against the selected policy version, including volume types and any changed AppArmor, SELinux, sysctl, probe, or lifecycle-hook settings.

The following fragment illustrates placement. Merge it into a complete Pod specification with a reviewed image and application configuration; it is not a standalone manifest. UID and GID 10001 are examples that must match the image and storage contract.

spec:
  os:
    name: linux
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        readOnlyRootFilesystem: true

Apply the container controls to each relevant entry, including init containers. Review ephemeral-container additions through their separate update path when debugging access is enabled. Do not assume the application container’s settings cover another container.

A read-only root filesystem does not make mounted volumes read-only. List the paths the application must write, provide narrowly scoped writable storage, and test permissions with the chosen UID and GID. Fix an incorrect image path or storage permission directly instead of dropping non-root execution to make startup succeed.

Render the actual candidate

Render every affected environment with its real values and overlays. Compare the resulting Pod specifications, not just the chart’s defaults. An environment value, sidecar, or init container can override an otherwise correct base patch.

For a Deployment, inspect .spec.template.spec; a CronJob nests its Pod template further down. Have the agent list each effective container’s security fields and every changed host-access field. Reject a summary that reports only one securityContext block while omitting the other containers.

Preserve labels, annotations, and the RuntimeClass when preparing test fixtures because they can affect admission and injection. If a webhook adds containers, inspect the admitted output as well as the renderer’s output. A hand-built Pod fixture cannot reproduce every controller-specific admission condition, so also exercise the real workload path in a disposable environment when those conditions matter.

Check the namespace before testing enforcement

Inspect the actual namespace labels. pod-security.kubernetes.io/enforce: restricted selects rejection behavior; a warn: restricted label alone does not. Record each applicable mode’s version label, such as pod-security.kubernetes.io/enforce-version, and the approved minor version it selects. A version pin makes the policy choice explicit; review it when upgrading the cluster.

Also confirm that the test username, namespace, and RuntimeClass are not exempt. Kubernetes skips all three admission modes for requests matching a configured exemption. An unexpectedly accepted negative fixture may therefore reveal a test-environment mismatch rather than a correct manifest.

Do not have the coding agent weaken labels or add an exemption to resolve a failed test. Return the workload change for repair, or route a documented exception through the platform team’s policy process.

Exercise a valid Pod and an intentional violation

Use an existing disposable namespace configured with the intended enforcement policy and a non-exempt test identity. The names review-cluster and agent-review below are examples: select the authorized context and namespace explicitly.

Have the repository renderer produce one Deployment as rendered-deployment.json. With jq installed, extract its Pod template while preserving template metadata:

jq -e '
  if .kind != "Deployment" then
    error("expected one rendered Deployment")
  else
    {
      apiVersion: "v1",
      kind: "Pod",
      metadata: {
        name: "pod-security-review",
        labels: (.spec.template.metadata.labels // {}),
        annotations: (.spec.template.metadata.annotations // {})
      },
      spec: .spec.template.spec
    }
  end
' rendered-deployment.json > review-pod.json

kubectl --context review-cluster --namespace agent-review \
  create --dry-run=server --validate=strict -f review-pod.json \
  -o json > admitted-review-pod.json

Choose a fixture name absent from that namespace. Check the command’s exit status before continuing, then inspect the admitted object’s effective security settings. The request should pass admission, but this dry run neither creates a running Pod nor proves application startup. Keep the full object private when it contains sensitive configuration; attach only the relevant sanitized fields and diagnostics to review.

Next, make one targeted violation in a copy:

jq '.spec.containers[0].securityContext.allowPrivilegeEscalation = true' \
  review-pod.json > review-pod-escalation.json

kubectl --context review-cluster --namespace agent-review \
  create --dry-run=server --validate=strict -f review-pod-escalation.json

Under the applicable Restricted policy, this variant should be rejected for its privilege-escalation setting. Require that specific policy diagnostic. A connection error, RBAC denial, existing-name conflict, or malformed fixture is not evidence that Pod security enforcement worked. Restore the unchanged valid fixture between further mutations.

Finally, use the approved deployment workflow in the disposable environment to run a harmless startup and storage smoke test. Verify the effective process identity, necessary writes, and the expected failure of a harmless write to the root filesystem when it must be read-only. Record admission checks separately from runtime results.

Failure modes

A Deployment passes while its Pods cannot start. Pod enforcement happens on resulting Pod objects. Test the Pod specification and then the real controller path.

Warnings are treated as rejection. Read the mode labels and command result. A warning accompanied by success is allowed admission.

One init container restores privilege. Inventory all container lists and introduce a negative fixture in an init container to verify coverage.

An override defeats the Pod default. Resolve overlapping settings per container rather than checking only the parent block.

Restricted is mistaken for the entire application policy. Add independent checks for requirements it does not cover, including a read-only root filesystem.

The agent fixes a startup error by broadening authority. Investigate UID, file ownership, writable paths, and application assumptions before requesting any policy exception.

FAQ

Does runAsNonRoot remove Linux capabilities?

No. Non-root execution, capability dropping, and disabled privilege escalation are separate controls. Review all three.

Does RuntimeDefault guarantee identical syscall filtering everywhere?

It selects the node’s container-runtime default seccomp profile. Test on the target runtime; the setting does not identify one universal profile across runtimes.

Is server-side dry run enough to approve the patch?

It provides admission evidence without persisting the resource. It does not pull the image, start the process, exercise storage, or establish readiness. Add runtime checks in the approved test environment.

Must every application meet this exact example?

The selected cluster policy and application requirements decide the contract. Any exception needs a stated reason, scope, owner, and review path. Keep an exception visible rather than silently disabling enforcement.

Reader next step

Choose one agent-written Deployment change. Render its effective Pod template, resolve every container’s security settings, and record the namespace’s enforcement mode and version. Submit the valid Pod and one privilege-escalation variant through server-side dry run, then run the approved startup and storage smoke test. Attach the revision, rendered output, expected decisions, and observed diagnostics to the pull request before approval.