Neuwerk

Policy Model

Policy is evaluated in ordered source groups and ordered rules, with different fallback rules for packets and DNS.

The policy model is built for operators who need to answer two questions quickly:

  1. which sources does this policy apply to
  2. what happens to traffic from those sources when no rule matches

The schema reference tells you which fields exist. This page explains how the Neuwerk turns those fields into behavior.

The Three Layers

A policy has three layers:

  1. a top-level policy mode
  2. one or more source groups
  3. ordered rules inside each source group

The control plane compiles that input into:

  • packet policy for dataplane decisions
  • DNS policy for hostname-based decisions

Those products share the same source-group model, but they do not use the same fallback behavior.

Top-Level Policy Mode

Every stored policy record has one of these modes:

  • disabled
  • audit
  • enforce

Behavior:

  • disabled keeps the record in storage without making it the active policy
  • enforce applies normal allow and deny behavior
  • audit evaluates the policy but converts final deny outcomes into allow

Audit mode is therefore a dry run of policy logic, not a bypass around policy evaluation.

Source Groups

Source groups bind traffic sources to policy intent. A source group can match traffic using:

  • static CIDRs
  • static IPs
  • Kubernetes-backed dynamic selectors

Source groups are evaluated in ascending priority. If no explicit priority is given, list order is used instead.

Practical rule:

  • lower numeric priority wins
  • otherwise earlier groups win

Rules

Rules are evaluated in ascending priority inside a matching source group. The first matching rule wins.

Each rule has:

  • an action of allow or deny
  • a mode of enforce or audit
  • a match block

Rule mode and policy mode do different jobs:

  • policy mode changes what happens to the final decision
  • rule mode decides whether a rule participates in enforce logic or only in audit evaluation

Packet Evaluation Order

For packet traffic, the Neuwerk evaluates policy like this:

  1. find source groups that contain the source IP
  2. walk matching source groups in priority order
  3. walk rules in each matching source group in priority order
  4. stop at the first matching rule
  5. if no rule matches, use the source group’s default_action if it has one
  6. if no source group produces a decision, use the top-level default_policy

This means default_action is stronger than default_policy once a source group has claimed the source IP.

DNS Evaluation Is Stricter

DNS policy uses the same source-group and rule ordering, but the fallback is intentionally tighter.

Once a source group claims the source IP:

  • the first matching DNS rule wins
  • if no DNS rule matches, the result is deny

If no source group contains the source IP, the result is also deny.

Operationally, that means hostname-based access requires explicit DNS allow rules. There is no implicit “allow if packet policy would have allowed it” behavior.

Match Semantics

The match block is additive. If you set multiple selectors, all of them must match together.

Current selector families include:

  • destination IPs and CIDRs
  • protocol
  • ports
  • ICMP fields
  • DNS hostname regex
  • TLS metadata
  • intercepted HTTP request and response fields

More specific rules should therefore be given higher precedence through priority, not by hoping the engine will infer specificity.

Safe Authoring Habits

  • Start with narrow source groups.
  • Put explicit deny-before-allow exceptions ahead of broad allow rules.
  • Treat hostname policy as a separate allow surface that needs explicit DNS rules.
  • Use audit workflows before broadening a new rule to large source populations.

Read Configuration Schema when you need the exact request shape.