Your first SBI policy

In about 15 minutes, write a policy rule, deploy it via d3x-edgectl, and verify it from a live request. By the end you'll know how a rule gets from JSON on disk to a decision on the wire.

Before you start

dflux EdgeGuard running with examples/edge-minimal.yaml. See Quickstart if you haven't done that yet.
d3x-edgectl installed and authenticated the same way as in the Quickstart (default -addr 127.0.0.1:9091; pass -key / D3X_EDGE_ADMIN_KEY if the example API key is set).

The state of play

With the minimal config and no rules, the proxy denies every request (the v1 default is fail-closed, default_action: deny). Confirm there are no rules yet:

Bash

That should print []. Now send an SBI request to the proxy port and check the response:

Bash

Expect 403. The proxy emits the deny as a structured JSON log line (zerolog) on its log stream — that's where decisions land, not in any separate store.

Write the rule

Allow read-only Nudm SDM lookups from any consumer for now. We'll tighten the matchers once we know more about your traffic. A PolicyRule is a flat JSON object: the request matchers (methods, path_patterns) sit at the top level.

JSON

Save this as allow-nudm-sdm-reads.json.

Deploy the rule

Create the rule through the admin API. The rule CRUD handler validates the body as it stores it, so a typo in a field name or an unknown action is rejected here with an error telling you what's wrong.

Bash

The proxy persists the rule to the control-plane store, bumps the policy version, rebuilds the request filter chain, and swaps it in atomically. There is no restart, no dropped connections, no warm-up.

Confirm the rule is now in place:

Bash

Exercise the rule

Repeat the request from earlier:

Bash

Expect a status other than 403 — the request now passes the policy gate. The exact response depends on whether a UDM producer is registered:

No producer: 503 with a "no route" body. Policy allowed, routing had nowhere to send it.
Producer registered, reachable: the producer's actual response.

Allowed ≠ delivered

A request can pass policy and still fail downstream (no producer, producer 5xx, timeout). The proxy's per-request log line records both facts: the policy decision (the filter chain let it through) and the final status code the consumer ultimately got. Ship those logs to your SIEM and metrics pipeline — see Setting up observability.

Versioning and rollback

Each rule mutation bumps the policy version. To capture a known-good policy you can roll back to, take a snapshot through the admin API before and after changes; restoring a snapshot reapplies that policy atomically. The operator-flow patterns (snapshot, restore, regression check) are covered in Versioning and rolling back policy.

Where to go next

A path-pattern rule that matches every consumer is fine for a smoke test but rarely the right production shape. Common refinements:

Add target_nf_types: ["UDM"] to constrain by target NF type.
Add source_nf_types to require specific consumer NF types.
Require an OAuth2 scope check via the auth filter rather than path-only matching.
Add a rate-limit rule keyed by consumer identity to cap noisy callers — see Configuring rate limiting.

See Policy schema for every available matcher field.