Hi everyone,
I opened a PR on the audit plugin and would love some feedback, and ideally a review from the XO team: https://github.com/vatesfr/xen-orchestra/pull/10460
The need
We need to send XO audit records to our central syslog server, like the rest of our infrastructure logs. Today the only way I found is to poll audit.getRecords from a cron job, which:
- adds a delay (up to the polling interval),
- needs to track which records were already exported, otherwise records are duplicated or missed,
- needs a long-lived token of a real admin user stored on the machine.
What the PR does
It adds a logRecords option to the audit plugin, disabled by default. When it is enabled, each new audit record is also written to the xo-server logs as a single JSON line (namespace xo:xo-server-audit:records, level info):
xo:xo-server-audit:records INFO {"data":{...},"event":"apiCall","previousId":"...","subject":{...},"time":...,"id":"..."}
The records then follow the existing log pipeline in real time, either stdout → journald → rsyslog or the built-in [logs.transport.syslog], with no extra credentials.
- The record is logged after it has been stored, so the log line is exactly the stored record, including id and previousId.
- Nothing changes when the option is disabled, and the hash chain is not affected.
- I tested it on a from-sources install with rsyslog forwarding to a remote server.
Related: #10461 (already merged) fixed actions made from XO 5 (/v5) being recorded with 127.0.0.1 / ::1 as the user IP. With both changes, the forwarded records contain the real client IP.
Questions
- Does this approach look acceptable to the XO team, or would you prefer something else (e.g. a dedicated syslog transport in the plugin)?
- Is anyone else exporting audit logs to a SIEM/syslog, and would this fit your use case?
Thanks!