CLI Policy Result Processing#

Overview#

The kubectl-kyverno apply command processes multiple policy types through distinct execution paths that all converge on a shared ResultCounts struct and a unified output pipeline. The primary entry point is applyCommandHelper in command.go.

Key files:

• cmd/cli/kubectl-kyverno/commands/apply/command.go — top-level orchestration
• cmd/cli/kubectl-kyverno/processor/policy_processor.go — per-resource policy execution
• cmd/cli/kubectl-kyverno/processor/result.go — ResultCounts and all accumulator methods
• cmd/cli/kubectl-kyverno/commands/apply/table.go — table output formatter
• cmd/cli/kubectl-kyverno/report/report.go — policy report generation

Separate Processing Paths#

Loaded policies are split into typed slices (kpols, vps, ivps, dps, cps, mps, etc.) and dispatched through independent processing functions 1:

Within ApplyPoliciesOnResource, legacy Kyverno policies are processed in a fixed order: mutate → verify images → validate → generate 2. ValidatingPolicies are additionally split by evaluation mode: EvaluationModeJSON policies are evaluated against raw JSON via celengine.RequestFromJSON, while default Kubernetes-mode policies go through the standard admission path 3. Kubernetes-mode policies are silently skipped when the input is a raw JSON payload 4.

All response slices are merged into a single []engineapi.EngineResponse before being passed to the output stage 5.

Shared Result Counting (ResultCounts)#

ResultCounts holds five integer counters: Pass, Fail, Warn, Error, Skip. Each policy type has a dedicated accumulator method with different audit-warn semantics:

• addEngineResponse (legacy Kyverno policies): only processes responses where AsKyvernoPolicy() != nil. A RuleStatusFail is downgraded to Warn if the policy is unscored (annotations.Scored returns false) or if --audit-warn is set and the failure action is Audit 6.
• addValidatingAdmissionResponse (VAPs): counts Pass/Fail/Error only — no warn downgrade 7.
• AddValidatingPolicyResponse (ValidatingPolicy, DeletingPolicy, CleanupPolicy, ImageValidatingPolicy): counts Pass/Fail/Error/Skip — no audit-warn logic 8.
• addMutateResponse: handles Kyverno, MAP, and MutatingPolicy types separately; returns a boolean indicating whether the patched resource should be printed 9.
• addGenerateResponse: handles both Kyverno and CEL-based GeneratingPolicy. For GeneratingPolicy, counts all five status types (Pass, Fail, Warn, Error, Skip). Previously, only Pass and Fail were tracked; Error, Skip, and Warn statuses were silently dropped, causing CEL evaluation errors (e.g., when test resources omit metadata.uid and a policy reads object.metadata.uid) to produce all-zero output instead of surfacing the error 10.

Important: addEngineResponses is called only for legacy Kyverno policy responses 11. VAP responses are appended after this call and counted separately via addValidatingAdmissionResponse .

Output Formatting Pipeline#

After all policies are processed, the command selects one of four output modes 13:

1. --policy-report: calls printReports → ComputePolicyReports, which groups results per policy and emits ClusterReport (cluster-scoped) or PolicyReport (namespaced) YAML/JSON objects.
2. --generate-exceptions: calls printExceptions to emit PolicyException resources for each violation.
3. --table / -t: calls printTable, which iterates all EngineResponse objects and renders a colored table row per rule result.
4. Default (violations list): iterates responses inline, printing failed rules per resource with an "audit warning" label when applicable. Error messages are printed for both mutate and generate policies 14.

In table mode, the --audit-warn flag causes RuleStatusFail results from audit-mode policies to render as warnings (color.ResultWarn()) instead of failures 15. The --detailed-results flag controls compactness of the table output 16.

ComputePolicyReportResult applies the same audit-warn downgrade at the report level: if the result is StatusFail, the policy action is Audit, and auditWarn=true, the result is changed to StatusWarn before being written into the report 17.

Exit Code Logic#

The exit function determines the process exit code from ResultCounts:

• rc.Fail > 0 → exit 1 ("policy violations")
• rc.Error > 0 → exit 1 ("policy errors")
• rc.Warn > 0 and --warn-exit-code N → exit N
• rc.Pass == 0 and --warn-no-pass → exit with warn code

Policies routed through AddValidatingPolicyResponse (ValidatingPolicy, DeletingPolicy, CleanupPolicy, ImageValidatingPolicy) do not benefit from the audit-warn Fail→Warn downgrade in result counting, so their failures always contribute to rc.Fail and will trigger exit 1 regardless of --audit-warn.