Process REX output

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.

This was discussed in my talk at config management camp 2024 in Ghent CVE scanning of Foreman hosts :: Config Management Camp 2024 Ghent :: pretalx . I will link the presentation later on for more details. Thanks for this idea and the feedback!

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.

As it is a REX job, it would be possible to output the trivy / grype report as plain JSON and process this output later on. Print the output in JSON is supported by both scanner tools. One idea would be, to extend https://github.com/theforeman/foreman_remote_execution/blob/45c063973f1490ff02dcac0705af5fcd3a41f489/app/lib/actions/remote_execution/run_host_job.rb#L74 so that a given method for interested plugins are called to process the REX output. I think, this would be pretty helpful for other use cases, too.

What are your thoughts? Additionally, it would be nice for some ideas how to implement this in the @remote_execution plugin.

2 Likes

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.

1 Like

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.

[1] - https://github.com/theforeman/foreman_leapp/blob/master/app/lib/actions/preupgrade_job.rb
[2] - Feat: OutputTemplates by avitova · Pull Request #813 · theforeman/foreman_remote_execution · GitHub

1 Like

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.

If it is really REX job and its output only then it will already be on Smart Proxy, then of course no additional one is needed.

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.

Thinking out loud: could you enhance REX to provide such a path and pull it back at the end of a run, providing some internal API to process that output. Or is there some other pipe? This suggests you can only forward sockets: SSH: Provide additional "pipe" fds in addition to stdin, stdout, stderr - Unix & Linux Stack Exchange

Thank you very much @aruzicka for the link to foreman_leapp. It was very helpful.

I have created a plugin to run the cve scanner. Very early stage can be seen at: https://github.com/ATIX-AG/foreman_cve_scanner

3 Likes