Docs / dflux EdgeGuard
ContactGet started

Auditing and compliance reporting

dflux EdgeGuard has no separate audit store. Your audit trail is the structured JSON decision log the proxy emits per request, shipped to your log pipeline or SIEM, alongside Prometheus metrics and a deny-by-default policy posture. This guide shows how to assemble those signals into a compliance story.

No audit subsystem
The proxy does not persist a signed audit trail, export to webhook or syslog sinks, or generate a compliance report. There is no audit config block, no storage.audit driver, no /admin/audit* endpoint, and no d3x-edgectl audit command. Decisions are emitted as structured JSON logs and as Prometheus metrics — those are what you build evidence from.

Structured decision logs

The proxy logs each request decision as a structured JSON line (zerolog). These lines are your record of what traffic the proxy saw and how it ruled on it. Ship them to your log pipeline or SIEM the same way you ship any container logs — there is no separate audit sink to configure.

The decision-relevant messages are:

  • proxied — a request was forwarded. Fields include request_id, target_nf_type, producer, path, status, and duration.
  • request denied — the policy filter rejected the request. Fields include the matched rule, the path, and target_nf_type.
  • rate limit exceeded — a rate-limit rule rejected the request. Fields include request_id, source_nf, target_nf, the bucket key, and the matched rule.
  • redirected — an SCP-style redirect was returned, with request_id, target_nf_type, producer, and redirect_url.

A denied request looks like this on the wire:

JSON
Set the log format for ingestion
Run the proxy with JSON log output so each decision is one parseable line. See Setting up observability for log level and format configuration, and for wiring logs into a collector.

Metrics for control evidence

Prometheus metrics give you the aggregate counts auditors usually ask for — request volume, status-code distribution, and how often each filter allowed or denied traffic — without parsing every log line.

  • edge_requests_total (labels method, target_nf_type, status_code) — request volume and outcome distribution per target NF type.
  • edge_filter_decisions_total (labels filter, decision) — allow/deny counts per filter, so you can show the policy and rate-limit filters are actively enforcing.
  • edge_request_duration_seconds (labels method, target_nf_type) — latency, for SLO evidence.

Scrape these into your long-term metrics store and you have a durable, queryable time series. See Metrics reference for the full list.

Deny-by-default posture

The strongest single control statement you can make is that the proxy fails closed. With admin.default_action: deny (the v1 default), any request that does not match an explicit allow rule is rejected and logged as request denied. Auditors can read the active policy as configuration evidence and the decision logs as evidence the configuration was enforced.

Read the active policy and rule counts straight from the admin API or CLI to capture a configuration snapshot:

Bash

For how authentication, the admin address, and the default_action default work, see Securing the admin API.

Building the compliance story

Assemble the three signals the proxy actually produces:

  • Configuration evidence — periodically snapshot the active policy, rate-limit, transformation, and routing rules via d3x-edgectl (cron + archive), along with the default_action: deny posture.
  • Enforcement evidence — retain the structured decision logs in your SIEM for your compliance window; their retention is governed by your log pipeline, not the proxy.
  • Aggregate evidence — keep the Prometheus metrics as a queryable time series of volume, outcomes, and filter decisions.

Where to go next