Skip to main content
Every Nyx policy carries a numeric priority. When more than one policy could apply to a connection, priority decides which is evaluated first — and within a single policy, rules are checked top-down. This page explains both, and what happens when nothing matches.

​
The four priority bands

Priorities run from 0 to 99,999, divided into four bands by convention. Each band is the home for a different kind of policy:
BandPriority rangeTypical ownerPurpose
platform-override0–99Platform / security teamNon-negotiable rules that take precedence over everything else.
namespace100–9,999Namespace ownersPolicies scoped to a single namespace’s traffic.
platform-baseline10,000–19,999Platform teamCluster-wide defaults and baselines, including the policies generated by defaultMode.
workload20,000–99,999Application teamsFine-grained, workload-specific policies.
Lower numbers are evaluated first, so the bands form a precedence order from top to bottom: a platform-override rule wins over anything below it, and a namespace policy is evaluated before a workload policy.
A policy’s priority is a single integer in the 0–99,999 range, and the admission webhook enforces these band boundaries — so precedence stays predictable as more teams add policies. The default priority is 100, in the namespace band.

​
How evaluation works

Nyx resolves a connection in two nested passes:
  1. Across policies — by priority. Every policy that could match the connection is ordered by priority, lowest number first.
  2. Within a policy — top-down. Inside each policy, rules are checked in the order they’re written. The first rule that matches decides the verdict, and evaluation stops there.
The first match across that ordered sequence wins. Nothing after it is consulted. Because the first match wins, rule order inside a policy matters: put specific allow rules above broad deny rules, or the broad deny will match first and the specific allow will never be reached.

​
When nothing matches

If no rule in any policy matches a connection, Nyx applies the cluster’s defaultMode, set in NyxClusterConfig. That backstop — allow, deny-cross-namespace, or deny — is why a freshly installed cluster with no policies still has well-defined behaviour.

​
A worked example

Suppose two policies could apply to a pod’s outbound connection to the public internet:
  • A workload policy at priority 25000 that allows egress to 0.0.0.0/0.
  • A platform-override policy at priority 50 that denies egress to the public internet.
Because 50 is lower than 25000, the override is evaluated first. Its deny rule matches, the connection is blocked, and the workload’s allow rule is never reached. This is how a platform team enforces guardrails that application teams can’t override — by placing them in the platform-override band.