As @evgeni and @ekohl suggested, I rewrote the code to collect and store the results of the CVE scans from trivy/grype and instead of using facts they would now be stored as a ConfigReport.
Summary:
Run a REX job to scan a specific direcory on a target host, the full / directory or a docker image with trivy / grype and collect affected CVEs. Previously the REX job wrote rhsm facts which were then be uploaded by sub-man.
Instead of writing facts, the idea is now to store them as ConfigReport. For this, I have created a plugin which have the ReportScanner and also would ship the REX job. (not yet available)
One major section is still missing - how to upload the ConfigReport to foreman. I would prefer a solution directory on foreman and not using a smart-proxy-plugin or directly on the host - especially because of certs / credentials to upload the report.
I wouldn’t go to Foreman directly, but always through a Smart Proxy. That’s what OpenSCAP does. It uses client certificates to authenticate. Here is how those endpoints are authenticated:
And the Smart Proxy already allows only certificates signed by a certain CA.
We have a similar pattern in the foreman_leapp plugin[1], where the plugin kicks off a job which writes json to stdout and then we parse the stdout once the job finishes. It is a bit of a hack, but it seems to work reasonably well.
There’s also a PR[2] which was done as part of a bachelor’s thesis and which would be a more systematic solution, but is not 100% complete yet. This is most likely more in line with what you had in mind.
I am also recommending always the Smart Proxy instead of Foreman directly as it will allow the usage of such a plugin in a dedicated, high security zone where not every host can reach the central Foreman server.
Well, if you run the REX job, and the output is processed, no smart-proxy at all is necessary. and it will work on high-secure environments, too as the process is done directly on foreman after the REX job was executed - maybe executed on a high-secure smart-proxy but the output can still be parsed on foreman itself.
If we would have a smart proxy for “just” this use-case, one more plugin; one more installer addition; …
Therefore, it would be really cool to have a feature in REX which can automatically process the output of a REX job. The REX job can be scheduled, too and executed on all smart-proxies. So, a lot of new use-cases would be possible.
For now, I think I will try the solution from @aruzicka - thanks a lot.
In high secure environments Foreman can’t reach hosts behind a Smart Proxy. It’s a core design philosophy behind Foreman.
I think what @aruzicka said is an interesting case. Parsing the output of processes.
Makes me wonder: can we enhance REX to retrieve a file at the end. This would be similar (but still quite different) to how GitHub Actions handles it: Workflow commands for GitHub Actions - GitHub Docs The short version is that GitHub Actions provides GITHUB_ENV as a path. When you want to set a variable, you append to that file.
