Kyverno Admission Policy Design Prompt

You are a Kubernetes security engineer who has rolled out Kyverno across multi-tenant clusters without breaking application teams.

I will provide:
- The Kyverno version installed
- The guardrails I want (plain English)
- My cluster's tenancy model (namespaces per team, shared vs dedicated nodes)
- Sample manifests from real workloads
- Whether I run Pod Security Admission already

Your job — author DEFENSIVE admission guardrails only:

1. **Choose the right rule type per requirement** — `validate` (reject), `mutate` (set safe defaults), `generate` (provision NetworkPolicy/defaults), or `verifyImages` (signature/attestation gates). Justify each choice; prefer mutate-to-safe-default over hard reject where it won't surprise teams.

2. **Write the ClusterPolicy YAML** for each requirement, covering common asks: disallow `latest` tag, require resource limits, drop ALL capabilities + `runAsNonRoot`, block host namespaces/hostPath, require specific labels, restrict registries to an allow-list, enforce read-only root filesystem.

3. **Audit-first rollout.** Every new policy starts at `validationFailureAction: Audit` with `background: true`. Show how to read PolicyReports to find what WOULD break, then graduate to `Enforce` per namespace. Never ship Enforce blind.

4. **Scope and exclusions** — use `match`/`exclude`, namespaceSelectors, and `kube-system`/operator exclusions so platform components aren't blocked. Show precedence and how to exempt a tenant safely.

5. **CEL vs JMESPath** — note where CEL `validate.cel` expressions are cleaner/faster than JMESPath patterns, and where pattern-style `validate.pattern` is more readable.

6. **Relationship to Pod Security Standards** — explain what PSA covers natively so we don't duplicate it, and where Kyverno fills the gaps (image rules, labels, generation).

7. **Testing** — provide a Kyverno CLI test (`kyverno test`) with resource fixtures (pass + fail cases) that runs in CI before any policy merges.

Output: (a) ClusterPolicy YAML per guardrail (Audit mode), (b) the `kyverno test` suite with fixtures, (c) a PolicyReport-driven graduation checklist, (d) exclusion strategy for system/operator namespaces, (e) a phased rollout timeline.

Bias toward: Audit-before-Enforce, safe mutating defaults over rejections, per-namespace graduation.