Audit trail
Every action that changes something is recorded in the control plane, in a table written in the same transaction as the change itself. A change without an audit entry, or an audit entry without a change, is not a state the database can reach.
What an entry contains
Section titled “What an entry contains”| Field | Meaning |
|---|---|
at | Timestamp |
actor_type | user, token, system or assistant |
actor_id, actor_label | Who — a person, an API token, a scheduled task, an assistant |
action | What, as a stable identifier: server.create, lb.listener.update, certificate.delete |
resource_type, resource_id, resource_name | Which resource, including its name at the time |
summary | A human-readable sentence |
before, after | Structured state where applicable |
request_id | Correlates with request logs |
The distinction between user, token and assistant is worth having: “an assistant
deleted this” and “a person deleted this” are different events with different follow-up,
and collapsing them into one actor type would lose that.
What is recorded
Section titled “What is recorded”Resource lifecycle (create, modify, delete), attachment changes (addresses, firewalls, subnets), credential events (token created or deleted, password reset, kubeconfig displayed), membership changes, and privileged access such as opening a console session.
Reads are not recorded. Listing your servers does not produce an entry.
What it is good for, and where it stops
Section titled “What it is good for, and where it stops”Good for: answering “who changed this and when”, correlating an incident with a configuration change, demonstrating that a control was applied, and — because assistants are a distinct actor type — showing exactly what an automated agent did on your behalf.
Where it stops, stated plainly:
- Retention is a database setting, not a product feature. There is no configurable retention period and no automatic archival to immutable storage. Your operator’s backup policy is your retention policy.
- It is not tamper-evident. Entries are ordinary rows. Someone with database access can alter them. There is no hash chain, no signature, no write-once store. If your requirements include tamper-evident logging, ship the entries to a system that provides it.
- Infrastructure-level actions are not in it. An operator acting directly in Proxmox does not appear here. That is Proxmox’s own log.
Getting the entries out
Section titled “Getting the entries out”Audit entries are visible in the panel and available over the API, scoped to your organisation. For long-term retention or SIEM ingestion, export them on a schedule; there is no push integration yet.