Add audit logging implementation based on Alloy and go-audit

[sysvinit]

This change adds a proof-of-concept implementation of the beta platform audit feature based on Alloy and go-audit, which should eventually replaced the implementation based on auditbeat. In particular, this feature adds an additional flyingcircus.audit.useAlloy flag, which defaults to false, which when set will enable go-audit to read audit events from the kernel and enable additional Alloy configuration to read log data from go-audit and forward this to Loki.

Currently the GELF protocol is used as a lingua franca between go-audit and Alloy with a UDP port on localhost. We don't consider this suitable for production use, as a network port on localhost is not secure against interference from other processes on the same machine. This change also includes a number of patches against go-audit, to make the generated log messages easier to handle in Alloy.

PL-129625

@flyingcircusio/release-managers

Release process

• Created changelog entry using ./changelog.sh => none, proof-of-concept for a beta platform feature.

PR release workflow (internal)

• PR has internal ticket
• internal issue ID (PL-…) part of branch name
• internal issue ID mentioned in PR description text
• ticket is on Platform agile board
• ticket state set to Pull request ready
• if ticket is more urgent than within the next few days, directly contact a member of the Platform team

Design notes

• Provide a feature toggle if the change might need to be adjusted/reverted quickly depending on context. Consider whether the default should be on or off. Example: rate limiting.
  • The new auditing implementation requires setting the new flyingcircus.audit.useAlloy flag in order to enable the functionality added in this PR. By default it is not enabled.
• All customer-facing features and (NixOS) options need to be discoverable from documentation. Add or update relevant documentation such that hosted and guided customers can understand it as well.

Security implications

• Security requirements defined? (WHERE)
  • The loopback UDP port mentioned above does not protect against interference from other processes, which may be able to inject falsified log data. This change isn't intended for production use, so this is okay while we evaluate other options for our audit logs pipeline.
  • See PL-133438 as a follow-up for evaluating other options for log transport.
• Security requirements tested? (EVIDENCE)
  • Does the right thing in a test VM.