[Feature] Support Direct Scanning of Helm Charts for Kyverno Policy Violations #12748
Open
2 tasks done
Assignees
Labels
enhancement
New feature or request
helm
Issues dealing with the Helm chart
triage
Default label assigned to all new issues indicating label curation is needed to fully organize.
type:cli
cli releated issue
Comments
|
/assign |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem Statement
Many Kubernetes applications are packaged as Helm charts, which produce those manifests only after templating.
Currently, Kyverno has no built-in capability to take a Helm chart as input and scan it for policy violations. Users must manually render the chart (e.g. via helm template) to obtain the YAML, then run Kyverno’s CLI to detect any policy issues. This extra step is cumbersome and error-prone, especially in automated pipelines. In fact, the community has created external solutions (like a GitHub Action) to fill this gap by templating charts and then invoking Kyverno https://github.com/ckotzbauer/kyverno-test-action. This indicates a need for a native Kyverno feature that can directly process Helm charts.
Solution Description
Proposal
Introduce a new capability in the Kyverno project to scan Helm charts directly for policy violations. There are a couple of ways this could be implemented:
Extend the Kyverno CLI: Add support for a flag or subcommand (for example,
kyverno apply --chart <chart_path> --values <values_file>) that accepts a Helm chart directory or packaged chart. The CLI would internally utilize the Helm SDK to render the templates with the given values, producing the Kubernetes manifests, then immediately apply the Kyverno policies to those manifests in-memory. This avoids requiring users to invokehelm templatethemselves. The output would be the same as scanning the rendered YAML – listing any policy violations or successes – but all in one step.Helm Plugin Approach: Alternatively, provide a Helm plugin (e.g.
helm kyverno) that hooks into the Helm CLI. This plugin could internally call Kyverno’s logic to validate a chart. For instance, a user could runhelm kyverno lint <chart>to get Kyverno policy feedback. This approach would integrate naturally for Helm users, similar to how tools like Datree have a Helm plugin for chart validation datreeio. Under the hood, it might invoke the Kyverno CLI or library with the rendered output.Kyverno Git Repository Bot: Kyverno Scans git repository and comes up with a pr with suggested changes on helm charts depending on the defined policies.
Alternatives
https://github.com/ckotzbauer/kyverno-test-action
https://polaris.docs.fairwinds.com/infrastructure-as-code/#audit-helm-charts
Additional Context
Helm Chart Pre-Deployment Policy Checks: Organizations often want to ensure that a Helm chart release will comply with all Kyverno policies before the chart is deployed to a cluster.
For example, in a GitOps or CI/CD pipeline, a developer might update a Helm chart for an application. Instead of waiting until deployment (where Kyverno would reject or report a violation on the live cluster), the team wants to scan the Helm chart as part of the pipeline, catching policy violations early.
Today, achieving this involves scripting manual steps: e.g., running helm template mychart | kyverno apply -f - for each chart.
This manual rendering is time-consuming to maintain across many services and prone to inconsistencies (wrong values, Helm version differences, etc.). A direct chart-scanning feature would let users simply provide the chart (and values) to Kyverno and get an immediate report of any violations, without the manual templating step.
Consider a GitOps workflow: a repository contains Helm charts or references to charts for deployment. Before Argo CD or Flux applies these charts, a CI job could run Kyverno to validate the charts against the organization’s policies. This would ensure that only conformant charts are merged and deployed. It’s much more efficient than discovering issues after deployment or requiring developers to run ad-hoc commands. In summary, the use case is “scan my Helm chart for Kyverno policy compliance prior to deployment”, enabling policy-as-code validation at the same phase where Helm charts are reviewed and tested.
Slack discussion
No response
Research
The text was updated successfully, but these errors were encountered: