-
Notifications
You must be signed in to change notification settings - Fork 8
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
Feature Request: Allow configuration of scanning reports output #102
Comments
Hi, thanks for opening this feature request!
We share the same concerns about instantiating PolicyReports WRT to In fact, we have had this in mind since the audit-scanner feature inception, you can have a look at its RFC here, particularly: So that is good news :). For developing and testing, we provide the PolicyReport as JSON in the logs with Another consideration is that the log may disappear if the Pod is killed. This isn't the case for the default Cronjob as it is configured, as we have it configured to keep an amount of failed and succeeded runs. But for some users this could be a problem. Other options we have considered is providing an HTTP endpoint that serves the results, and saving the results to an in-cluster database or messaging queue instead of etcd. The idea of writing to a file on a volumeMount is new to me, and is also another possible option. Personally, it feels a bit overkill to add a volumeMount just for that, though. I wonder what @kubewarden/kubewarden-developers think. WRT to your hyphotesis on using Kubewarden, |
The more I think about writing to a provided VolumeMount, the more I think it's the simpler way for now. The user provides the VM, and in audit-scanner we can ensure we only write the PolicyReport JSON once there has been a successful run, hence the VM always contains the last known state of the audit. One needs to consider making writing to the VM file concurrent safe in case there are several audit-scanner jobs, that started at different times. It may be enough with timestamping the beginning of the file contents. |
As Victor said, we share your concerns about the performance impact of storing the policy reports into etcd. We want to offer alternatives to this approach in the next iteration of the audit-scanner. Your feedback would allow us to determine the direction to pursue. Do you already have plans about how to leverage the json output? Do you plan to rely on some centralized logging solution to handle that? |
Hallo @viccuad and @flavio ! 👋 Thank you so much for your comments, they are really insightful (and I'm glad that this is something that you already thought about)! I've been discussing this internally with one of my co-workers (tagging @brunorene for visibility), and we think that there's a way to suit our needs without much of a hassle. To summarise, we would like to use Given that the remaining Kubewarden projects are integrated with OpenTelemetry, perhaps we could leverage it to expose metrics at the namespace level, like Regarding logs, we were wondering if it would be possible to log each Also, keeping in mind that these new developments could take some time to be implemented, would you be happy for us to contribute with a PR to disable (Cluster)PolicyReport per configuration? Hope this gave you more context about our goals with Thank you! 🙌 |
Yes, indeed. The The @jvanz , just realized that the PR for the audit-scanner docs doesn't mention the new instrumentation, could you add a small paragraph there? (as the PR branch is on your personal repo)
Yes, that's definitely possible. Currently, with Click me
It has
Yes, definitely :). We already had in mind adding other stores in the future, such as an in-mem one, sqlite one, etc. Opened #107 for it. It involves adding a store interface, and a new in-mem store.
Thanks for the kind words! ❤️ |
Sure! |
|
Is your feature request related to a problem?
Hallo! 👋
I'm currently analysing the hypothesis of using the Kubewarden stack as the policy manager for a multi-tenant cluster, and I'm struggling a bit with
audit-scanner
as it requires by default the instances of a (Cluster)PolicyReport forPolicyReportStore
. From our experience with Gatekeeper, working with clusters with hundreds of namespaces, all these CRD instances led to increased pressure onapiserver
andetcd
nodes, which if possible would be something we would want to avoid.Solution you'd like
As a result, I would like to understand if it would be possible to add a configuration that would define where would
audit-scanner
output/write a scanning report. To keep compatibility, it could keep writing to a (Cluster)PolicyReport by default. It could also output as JSON to the stdout (just like the--print
flag that you currently have) or even write to a file on a volumeMount.Alternatives you've considered
Looking at
audit-scanner
source-code, I couldn't find any alternative without changing its source code.Anything else?
Please let me know if this makes sense and if it's aligned with the vision that you have for
audit-scanner
. I can also happily contribute with a PR, if this is something that you can't fit in your roadmap in the foreseeable future.Thank you so much for all the hard work that you've put into this project! 🙌
The text was updated successfully, but these errors were encountered: