-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native PolicyReport support #2003
Comments
@stone-z replacing out standard report with |
This issue is stale because it has been labeled with inactivity. |
@chen-keinan If it is simply replacing the custom struct with a new one from kubernetes, I can help do some of the grunt work. I am unsure if you want to handle migration as well. TTL should make sure everything is rescanned eventually. |
This issue is stale because it has been labeled with inactivity. |
Storing reports as Kubernetes objects makes them very easy for users and other tools to consume. The current report structure is very useful for working with Trivy Operator data, and I'm wondering if it could even be enhanced in order to re-use other tools in the ecosystem.
PolicyReports are a type proposed by the Kubernetes Policy Working Group, which seeks to standardize the experience of working with policy management in Kubernetes clusters.
Currently, Trivy Operator report types can be converted into PolicyReports using the Trivy Operator PolicyReport Adapter. This makes it possible to access Trivy data via the common format, and use additional tooling like Policy Reporter to work with the data.
However, the adapter works by copying the data from the original report (e.g. a VulnerabilityReport) into a PolicyReport. This duplicates the data and the etcd space needed to store it.
If Trivy Operator were to natively support PolicyReports as an output, it would be a big improvement.
Additionally, it would enable storing reports outside of etcd. We've written a more in-depth discussion of the limitations of etcd storage for reports in large clusters, but in short, the volume of data cycling through the API server becomes too large, and even individual reports can become quite large, and exceed the maximum size tolerated by etcd (#442, #441).
To address those limitations, PolicyReports can now optionally be stored in an external database using an extension API server. If Trivy Operator were to support PolicyReports natively, it could also get the performance benefits of using the same external storage.
As a side note, if PolicyReport support isn't feasible, please consider this a feature request for a similar external storage mechanism like the one linked above, to address the problem of report volume in large clusters.
The text was updated successfully, but these errors were encountered: