Stop wildcard report watcher failures without broadening access #4929

🤖 Generated by the Agentic Engineer

Description

Fresh read-only verification after #4920 finds genuine, repeated error-level records from Kyverno's resource report controller. These are distinct from the formatter defect: a bounded sample contains valid JSON with explicit error severity, and Coroot still reports four unique errors.

Steps to Reproduce

1. Run Kyverno v1.19.1 with an admission-only validating policy whose resource kinds include a wildcard and with least-privilege reports-controller RBAC.
2. Observe the resource report controller building its watch set from that policy even when background processing is disabled.
3. The controller repeatedly logs a forbidden list request and a failed watcher start for kinds outside its reporting grants.

Expected Behavior

Keep admission enforcement, retirement identity fences, ordinary policy reporting and real error reporting intact while eliminating the incompatible reporting watch plan. Do not grant wildcard resource reads, disable reporting, filter these errors, or narrow the retirement fence merely to clear a counter.

Evidence and Scope

The deployed v1.19.1 source at pkg/controllers/report/resource/controller.go calls BuildKindSet over RemoveNonValidationPolicies; that filter retains validating policies regardless of background eligibility. BuildKindSet includes wildcard matches, and startWatcher performs an initial full-object list. This establishes the observed policy-to-watch-to-denial path, not a safe fix or proof of report freshness. The existing narrow reporting grants from #3760 address a different, finite kind set.

Acceptance Criteria

• Reproduce the admission-only wildcard case with native policy/controller controls before changing behavior.
• Select and document a repair that retains the admission fence and report coverage without widening secret or unrelated-resource access.
• Preserve genuine failures and test incomplete/denied observations as failures, not successful empty coverage.
• Obtain separate upstream authorization if the necessary repair belongs outside the portfolio.
• Merge the reviewed fix, verify deployed source and reporting freshness, and collect separated producer and Coroot readbacks.

Related to #4919 and #4819. Captured during active deployment acceptance; no permission, policy, reporting or suppression change was made. Priority High reflects sustained controller errors and uncertain reporting coverage; Effort High includes the compatibility decision and native/live evidence. Service class Standard; capture only, not an additional WIP start.