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

[maltemorgenstern]

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]

@maltemorgenstern sound interesting use case, today we already has metric separation for teams by resource label maybe it will be more flexible to support ignorefile by resource label, wdyt ?

[maltemorgenstern]

Hey @chen-keinan, that is an interesting suggestion - but how would that work (where/how would you configure those label matchers)?

I think the crucial part is how to enable teams to deploy their own ignorefile (as a ConfigMap). Looking at an example setup they would create an additional resource which is being synced into the cluster via GitOps.

After that the operator would need to do two things:

• Collect the ConfigMap (and its contents) in all namespaces it is scanning (where only some might have it)
• Use the ignorelist for all scanJobs running for resources in that namespace (which could be easier with vulnerabilityReports.scanJobsInSameNamespace enabled - but not sure if that should be a requirement)

Maybe the first part could be replaced by an additional deployment/services/... that reads all those ConfigMaps and creates a new one with all contents combined - but honestly I think that would just lead to more issues down the road (untracked resources, ConfigMap size limits, ...).

[chen-keinan]

@maltemorgenstern please convert this discussion to issue and we can discuss implementation there, wdyt?

[maltemorgenstern]

Done - see #1857