Kustomize Helm support - detect outdated helmCharts in kustomization.yaml

[HariSekhon]

Problem Statement

When installing Helm charts via Kustomize, because Kustomize renders the helm template to apply instead of running a helm install, Nova does not address the use case of outdated Helm charts in Kustomize configurations.

Use Case Example

My public kubernetes repo with lots of *-kustomization.yaml files with Helm charts embedded in them:

https://github.com/HariSekhon/Kubernetes-configs

Proposed Solution

Nova could scan kustomization.y*ml files for the helmCharts section and extract the chart repo/name to check for outdated versions.

This shouldn't be difficult to do, and is much cleaner than the alternatives.

Alternatives considered

1. Parsing the kustomization.yaml myself, installing the Helm charts the old fashioned non-GitOps way using the helm command against a CI/CD K8s cluster and then running Nova against the CI/CD cluster. Obviously this is far from ideal, compared to Nova just comparing the versions in the yaml to the upstream repo.

2. Installing all the Kustomizations to a CI/CD cluster and then hoping #62 is implemented to be able to scan from annotations, but that is not yet implemented either.

My proposed solution for Kustomize is simpler, faster and more lightweight than either option above.

Additional context

Relates to #62 and #45

[sudermanjr]

I agree, we definitely have a gap where helm-templated and gitops solutions are excluded from Nova.

The proposed solution here could work, but how do you propose to do in-cluster scanning? The proposed solution in #62 would cover both in-cluster and out-of-cluster, and would cover almost all use-cases, rather than specifically one tool at a time. ArgoCD and Kustomize are only 2 tools in an ever-expanding list of tools that support Helm charts but don't create actual releases.

Would love to get @rbren or @makoscafee to weigh in on this as codeowners of this project.

[HariSekhon]

I agree that the #62 solution is more universal.

From the point of view of CI/CD and Kustomize, this is a very nice to have and a lower implementation bar IMO, which is why I mention it here.

Otherwise in my GitHub Actions CI/CD I'll have to actually deploy the Kustomize to a K8s cluster and then run Nova against the live cluster to scan for new updates, which is pretty inefficient.

[HariSekhon]

I've created a CI/CD workflow that installs all kustomization.yaml apps and then runs Nova.

Right now it finds nothing because Nova must be looking for Helm release information, but once it starts scanning for applied templates via helm annotations I can use this workflow to immediately test it:

https://github.com/HariSekhon/Kubernetes-configs/runs/7971985694?check_suite_focus=true

[HariSekhon]

I would still like the file scanning level of-course though, as this is a pretty heavy and slow solution to the problem of parsing out the helm chart version from kustomization.yaml.

[HariSekhon]

FYI I created another script kustomize_install_helm_charts.sh to parse out and install the Helm chart(s) the old-fashioned non-GitOps way using Helm CLI so that Nova can be run on it right now:

https://github.com/HariSekhon/DevOps-Bash-tools

I've used this in my Kubernetes repo's GitHub Actions CI/CD workflow and this works for me as a workaround until Nova can scan the helm release annotations from the Kubernetes objects instead:

https://github.com/HariSekhon/Kubernetes-configs/actions/workflows/nova.yaml

However, Nova seems to be outputting the information in JSON instead of the nicely tabulated format on the CLI, which is presumably due to detecting running in non-interactive or CI environment.

Any idea how I can force Nova to output in tabular format?

[sudermanjr]

In theory the --format=table flag should work for that.

[HariSekhon]

Yeah that solved it, thanks.

I didn't see the flag in --help locally because I had 3.0.2 installed but once I upgraded to 3.3.0 I found it and this has solved the output in the CI workflow output.