Pod Security Admission and runtime constraints

The mechanism

Pod Security Admission evaluates Pod configurations against defined security standards. The built-in levels include Privileged, Baseline and Restricted. Namespace labels select enforcement, audit and warning behavior, and can pin the standard version used for evaluation.

Admission examines configuration before it is accepted. It is not a complete runtime monitor or proof that an application cannot misuse permitted access. Network policy, identity, image provenance and application authorization remain separate controls.

For ParcelOps, start by understanding Restricted-compatible settings and platform prerequisites. A non-root process, limited capabilities, no privilege escalation and an appropriate seccomp profile reduce available authority, but their exact compatibility depends on the image and workload.

Worked example

This offline security-context fragment illustrates common Restricted-oriented settings for a Linux container. It is not a claim that the complete workload passes every policy or runs successfully. The image must support non-root execution.

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: api
    image: registry.example/parcelops/api:reviewed-version
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

Practice: predict, inspect, explain

Offline exercise. Explain the purpose of each field and identify what it does not constrain. For example, dropping Linux capabilities does not by itself deny outbound network access. Then compare warn, audit and enforce modes conceptually without changing namespace labels.

Expected observation: an admission warning is not an enforcement denial. Write a proposed rollout plan that first discovers incompatibilities, then fixes workloads before enforcement. Keep version pinning explicit so a policy change does not arrive as an unexplained surprise.

Troubleshooting and trade-offs

If a workload is denied, read the exact violated control and image requirements. Do not disable the entire admission policy to make one application start. If non-root execution fails, inspect filesystem ownership and application ports in the image build. A policy-compliant manifest can still contain a vulnerable application or excessive API credentials.

Interview practice

Completion check

Map each security-context field to its mechanism and name three separate controls still needed.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

• Official documentation: Pod security admission
• Official documentation: Pod security standards
• Official documentation: Overview