Skip to main content
Version: 2.19

Kubeconform


Overview

The Helm backend has opt-in support for using Kubeconform as a validation tool for both Helm charts and deployments. This gives the extra confidence that the templates defined in the different charts are conformant to a Kubernetes version or specification, plus the addtional benefit of ensuring that their final version (when used in deployments) also meets that criteria.

To enable the usage of Kubeconform, first we need to activate the relevant backend in pants.toml:

pants.toml
[GLOBAL]
backend_packages = [
...
"pants.backend.experimental.helm.check.kubeconform",
...
]

This will enable the kubeconform subsystem in our workspace and enrich our helm_chart and helm_deployment with common fields that can be used to fine tune Kubeconform's behaviour in each of our targets.

Extra documentation on kubeconform

Enabling the backend will add the kubeconform subsystem in our workspace and enrich our helm_chart and helm_deployment with common fields that can be used to fine tune Kubeconform's behaviour in each of our targets. Please run pants help kubeconform as well as pants help helm_chart/pants help helm_deployment after enabling the backend to consult the different configuration settings.

Validating charts and deployments

After enabling the backend, we can run the check goal in both helm_chart and helm_deployment targets as we please:

❯ pants check ::

The check always happens in the rendered form of the Helm chart in question. In the case of helm_chart targets, the chart will be rendered as has been defined, using the default companion values.yaml (or values.yml) file defined for the chart.

For helm_deployment targets, the referenced chart will be rendered using the deployment sources and other settings like inline values, etc. This will also include all post-renderers defined for that given deployment (in case any has been defined). The effect this has is that running pants check src/helm/mydeployment requires a bit more of work under the hood than checking a standalone chart.

You can use the skip_kubeconform field in both helm_chart or helm_deployment to prevent running it against a given target in case you consider it to be a redundant check.

Skipping check on publishable charts

On a workspace that contains both helm_deployment and helm_chart targets is easy to consider that checking the charts is a redundant task as doing it so on the deployment is effectively the same. This is a safe assumption as long as you don't publish your charts to be consumed elsewhere. For that specific case we recommend also checking the standalone chart as that gives assurance that the chart package itself is sound. Regardless of that, running Kubeconform on a standalone chart is a pretty lightweight operation so unless you are facing extremelly long build times, better to not skip it.