Enable scanning yaml that has been templated from a helm chart
sudermanjr opened this issue · 6 comments
Is your feature request related to a problem? Please describe.
If I generate my yaml and then apply it, there's no helm release object, rendering nova useless to me.
Describe the solution you'd like
If I want to maintain a repository of Yaml manifests that have been generated by a helm template command, the generated yaml will still generally have the helm annotations that say what chart it came from. Nova could detect that and do its magic after that. This could work on all in-cluster objects too, depending on what you wanted to give nova access to
Describe alternatives you've considered
This could be somewhat mitigated by #18 as well.
Additional context
Related to #45, which is working with a similar problem statement in that ArgoCD is in use. (I'm using argocd with the generated yaml manifests)
Sounds like a great idea, and one that would expand Nova usage.
FYI for the Kustomize-specific scenario in #141 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
Ideally Nova could work on the resulting yaml by using the helm annotations to get the version information and compare that to upstream as that is much faster and more efficient and gives more options for CI/CD integration.
For Kustomize I've also 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
Thinking a bit out loud here...
All my helm releases come from Jsonnet ( https://tanka.dev ) - so I guess I could theoretically craft my own helm.sh/release.v1 Secrets that Helm (and Nova) expects?
Update: Interesting, did not expect that. The helm release data in this secret contain ALOT... basically all of the manifests and some metadata. The problematic part for me is not that it's double base64 encoded, but that it's also gzipped.
After experimenting I find the gzip is optional. And only some of the data is necessary for nova find to work. This means I have a way forward with plain jsonnet.
Hi Guys,
Any update on this?
I'm working with ArgoCD + Kustomize. I'm able to run nova find --containers, but what I really need is to generate a report at the helm packages level. Since ArgoCD handles the installation on its own and the Helm Releases aren’t available via CLI, I’m unable to generate the report using nova find --helm.
Any workarounds for this?
Thanks!