Skip to main content
Every Nyx policy runs in one of three enforcement modes. Together they let you take a policy from “what would this do?” to “this is now blocking traffic” in deliberate stages — against your real traffic, before anything breaks.

​
The three modes

dry-run evaluates the policy without entering the enforcement datapath. It reports what the policy would match as a hypothetical preview, so you can check a policy’s logic before it touches anything live. audit loads the policy into the kernel datapath, where it evaluates live traffic in real time and logs every connection it would block — but lets all of it through. This is the mode that tells you the true impact of a policy: real traffic, real findings, zero drops. enforce is the same as audit, except matching traffic is actually dropped. This is live enforcement.

​
Staging a policy safely

The three modes form a progression. Each step gives you more confidence before the next: You don’t have to use all three — but the path from audit to enforce is the one that prevents outages. Run a policy in audit, review what it would have blocked, add explicit allow rules for the legitimate traffic you find, and only flip to enforce once the audit findings are clean.

​
Where enforcement is set

Each policy carries its own enforcement field, set to dry-run, audit, or enforce. You control the mode per policy, so different policies can be at different stages at the same time — some enforcing, others still in audit. The cluster-wide NyxClusterConfig also has an enforcement field. This sets the mode for the baseline policies that Nyx generates from defaultMode — it does not override the modes on your own policies.

​
Staging a cluster-wide default deny

This is where modes and defaultMode work together. Setting defaultMode: deny-cross-namespace generates baseline policies that deny cross-namespace traffic — and NyxClusterConfig.enforcement decides whether those run in audit or enforce. So you can stage even a cluster-wide default deny:
With enforcement: audit, every cross-namespace connection that would be denied is logged, and nothing is dropped. Review those findings, add explicit allow policies for the cross-namespace traffic that’s meant to flow, and once the log is clean, change enforcement to enforce. Cross-namespace traffic is then denied unless a policy explicitly allows it — and you got there without a single surprise outage.

​
The same on Linux and Windows

All three modes behave identically whether a workload runs on a Linux node, enforced through eBPF, or a Windows node, enforced through a WFP callout driver. A policy in audit logs the same way on both; a policy in enforce drops the same way on both. A mixed Linux/Windows cluster runs one security model, not two.