Namespace scoped Trivyignore file

[glimpsec]

Issue #541 added the possibility to configure a Trivyignore file for CVE's we don't want to appear in the scan results.

Our clusters are used by multiple teams. Each team maintains its own images and pods, and currently has its own Trivy ignorelist in a Harbor registry. Allowing namespaces to define their own trivyignore file (in for example a configmap) would allow them to do the same for their Starboard scans. Assuming a single Starboard operator in the cluster, it's not possible for us to maintain a single cluster-scoped trivyignore file. The reasons to ignore a specific CVE are usually team- (and in our case namespace-) specific.

For our case, it would not matter if a namespace scoped trivyignore file either overwrote of unioned with the trivyignore file from the operator configmap.

We're excited about Starboard. This feature would make the operator more fitting for use in multitenant clusters.

[danielpacak]

👋 @glimpsec In the current architecture Starboard is agnostic to Trivy. It just happens that Trivy is the default vulnerability scanner and we provide in tree plugin for it. That's also the main reason why there's only a global config for Trivy across all namespaces because plugins' config is global by design.

Reading Trivy-specific ConfigMap from the workload's namespace directly will break the boundaries between core Starboard and its plugins system. However, I do agree that global config to managed CVEs may not be flexible in multitenant clusters where you deploy a single instance of Starboard Operator to watch all namespaces. What's more it's not something specific to Trivy.

That's said we could design (generic) ConfigMap or a CRD to ignore certain vulnerabilities. Such object would be discovered by Starboard and passed to a vulnerabilityreport.Plugin, and the plugin implementation would map it to trivyignore file or any other proprietary input format.

I can also imagine cases where users would specify global ignore policy or narrow it down to a particular container registry or repository or even certain tag or digest. Since not every scanner provides such functionality we may also consider expressive policy languages such as OPA / Rego evaluated with VulnerabilityReport as an input. Such VulnerabilityReport would contain all vulnerabilities returned by the scanner, but we could filter them out with some policies and store results, for example, in a ConfigAuditReport owned by the VulnerabilityReport.

Anyway these are just ideas. The best would be to start with use cases describing end to end vulnerability management workflow like you did for multi-tenant clusters. In particular define the input format for ConfigMap (or CRD) to cover most commons scenarios including roles and actors who configure and consume security reports. Would it be something you could contribute to @glimpsec ?