Files
acdl/adapters/kyverno
Jon Chery 3d9dd06411 docs(P13): complete kyverno-kube-version-resolution phase (v1.13.16)
---ci---
project: acdl
phase: 13
milestone: v1.14
status: complete
requirements:
  covered: [REQ-147]
  partial: []
---/ci---
2026-07-29 21:07:10 +00:00
..

Kyverno Adapter

The Kyverno adapter translates Kyverno PolicyReport results to the normalized ACDL PolicyCheckResult schema (engine: "kyverno"), mirroring the Checkov/Wiz adapter pattern.

What Kyverno is

Kyverno is a Kubernetes-native policy engine. It runs as an admission controller inside a cluster, validates / mutates / generates K8s resources against declarative ClusterPolicy rules, and publishes results to PolicyReport resources.

When to use it

Kyverno is the right engine when the platform emits Kubernetes manifests (a K8s-native stack). The ACDL platform today emits Terraform only (D-053), so this adapter is ready but inactive: it ships now so the schema path, severity/result mapping and sample policies are in place ahead of the GitOps reconciler that will emit K8s manifests (roadmap).

How the adapter translates PolicyReport results

kyverno_adapter.py <policyreport.json> <contract-id> reads a JSON file containing a Kyverno PolicyReport (or just its .results[] array) and emits a list of PolicyCheckResult dicts:

Kyverno PolicyReport result field PolicyCheckResult field
policy ruleId (default KYVERNO_UNKNOWN)
severity severity (lower-cased, mapped)
result result (pass/fail/error as-is, warn/skipskipped)
message message
resource resourceRef + evidence.resource
namespace, kind, name evidence.*

The adapter is read-only against a local JSON fixture; the GitOps reconciler is responsible for fetching the live PolicyReport and writing the file. When there are zero results, the adapter returns an empty list (unlike Wiz it does not synthesize a SKIPPED record — Kyverno not running is a deployment state, not a configuration gap).

Roadmap dependency

This adapter activates when the GitOps reconciler (roadmap) emits K8s manifests. Until then it is documentation-only; the pipeline does not invoke it. The engine: "kyverno" enum value is present in schemas/policy_check_result.schema.json so future records validate.

Sample policies

The policies/ directory holds three valid Kyverno ClusterPolicy manifests (documentation-only today — the platform does not run them):

  • disallow-privileged-containers.yml — fail pods with securityContext.privileged: true.
  • require-resource-labels.yml — require acdl:owner and acdl:environment labels on all pods (mirrors the ACDL tagging standard in schemas/tagging-standard.json).
  • require-image-digests.yml — require container images to reference a digest (image@sha256:...), not a mutable tag.

Schema path

The output records validate against schemas/policy_check_result.schema.json (engine: "kyverno" was already in the enum and is retained in Phase 23).