Pin pod-security policy behaviour before its policy format migration #5143

🤖 Generated by the Agentic Engineer

Description

Before rewriting the pod-security policy for #4996, pin what it decides today. Its only fixture checks three provider Deployments for the pod-level seccomp rule. Nothing pins the container hardening checks (privilege escalation, privileged, non-root, dropped capabilities), init or ephemeral containers, the container seccomp override, the namespace exemptions, or which workload kinds the policy judges. A rewrite could change any of those without a test noticing.

This is a test-first slice of the already-started migration. It leaves the policy and its enforcement settings unchanged.

Tasks

• Pin allowed and rejected Pods for each of the three rules, including init and ephemeral containers and a container-level non-root requirement.
• Cover the namespace exemptions with an otherwise-rejected Pod in an exempt namespace and the same Pod outside it.
• Record which controller kinds the policy judges through its generated rules (Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob).
• Prove that weakening each rule makes its expected denial results fail, and pass the policy fixture and evaluation gates in CI.

Priority High; service class Risk reduction. This supplies the behaviour baseline required before the pod-security rewrite, with bounded test-only effort. Part of #4996.