LEARN. PRACTICE. GROW.Concept and mechanism
Pod Security Admission distinguishes warn, audit, and enforce. A warning helps prepare migration but does not itself reject a Pod. Enforce applies to resulting Pods; an accepted Deployment can remain without replicas because its controller cannot create compliant Pods. Inspect events before investigating probes or networking. Pin the policy version when a controlled reference is needed, such as Restricted v1.35, and plan updates to that reference. In this path’s Linux examples, also review initContainers and other relevant containers so review does not stop at the main application.
Guided application
A security context should match application behavior. Running without root, preventing escalation, and reducing capabilities require functional validation. A read-only root filesystem may need a temporary volume at /tmp; that does not justify making the entire image writable. Before the production window, rehearse the complete template under the same policy and confirm the business transaction, not only object creation. If an initContainer violates policy, correct the specific need or use a compliant prior version. A broad namespace exception can affect applications absent from the decision, so it requires scope, deadline, and owner assessment.
The Deployment exists but events identify allowPrivilegeEscalation in the initContainer: correct that template and observe admission of new Pods.
Common pitfalls
Warn treated as blocking; accepted Deployment treated as completed release; inspecting only the main container; removing enforce for convenience.
Related topics: Secrets, encryption, and recovery · Artifacts, provenance, and vulnerabilities
Policy, template, and functional behavior need joint validation.
Reference: Pod Security Admission · Kubernetes v1.35; current six-domain CKS outline