Skip to main content
Kyverno is a Kubernetes-native policy engine for validation, mutation, generation, and image verification - no new language required, policies are written as Kubernetes resources.

​
What Radar Shows

Policy / ClusterPolicy Detail View:
  • Enforcement badge: what the policy does at admission, not just what validationFailureAction reads. Enforce in red, Audit in yellow, and Background only (or Inactive, when background scanning is off too) in orange for a policy that declares Enforce but is kept out of the admission webhook by spec.admission: false
  • Configuration: admission and background scanning, webhook timeout, failure policy, schema validation
  • Rule type summary (validate/mutate/generate/verifyImages counts)
  • Individual rules with type badges and match/exclude indicators
  • Auto-generated rules list
PolicyReport / ClusterPolicyReport Detail View:
  • Visual result bar chart (pass/fail/warn/error/skip proportions)
  • Scope and source information
  • Individual results with status badges, severity levels, policy/rule names
  • Expandable details: message, category, source, affected resources
  • Problem detection (AlertBanner for failures or errors)
Resource Browser: Smart columns show status (colored by worst outcome), enforcement at admission, rule counts, and pass/fail/warn/error/skip breakdowns.

​
The per-policy resource view

A resource page answers “which policies does this break”. The policy page answers the other direction: which resources does this policy cover, and what happens to them, grouped by rule. Keep these semantics in mind when reading the results:
  • Report producers share the same fields. Trivy and Falco can write their own identifiers into results[].policy; Radar labels those results by producer instead of presenting them as Kyverno policy outcomes.
  • Status wording follows the rule type. For example, a mutating rule’s fail means the mutation was not applied, while a generate rule’s pass means the resource was generated.
  • Enforcement follows declared operations. A CREATE-only policy rejects new resources, not updates to existing ones. A resource already failing that rule is grandfathered until it is recreated.
Passing resources are available behind an all N passing disclosure. Large subject lists are initially bounded, with a Load the rest control when more results are available. GlobalContextEntry gets its own view because a policy referencing an entry that never resolves fails at evaluation time with no obvious cause. Kyverno records success as status.lastRefreshTime and records failure as nothing at all - no message, no condition, no reason. So the page reports “has refreshed” versus “has never refreshed” (with the entry’s age turning the second into a diagnosis) and says outright that Kyverno records no reason, rather than inventing one. The count of queued work appears on the policy itself, above its configuration. The section is silent when a policy has nothing queued, so it stays out of the way for policies that only validate. UpdateRequest is where a generation or mutate-existing operation that silently stopped is diagnosed: the policy may report Ready while the target never appears, with a request sitting in Pending as the remaining evidence. Radar handles both Kyverno request shapes and links each request to the trigger resources it records. EphemeralReport holds a background scan’s findings before they are folded into a PolicyReport. Kyverno deletes these reports quickly after processing, so an empty list normally means the work completed rather than that reporting is unavailable.

​
Supported CRDs

PolicyReport findings are policy posture, not live operational failure, so they are not part of the /api/issues stream. They surface per-resource: the PolicyReport detail view (above) and the resourceContext policy rollup on a resource fetched via get_resource. (The cluster audit - /api/audit + MCP get_cluster_audit - is radar’s own static best-practice scanner and does not include PolicyReport results.) Limitations:
  • Queued work (UpdateRequest) is only shown for policies that generate or mutate existing resources, and only while it is in flight - Kyverno deletes these seconds after the work completes, so an empty section is the normal resting state rather than evidence that nothing ran.
  • Coverage counts describe the whole cluster within what the caller is authorized to read; per-rule subject lists are capped by the server and additionally follow the namespace view filter. The screen states which number it is showing, but the two are not interchangeable.
  • Radar authorizes the wgpolicyk8s.io and openreports.io report families separately at each subject scope. A grant to read policyreports does not imply clusterpolicyreports, while a namespace-restricted caller can still see findings for namespaces they may read. Findings from an unreadable family are withheld from both lists and counts, and the number withheld is reported.