Overview
When the audit evaluator is enabled (evaluator.enabled: true in
chart values), the broker forwards every observed pod-traffic flow
to the evaluator, persists the per-policy verdicts to the
audit_verdicts table, and exposes them here. The frontend’s
“Would-Deny” view consumes this endpoint.
Each verdict row captures one (flow, policy, direction) tuple. A
single flow may produce many verdicts when several
AuditNetworkPolicy / AuditClusterNetworkPolicy resources match the
subject pod.
GET /audit/verdicts
Returns the most-recent verdicts, ordered by(observed_at DESC, id DESC) — newest first, with the BIGSERIAL
primary key as a tiebreak so two pages of the same query never
reshuffle their boundary rows.
Query Parameters
All filters are optional. Apply them server-side rather than filtering the response client-side: server-side filtering uses the(policy_namespace, policy_name, observed_at DESC) and
(verdict, observed_at DESC) indexes, so narrowing by policy or
verdict is index-backed.
Example
Response
Returns an empty array
[] when no rows match — never null. Status
is always 200 on a successful query.
Retention
The broker runs a background task that prunesaudit_verdicts rows
older than AUDIT_VERDICTS_RETENTION_DAYS (default 30) every
AUDIT_VERDICTS_RETENTION_INTERVAL_SECS (default 3600). Deletion is
batched (AUDIT_VERDICTS_RETENTION_BATCH_SIZE, default 5000) to bound
the lock-hold time and WAL churn — so a one-time prune after dropping
retention from 365 days to 7 doesn’t block concurrent INSERTs.
Set AUDIT_VERDICTS_RETENTION_DAYS=0 (or
broker.audit.retention.days: 0 in chart values) to disable retention
entirely. The audit_verdicts table will grow unbounded — only useful
when you’re exporting to long-term storage out-of-band.