Skip to main content

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 prunes audit_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.