A review finds that many Kubernetes pods run as privileged containers with root users and host access, and developers can deploy any pod specification they like. The platform team wants such pods rejected before they are ever scheduled. Which control fits?

Kubernetes admission control evaluates every request to create or modify an object after authentication and authorization but before the object is persisted and scheduled. Built-in Pod Security Admission enforces the Pod Security Standards, and the restricted profile disallows privileged containers, host namespaces, host path mounts and running as root, among other settings; policy engines such as validating admission webhooks can enforce similar or custom rules. Applying such a policy to namespaces rejects noncompliant pod specs at submission, which is exactly the before-scheduling requirement, and pairs naturally with RBAC that limits who can deploy where. A network policy controls which pods can communicate over the network; a privileged pod restricted by network policy still runs with host-level capabilities and can escape to the node. A horizontal pod autoscaler adjusts replica counts based on load; it neither inspects security context nor blocks privileged pods. A registry vulnerability scan evaluates the image's packages; a clean image can still be deployed with a privileged, root, host-access pod spec. Exam caveat: least privilege in orchestration combines admission policy, RBAC and namespace isolation; no single control is sufficient. Operational check: label a test namespace for the restricted profile in enforce mode, attempt to create a privileged pod, and confirm the API server rejects it with a policy violation message.