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!
