Docs / dflux EdgeGuard
ContactGet started

Policy engine

The policy engine decides which requests dflux EdgeGuard forwards. Rules live in the control-plane store, evaluate in priority order with first-match-wins semantics, and fall back to a configured default action. It runs on both SBI and Diameter from one rule set.

Rules

A policy rule is a named record with two essential parts:

  • Action — allow or deny.
  • Match conditions — the predicates a request must satisfy for the rule to apply. SBI conditions include path_patterns, methods, source_nf_types / target_nf_types, snssais, and subscriber matchers (supi_ranges, gpsi_patterns, dnns) extracted from the request body. Diameter conditions include diameter_apps, command_codes, origin / destination realms and hosts, imsi_ranges, and AVP matchers. The rule shape is flat — there is no nested match object.

Every match condition is optional. An empty field is a wildcard and does not constrain the request. The full field list is in the policy schema.

Rules carry a priority (an integer) that sets evaluation order: lower values evaluate first. Ties are broken by rule name in ascending order, so ordering is deterministic across restarts and replicas.

How a request matches

  1. The policy filter walks rules in priority order (lowest first, then by name).
  2. For each rule, every populated match condition is evaluated against the request. Empty conditions don't constrain.
  3. The first rule whose every populated condition matches wins. Its action becomes the decision.
  4. If no rule matches, the configured default_action applies.
The default action is deny
default_action: deny is the default (fail-closed). A fresh install with no rules denies every request. Add at least one allow rule before sending real traffic, or set the default to allow — see Securing the admin API for the trade-offs.

SBI vs Diameter matching

A rule's conditions cover both protocols. Conditions that don't apply to a request are ignored, and an optional protocols field scopes a rule to sbi or diameter explicitly. For example:

  • On an SBI request, methods, path_patterns, NF-type conditions, and the SUPI / GPSI / DNN / S-NSSAI matchers test against the URI and request body.
  • On a Diameter request, command_codes, diameter_apps, realm / host conditions, imsi_ranges, and AVP matchers cover the same role. SBI-shaped conditions stay empty.

A single rule can target one protocol or both. A rule that populates only SBI conditions will never match a Diameter request, and vice versa.

Snapshots

The live policy is read-only via d3x-edgectl policy (GetPolicy). Mutations go through the per-resource CRUD commands. For point-in-time captures, take named, immutable snapshots of the full policy and restore one later — all without restarting the proxy. There is no d3x-edgectl snapshot subcommand; the RPCs are List/Create/Get/Delete/RestorePolicySnapshot.

  • ListPolicySnapshots — list snapshots.
  • CreatePolicySnapshot — capture the current policy.
  • GetPolicySnapshot — fetch one snapshot by id.
  • RestorePolicySnapshot — restore a snapshot as the live policy.
  • DeletePolicySnapshot — delete a snapshot.

See Versioning and rolling back policy for the operator workflow.

Decision logs

Each policy decision is emitted as a structured JSON log line: the matched rule (when a rule fires), the action, the deny reason, and the request context such as path and target NF type. Ship those logs to your log pipeline or SIEM, and pair them with the Prometheus metrics for aggregate counts. See Setting up observability.