-
Notifications
You must be signed in to change notification settings - Fork 176
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
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
Comments
stone-z
added
the
kind/feature
Categorizes issue or PR as related to a new feature.
label
Apr 11, 2024
@stone-z replacing out standard report with |
This issue is stale because it has been labeled with inactivity. |
github-actions
bot
added
the
lifecycle/stale
Denotes an issue or PR has remained open with no activity and will be auto-closed.
label
Jun 14, 2024
chen-keinan
removed
the
lifecycle/stale
Denotes an issue or PR has remained open with no activity and will be auto-closed.
label
Jun 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: