A rollout method for Kubernetes Pod Security Admission that separates admission modes, version labels, workload templates, Linux runtime controls, and exemptions. Includes a review matrix and concrete acceptance evidence.
At a glance
Key findings
- An enforce label controls admission of new Pods. It does not replace already running workloads or prove that their next replacement will start.
- Policy levels, admission modes, and policy versions are separate choices. Record all three rather than treating Restricted as a complete rollout plan.
- A useful acceptance record includes a successful replacement, a deliberately rejected violating Pod, and every exemption that can bypass the check.
Review the next Pod before changing the namespace
A namespace can look healthy immediately after a policy change and still contain a delayed outage. The running application has not been recreated, the nightly Job has not started, and the deployment controller has not attempted a replacement. Review those future creation paths before using current availability as evidence that a stricter policy is compatible with the workload. The rollout unit is the application lifecycle, not just the namespace label.
Pod Security Admission enforces policy on resulting Pods, while warn and audit also inspect workload templates. A Deployment can therefore be accepted before its Pods fail enforcement. Changing namespace enforcement reports existing Pod violations without evicting those Pods. [2][3]
Build an inventory that connects each workload to its owner, controller, container images, init containers, injected sidecars, and expected startup path. Include infrequent jobs and maintenance tools. For the first rollout, choose a namespace whose owner can exercise those paths and inspect controller events. Avoid starting with a broad collection of services for which nobody can explain what a successful replacement looks like.
Choose a mode, a level, and a version
Kubernetes defines Privileged, Baseline, and Restricted policy levels. Restricted adds controls intended for more constrained workloads, but several requirements depend on the policy version and operating system. Evaluate the rules for the version you intend to enforce, including their treatment of Linux and Windows Pods. Do not copy a version label from an unrelated cluster and assume it describes your installed environment. [1]
Each namespace mode selects a level and optional policy version. warn returns client warnings, audit adds audit annotations, and enforce rejects violations. Pin a reviewed minor version or explicitly accept the changing rules associated with latest. [7]
A practical starting arrangement is a deliberately chosen enforcement level with stricter warning and audit settings. Record why that combination exists and what evidence permits advancing it. Someone reading the configuration should be able to identify both the current boundary and the next intended boundary. Keep the version choice in the same review record so an upgrade does not quietly change the meaning of a previously accepted exception.
Three admission modes answer different questions
Warnings and audit records support the rollout; only enforce rejects a violating Pod.
Source. Kubernetes mode and version explanation [7], corroborated against current Pod Security Admission and exemption documentation [2].
Method. Categorical mapping of documented admission behavior, not an effectiveness measurement or cluster test. Current documentation confirms that exempt requests bypass all three modes. [2]
Accessible table and figure data
| Mode | Violating Pod | Evidence | Rollout use |
|---|---|---|---|
| warn | Allowed | Client warning | Find template issues |
| audit | Allowed | Audit annotation | Review policy violations |
| enforce | Rejected | Admission error | Block new violations |
| Mode | Violating Pod | Evidence | Rollout use |
|---|---|---|---|
| warn | Allowed | Client warning | Find template issues |
| audit | Allowed | Audit annotation | Review policy violations |
| enforce | Rejected | Admission error | Block new violations |
Turn warnings into a bounded rollout decision
Use the documented server dry-run label operation to inspect the proposed namespace change before applying it. Review the resulting messages by workload owner and exact failed requirement. A clean dry run is useful feedback, but it cannot exercise an application initialization path or prove that every future sidecar configuration was represented. Preserve that distinction when reporting progress. [3]
Group findings by the change they require. Some applications need a corrected manifest, some need a rebuilt image with suitable ownership, and others depend on a privileged operation that belongs in a different trust boundary. Asking each owner to explain the failed check produces a more useful backlog than treating every warning as a reason to exempt the namespace. The exception decision should follow diagnosis.
Then enforce the reviewed policy on the selected namespace and trigger representative replacement activity. Inspect the resulting Pod specifications after admission-time mutation, controller events, readiness, and the actual application operation. For a service, that might include a request that creates and later reads a file. For a scheduled workload, it includes the job's intended result. Record the commands and observations without retaining sensitive application data.
Check what the runtime will actually enforce
For Linux Pods, Restricted includes requirements concerning privilege escalation, non-root execution, seccomp, and Linux capabilities. For example, the documented capability rule drops ALL and permits only a narrow addition. These checks constrain configuration; they do not constitute a complete operating-system hardening assessment. Use the precise standard rather than an abbreviated checklist when deciding whether a manifest qualifies. [1]
An image that starts as a non-root user can still fail because its application expects a writable directory or incompatible group ownership. Review the Pod and container security contexts together with the image's filesystem requirements. Kubernetes documents distinct user, group, and volume-related settings; changing one field does not establish that every mounted path has the intended ownership. Validate the actual read and write operations the application needs. [5]
Kernel protections also depend on the runtime and host configuration. Kubernetes describes privileged containers as bypassing several of the normal seccomp, AppArmor, and SELinux constraints. A namespace policy is therefore one layer in a wider review that includes node maintenance and runtime behavior. Do not use an admission pass to claim that a vulnerable kernel, unsafe mount, or unrelated permission problem has been repaired. [4]
Make exemptions and namespace changes accountable
An exemption should name the necessary operation, the owner, the reason a narrower design was not chosen, and the conditions for removing it. If the workload needs host access for a specific operational purpose, explain that purpose in terms a reviewer can evaluate. A permanent label saying infrastructure is not enough to distinguish a justified capability from an inherited convenience.
Kubernetes cautions against exempting controller identities that create Pods for other users. Such an exemption also bypasses checks for those users' workloads. Review the actual Pod-creation identity, not only the person editing a Deployment. [2]
Namespace labels also belong in the authorization review. Kubernetes RBAC guidance notes that permission to patch namespaces can weaken Pod Security and network policy boundaries. Restrict who can alter the governing labels and make those changes visible in the normal configuration review process. Otherwise, the team enforcing the policy may be different from the team that can silently remove it. [6]
Require evidence from both allowed and denied paths
The acceptance record should identify the cluster context, namespace, reviewed policy version, admitted workload revision, and expected behavior. Include one intentionally noncompliant test Pod in an isolated fixture and confirm that enforcement rejects it. Keep the test distinct from production workload mutations. A successful application rollout alone does not demonstrate that the rejection path is active.
Also record an ordinary replacement that becomes ready, an infrequent job that completes its intended work, and any injected containers included in the final Pod. Note which paths remain untested. If a failure forces a temporary relaxation, preserve the reason and the exact narrower or earlier policy to restore. Do not remove all controls simply because one application needs a documented exception.
Revisit this evidence when upgrading Kubernetes, changing the enforced policy version, replacing an admission webhook, or changing a base image that alters runtime identity. Those changes can affect a different part of the same creation path. A concise record of the accepted manifest and observed operation gives the next reviewer a starting point that a screenshot of a healthy namespace cannot provide.
Method and provenance
Primary documentation reviewed on August 28, 2026. The article combines the cited platform behavior with an original review procedure and visual explanation. Suggested acceptance cases are not reported experiments.
No cluster rollout or kernel control was tested. The procedure targets built-in Pod Security Admission and distinguishes Linux requirements from operating-system-specific rules. It is not a complete cluster security standard.
AI assistance. AI assistance was used for source research, drafting, editorial checks, and figure preparation. No human technical review or production experiment is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Kubernetes Pod Security Standards Kubernetes. Accessed .
- Kubernetes Pod Security Admission Kubernetes. Accessed .
- Kubernetes namespace label enforcement Kubernetes. Accessed .
- Kubernetes Linux kernel security constraints Kubernetes. Accessed .
- Kubernetes Pod and container security contexts Kubernetes. Accessed .
- Kubernetes RBAC good practices Kubernetes. Accessed .
- Kubernetes 1.23 Pod Security Graduates to Beta Kubernetes. Published . Accessed .