Auditd rules
Every Syself Linux node records privileged activity with a fixed auditd ruleset. The ruleset is baked into the sealed, read-only node image, and it is loaded as immutable on every boot. You cannot edit it, and neither can anyone with a shell on the node: it is part of the image, not a file you manage. That is the point. An audit trail an operator could quietly turn off is not evidence.
The trail records who did what on the node: logins, privileged commands, changes to accounts and access, and kernel-level actions. It is scoped to the activity a person can take, not to the routine work of the platform's own daemons.
What the audit trail supports#
The ruleset is built to produce accountability evidence: a tamper-resistant record of privileged actions on the node. That maps to the logging controls in the main security frameworks, so the trail gives you evidence you can use toward your own obligations.
| Framework | The control it maps to | How this helps |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.15 Logging | Node-level event logging. Syself's information security management system is undergoing ISO/IEC 27001:2022 certification (in progress). |
| BSI C5:2020 | Operations: logging and monitoring | Hetzner holds a BSI C5 Type 2 attestation for the underlying infrastructure; the node audit trail adds the OS-layer logging evidence in the shared-responsibility split. |
| DORA RTS (EU) 2024/1774 | Art. 12 Logging | Immutable logging of privileged and access-control events, for financial-services customers. |
| NIS2 IR (EU) 2024/2690 | ยง3.2 Monitoring and logging | Tamper-protected event logs, for customers in critical sectors. |
| NIST CSF 2.0 | PR.PS-04 | Log records generated and available for monitoring. |
Note
These are alignments, not certifications. The audit trail supports evidence toward the controls above; it does not by itself make a cluster compliant. You own the wider compliance story for your workloads.
What it records#
The ruleset watches the actions that matter for accountability and integrity. It records these categories:
| Category | What it covers |
|---|---|
| Audit-subsystem tampering | Changes to the audit configuration, and deletion of audit log files |
| Identity and authentication | Changes to user accounts, group membership, and the authentication configuration |
| Privilege configuration | Changes to sudo rules and SSH access configuration |
| Cluster and runtime config | Changes to the Kubernetes and container-runtime configuration on the node |
| Commands in a login session | Every command run in an interactive login, including emergency ("break-glass") root logins |
| Privilege escalation | Commands that run as root from a non-root user |
| Kernel modules | Loading and unloading of kernel modules |
| System time changes | Changes to the system clock |
| Process debugging and mounts | Attaching a debugger to another process, and mounting filesystems, from a login session |
Rules aimed at human activity match only sessions that belong to a logged-in user, so the platform's own background daemons do not fill the log with noise. The record stays focused on people, break-glass sessions included.
Note
This page names the categories, not the exact rule lines. The audit configuration is public, and publishing the full ruleset would hand an attacker a precise map of what is and is not watched. The categories tell you what the trail covers without giving that away.
It is immutable#
The ruleset stays fixed for two reasons:
- The image is sealed. The ruleset lives on the read-only root filesystem, which is verified block by block at every boot. A changed byte fails verification and the node stops.
- The loaded rules are locked. After the rules load, auditing is set immutable for the rest of the boot. Nothing, not even root, can add, remove, or flush a rule until the node reboots, and a reboot reloads the same sealed ruleset.
Session attribution is pinned the same way: once a login session has an identity, that identity cannot be rewritten to escape the rules.
Where the log goes#
The audit log is written to the node's writable data partition, root-owned and not world-readable. It rotates by size and keeps a small local history, so a busy node cannot fill its disk with audit records. If the disk runs low, auditing suspends rather than taking the node down.
The local history is deliberately short. The node keeps enough for immediate investigation; long-term retention lives off-node.
Shipping logs off-node#
Logs stay on the node by default. To keep them, run a log shipper in your cluster that reads the audit log from each node, for example with a DaemonSet. See collect logs for patterns. For audit evidence that must be tamper-proof, ship the records to object storage with WORM (write-once, read-many) retention. See retrieve audit logs .
Early boot#
There is a short window at boot, before auditd loads the rules, where syscall auditing is not yet running. Nothing here is yours to configure, and nothing needs to be: that window is covered by integrity, not by logging. The read-only root is cryptographically verified and only signed kernel modules load, so every binary that runs before auditd is proven to be the unmodified image. Syscall auditing then turns on at steady state, where the real attack surface is, and covers the entire running life of the node.
How to check that auditd is running#
From a node shell:
$ systemctl is-active auditd
$ systemctl is-active audit-rules
auditd state is not a node health condition and not a node annotation, so you cannot read it with kubectl. A log-collector bundle captures it on the node.
Related#
Server types and sizing
Which Hetzner server types work with Syself Autopilot, how to choose the right size for control planes and workers, and sizing guidance for common workloads.
Metrics reference
The Prometheus metrics Syself Autopilot node components expose, the port each one binds, and what it tells you. Health-daemon metrics, loopback component endpoints, and how to scrape a host-network node.