DAILY ANALYSIS
How to verify Kubernetes Pod Security enforcement before rollout
Test whether Kubernetes rejects pods that violate your security policy while keeping compliant deployments and jobs running.
Test what the controller creates
A Kubernetes Deployment can be accepted even if the pods it attempts to create later are rejected. Pod Security Admission applies enforcement to the resulting Pod objects. Audit and warning modes can flag violations in workload templates earlier. During a rollout, checking only whether the Deployment object exists can miss a blocked release. Inspect controller events and pod readiness to establish whether the workload actually started.
Find the workloads that need changes
Inventory namespace policy labels, their versions, and any configured exemptions. Start with warnings and audit records at the intended policy level, and use a server-side dry run of the namespace enforcement label to check existing pods without changing policy. For Linux workloads, review the Restricted profile requirements for running as non-root, preventing privilege escalation, and setting seccomp. Check init containers as well as application containers. Test image and filesystem permissions after changing the runtime identity.
Run one passing and one failing case
In a hypothetical staging namespace, the platform team pins the intended Restricted policy version and enables enforcement. It rolls out a compliant Linux workload and confirms that its pods become Ready. It then uses a disposable test Deployment whose pod template explicitly sets the user ID to zero. The team confirms that the controller reports a Pod Security rejection and creates no running pods for the test Deployment. Capture the specific rejection reason so a scheduling failure or an unrelated admission rule cannot be mistaken for a passing security test.
Roll out in groups and track exceptions
Start with a namespace whose owners can verify application health and restart behavior. Compare results for deployments, scheduled jobs, and any operational tasks that create pods. Record the namespace, policy version, test results, and owner. If a workload needs an exception, document its exact scope and expiration. Review configured exemptions separately because matching requests skip Pod Security Admission checks.
Keep the evidence in scope
Changing the namespace label does not evict existing pods. Review those pods and plan a controlled replacement where needed. A successful admission test demonstrates that the selected policy evaluated the tested requests. Image provenance, network isolation, and runtime monitoring each require their own evidence.