Kubernetes Pod Security Standards in Practice: A Policy Review and Enforcement Guide

Overview

Kubernetes Pod Security Standards (PSS) define three progressively stricter security profiles for pods: Privileged, Baseline, and Restricted. Pod Security Admission (PSA) is the built-in admission controller that evaluates pod security against those profiles when a pod is created or updated.

The practical question is not whether every namespace should immediately use Restricted. It is whether each workload has been assessed, its required privileges documented, and its namespace assigned an appropriate policy with a clear path toward stronger controls.

PSA is configured through namespace labels. The three relevant modes are:

• enforce: rejects pods that violate the selected standard.
• warn: allows the request but returns a warning to the user or deployment tool.
• audit: allows the request while recording policy violations in audit annotations, subject to the cluster's audit configuration.

A common rollout pattern is to begin with warn and audit, fix or document violations, and then enable enforce on namespaces that are ready. Policy behavior can vary by Kubernetes version, so check the version-specific documentation before applying labels across a cluster. The Kubernetes version support and upgrade planning guide is useful when this review is part of an upgrade plan.

The table is a planning aid, not a substitute for the standard's versioned requirements. A pod can pass one profile and fail another, and a deployment may contain several pod templates that need separate testing.

Checklist by scenario

New application or namespace

1. Identify the workload owner and record whether the namespace contains applications, platform components, jobs, or third-party charts.
2. Start with the strongest realistic target. For a new application, test Restricted first rather than assuming a later migration will be easy.
3. Set warn and audit labels on the namespace during development, then review the resulting violations.
4. Define security contexts explicitly in the pod or container specification. Avoid relying on an image's undocumented defaults.
5. Test the complete delivery path, including Helm rendering, admission, init containers, sidecars, jobs, and rollout updates.

Existing application with unknown dependencies

1. Inventory all pod-producing resources, including Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, operators, and manually applied manifests.
2. Apply warn and audit before enforce. Capture violations during normal releases as well as scheduled jobs and recovery procedures.
3. Classify each finding as a required capability, an obsolete setting, an image problem, or an application that has not been tested under a non-root identity.
4. Fix the workload where possible. If a requirement is legitimate, document the reason, owner, scope, and planned review date.
5. Enable enforcement for a canary namespace first, then expand only after observing upgrades, restarts, scaling, and rollback behavior.

System or infrastructure namespace

Some node agents, networking components, storage plugins, monitoring tools, and security products may require host access or other privileges. Do not move these workloads to Privileged automatically. Verify the vendor's documented requirements, restrict permissions to the smallest namespace and service-account scope practical, and use cluster-level PSA exemptions only when they are explicitly configured and governed. An exemption should have an owner and an explanation; it should not become a general bypass for application teams.

CI/CD and policy-as-code workflow

Run policy checks before deployment so developers receive feedback before admission rejects a release. Kyverno and OPA Gatekeeper can complement PSA with organization-specific rules, such as required labels, approved registries, resource requests, or permitted image sources. They are not interchangeable with PSA: compare their enforcement modes, failure behavior, exemption model, and operational ownership before selecting one. Keep the cluster admission policy and the pipeline policy aligned so a manifest does not pass one checkpoint and fail unexpectedly at another.

What to double-check

• Namespace labels: Confirm that enforce, warn, and audit each name the intended profile and policy version. A label typo or unexpected version can produce a result different from the team's assumption.
• All pod templates: Check init containers, ephemeral containers, sidecars, and scheduled jobs, not only the primary application container.
• Security context placement: Distinguish pod-level settings from container-level settings. A value placed at the wrong level may not satisfy the relevant control.
• Identity and filesystem behavior: Confirm the image can run as the selected user, does not require a writable root filesystem, and writes temporary data to an approved writable location.
• Capabilities and privilege escalation: Remove unnecessary Linux capabilities, set privilege escalation deliberately, and verify that the application does not depend on an implicit root identity.
• Host integration: Review host networking, host ports, host PID or IPC namespaces, host paths, device access, and runtime classes. These are frequent reasons a workload fits Baseline poorly or fails Restricted.
• Tooling output: Test the exact rendered YAML generated by Helm, Kustomize, or another deployment tool. Source templates alone may hide environment-specific values.

Image behavior is often part of the policy problem. A smaller or security-oriented base image may help, but changing images can also alter users, filesystem paths, shells, certificates, and startup behavior. Review the container base image comparison guide before treating an image change as a simple compliance fix.

Common mistakes

Enforcing the strictest profile everywhere on day one can turn a security improvement into an emergency exception process. Start with evidence and namespaces that can be tested safely.

Using Privileged as the permanent answer hides technical debt. If a workload needs host access, document exactly which access is required and whether a narrower configuration or replacement is available.

Checking only Deployments misses CronJobs, DaemonSets, operators, and admission-created pods. A namespace is ready for enforcement only when its full workload inventory has been assessed.

Confusing PSA with a complete security program leaves gaps. PSA does not replace image provenance, vulnerability management, network controls, RBAC review, secrets handling, runtime monitoring, or resource governance.

Creating undocumented exemptions makes audits and incident response harder. Record the reason, scope, owner, compensating controls, and expiry or review date for every exception.

When to revisit

Revisit the policy before onboarding a new namespace, after changing a base image or deployment chart, when adding an operator or infrastructure agent, and before enabling enforcement. Repeat the review during Kubernetes minor-version upgrades because admission behavior, policy versions, and supported fields can change. Also reassess after a failed rollout, a migration to a new runtime, or a security incident.

A practical recurring workflow is:

1. Export or inventory namespaces and their PSA labels.
2. Find namespaces still using only Privileged or lacking an explicit policy decision.
3. Run representative workloads with warn and audit.
4. Group findings by reusable fix, such as a shared chart value or container security context.
5. Move a tested namespace to enforce, monitor releases and scheduled work, and record any approved exception.
6. Review the exception list and policy tooling whenever workflows or cluster versions change.

The goal is not a one-time compliance label. It is a maintained decision for every namespace: what the workload needs, what it is allowed to do, how violations are detected, and when the decision will be reviewed again.