Icingaweb and auditing

Hello guys,
I have a question in regards to the situation that happened in our company. We are going though audit for new certification and the Icinga came up.
The main topics from our discussion was, that the changes in icingaweb should be somehow logged in regards to beeing able to pair the change in web with the change request.

What I found, was that there exists separate module for this, but unfortunately it does not seem to be doing what we need. The only thing that it logs is, who logged in and who logged out and when, what we would need, at least, is to be able to see, if the definition of Roles for authentication changed.

Did any of you ever came to needing something simmilar ? or would we need to create something custom for this purpose ?

Any ideas or suggestions would be appreciated.

Filip

Hi,

what type of changes would you need being logged? Is it about the Icinga Director with configuration deployments, or are other modules affected by this?

The audit module provides hooks which may need to be implemented by other modules then. The audit module subscribes to those hooks and may log/stream them to a file.

Here’s an example for the REST API command transport, how it is implemented: https://github.com/Icinga/icingaweb2/blob/27c6c06f75d466c43c16fc19410f71f22f9819d8/modules/monitoring/library/Monitoring/Command/Transport/ApiCommandTransport.php#L203

Depending on the changes you’d need, consider preparing patches for upstream (or discussing this in a feature request on GitHub once you’ve got them working).

Cheers,
Michael

E.g. changing roles. Isn’t it possible to just check the roles.ini in /etc/icingaweb2/ ? As far as I know, the role permissions are stored there. You could also use sth. like Elastic + Auditbeat.

Hello,
Thank you very much for your suggestions. The hooks approach is probably going to be much more robust, but I will need to look into that, but basically, we use config files approach with ansible and puppet so we dont use director. From this point there is thankfully not so many things that would need to be audited, mainly the configuration changes, so authentication, application changes, modules eg.

For the approach with files, I already thought about that in regards to audit of icinga itself (icinga2 object list and diff to the rescue), but that brings another issue to the mix. There is no way to match the change in file with specific user (in case of icingaweb), but that might not be that big of a deal in this case.

Maybe etckeeper is also sth. you could like?