Audit Logging
Because OmniWeb is the single gateway to the network, it is also the single place where activity can be recorded. Auditing in OmniWeb has three layers that together answer "who did what, where" — across both the portal and the hosts it manages.
← Authentication & Access Control · ← Operations Guide
The Three Layers
| Layer | Captures | Where it appears |
|---|---|---|
| Portal request audit | Every action taken through OmniWeb | Settings → Audit |
| SSH login audit | Every SSH login to a managed host | Settings → Audit (via host callback) |
| Command audit | Every command run on a host (typed + executed) | Settings → Commands |
Portal Request Audit
Every request that passes through the OmniWeb proxy is recorded — regardless of whether it succeeded, failed, or was rejected by RBAC. Each entry captures:
- The user who made the request.
- The element type and instance targeted.
- The HTTP method (which tells you whether it was a view, a change, or a delete).
- The result (status code).
- The timestamp.
This gives a complete record of who changed what, where, and when, inside the portal. It lives under Settings → Audit. Because reads (GET), writes (POST/PUT/PATCH), and deletes are all distinguishable by method, the audit log doubles as a change history for the network.
The Audit Trail (Settings → Audit) — every action with the user, event type, element/instance, HTTP method, result, and source IP. Note the denied DELETE (403), the permission_changed, and the ssh_login events alongside ordinary API requests. Filter by event type, user, element, or date range.
SSH Login Audit
Hosts can report SSH logins back to OmniWeb so that host access shows up in the same audit view as portal activity. A small PAM hook on each host calls OmniWeb when a session opens, reporting the username, source IP, and service detail.
The callback is authenticated with a shared secret so only trusted hosts can write audit entries:
| Variable | Default | Description |
|---|---|---|
AUDIT_API_KEY | omniweb-audit-key | Shared secret the host PAM hook presents (as X-Audit-Key) when reporting a login. Change this — and set the matching value on each host. |
With this in place, every SSH login to a managed host appears under Settings → Audit alongside portal actions, tying together a person's portal and host activity.
Command Audit
For command-level visibility on the hosts, OmniWeb collects two complementary streams, both shipped to Loki and browsable under Settings → Commands with a source toggle:
| Source | Captures | Loki stream |
|---|---|---|
| Typed commands | The exact command lines a user types in an interactive shell — including shell built-ins like echo, cd, export | job="cmdaudit" |
| Binary executions | Every binary that actually ran on the host (scripts, tools, automation) | job="auditd" |
Neither replaces the other: built-ins never run a separate binary, so only the typed-commands stream sees them; and automation/scripts that never sit at an interactive prompt only appear in the binary-execution stream. Together they cover what a person typed and what actually executed.
Typed commands are captured by a lightweight interactive-shell hook that records each command a user runs (with user, working directory, and TTY) — the layer that catches built-ins a binary tracer structurally cannot see.
Binary executions come from a lightweight host agent that records every binary run on the host. Because it works in userspace it functions inside LXC containers without kernel audit support. Each entry captures:
| Field | Meaning |
|---|---|
login | The user who originally logged in — survives sudo/su, so privilege changes don't hide who is acting |
uid | Effective UID the command actually ran as |
filename | The binary that was executed |
cwd | Working directory at the time of execution |
(after ]:) | The full command line |
A representative execution entry:
2026-04-16T13:18:35 omni-stp01 [login:nickj uid:0 tty:(none) cwd:/home/nickj filename:/usr/bin/sudo]: sudo tail -10 /var/log/auth
The Settings → Commands view defaults to the typed-command stream and lets you filter by host, search by user or command, and live-tail activity across the fleet — with the source toggle to switch to the raw binary-execution view when you want to see exactly what ran.
Note: the command streams are an operator-visibility aid captured in userspace. A determined root user can bypass them; kernel-level auditing is the hardening step if you need non-bypassable capture. For the security-relevant, structured record (logins, permission changes, denials), rely on the Portal and SSH login audit above, which are written to OmniWeb's own database.
How the Layers Fit Together
- A configuration change made through OmniWeb → portal request audit.
- A change made by hand on a host → SSH login audit (who got in) + command audit (what they did).
Together they leave no blind spot between "changed it in the UI" and "changed it on the box".
Related
- Logs & Subscriber Tracing — the general log explorer behind the command streams.
- SSH Key Login — the access side of host activity.
- RBAC — the permissions whose use the portal audit records.