Firewall Rules
Firewall rules restrict what public keys otherwise permit. Where a key says “this key may reach these devices as these users”, a firewall rule says “and not from there, not as that, not to that one”.
Anatomy
| Field | Meaning |
|---|---|
| Status | Whether the rule is active |
| Priority | Evaluation order — rules are considered in priority order |
| Policy | Allow or deny |
| Source IP | Which client addresses the rule matches |
| Username | Which unix login the rule matches |
| Device filter | Which devices — all, a hostname pattern, or tags |
Priority, and why it is the hard part
Rules are evaluated in priority order and the first match decides. That makes the rule set order-dependent, and order-dependence is where firewall rule sets go wrong: inserting a rule at the wrong priority silently changes what the rules below it do.
Access policies are not ordered this way — deny is always evaluated before allow, regardless of what order the policies were created in. That is one of the reasons for the change.
The source IP difference
This is the one to understand before migrating.
A firewall rule can grant on source IP: “allow from this range”. An access policy’s source IP only narrows a grant that already matched — an empty list matches everything, and no source IP ever grants on its own.
So a firewall rule that grants access to a range has no direct equivalent. The replacement policy needs a real subject — a user, a role, an API key — with the addresses as a restriction on top. See Upgrading a Legacy Namespace.
Where to go next
- Public Keys — What these rules restrict.
- Upgrading a Legacy Namespace — Translating rules to policies.