search

aquasecurity / trivy-operator

Kubernetes-native security toolkit
https://aquasecurity.github.io/trivy-operator/latest
Apache License 2.0
1.29k stars 213 forks source link

Load .trivyignore (or ignore-policy) from ConfigMaps in target namespaces #1857

Open maltemorgenstern opened 9 months ago

maltemorgenstern commented 9 months ago

Discussed in https://github.com/aquasecurity/trivy-operator/discussions/1847

Originally posted by **maltemorgenstern** February 8, 2024 Hey there, I started to play around with the `trivy-operator` and wanted to get your thoughts on an issue/question. ### Current situation We have a kubernets cluster managed by a platform team. It contains different shared services (logging, metrics, gitops, ...) and can be used by dev teams. They can request their own namespace - and start deploying their applications (pods). Adding the `trivy-operator` as a managed service would increase the cluster security while reducing efforts for our developers. Trivy would be managed by the platform team and automatically scan new workloads deployed by the teams - and they would not need to worry about how to scan images. The findings could be passed to each team using a grafana dashboard - and even alerting on new findings would be possible out of the box 🚀 ### The problem But - as always - there will be false-positive findings that need to be suppressed (in order to actual spot critical vulnerabilities). As far as I can tell this can be done in two ways: - Configure a `.trivyignore` file that contains CVEs - but would match all workloads in the cluster - Configure (multiple) `trivy.ignorePolicy` rego rules - that can be scoped to namespaces or even specific workloads In both scenarios the config would have to be placed in the `trivy-operator-trivy-config` ConfigMap - inside the operator namespace. This would mean that the platform team would have to maintain all ignore configs - for each team and each of their workloads, which would be a lot of work. I think it would be a great feature to allow teams to configure their own `.trivyignore` (or `trivy.ignorePolicy`) inside a ConfigMap deployed to their namespace. This way the teams could manage findings themselves and would not depend on the platform team to maintain a central config. This would require the `trivy-operator` to read multiple ConfigMaps from other namespaces and merge the configs before applying them. What are your thoughts about this? 🙂
chen-keinan commented 9 months ago

@maltemorgenstern contributions are welcome.

teimyBr commented 9 months ago

Would also be nice this Feature will help us a lot

chen-keinan commented 8 months ago

@maltemorgenstern maybe solution similar to ignore policy with ignoreFile make sense for your use-case ?

maltemorgenstern commented 8 months ago

@chen-keinan there are for sure some similarities between these two features.

Having the ability to apply different ignoreFiles (like ignorePolicies) for different namespaces/workloads is one part of this feature request.

But the other (and probably more complex) part is the ability to load the ignoreFile from somewhere else than the values.yaml - preferably from ConfigMaps in the target namespaces.

There might be some similarities to https://github.com/aquasecurity/trivy-operator/issues/1223 here - maybe a generic solution could help to solve both these issues (but that is just an idea).