Thanks for your feedback!

First, it doesn’t run as root and only allows specific needed commands that are needed on the platforms to perform upgrades (see also https://github.com/gyptazy/QualvoSec/blob/main/sudoers.d/qualvosec).

Next, the mgmt server does not have any access to the clients and only provides a static manifest (https://github.com/gyptazy/QualvoSec/blob/main/src/server/patch.yaml) holding the update schedules for the systems. In a worst case scenario, someone would be able to define another timeslot to perform upgrades on the nodes. No other code execution would be possible.

Regarding the last question:
I think this comes up to every operators own choice. Sure, you can use regular unattended updates but I think when you have a bunch of servers to manage validating and managing time windows might be more uncomfortable. Sure, you can use config management tools to push this to nodes, use them to get the configured patch windows etc. but that’s only usable for ops. Sure, you could write playbooks and abstractions layer around like Tower or Rundeck to gather the information by keeping in mind that everything gets collected by a code execution bridge.

Currently, I manage 43 personal systems a little bit more project systems with #QualvoSec benefiting from a static and centralized manifest holding the information which do not contain any sensible information. It does not allow the execution of other commands. As said before, it’s a centralized managing solution where it can easily be defined which system should be patched at which time slot. If there’s a reason for temporary stopping the patching, like a maintenance window, a special campaign where the system needs to be available, or something else this can just be placed there.

With the admin tool (and my case an abstraction layer for the parsing), customers can (re)define, temporary stop patching or define schedules from their webinterface, parsed by the admin tool which writes the manifest file. No ssh login, no cfg-mgmt run (with code executions). If a user or mgmt wants to look up schedules the same applies. Just parsing the manifest file by an abstraction layer to simply provide only the related resources.

That’s the background for creating this.