Build a simple policy and push it live

With an engine online, the next step is a policy for it to enforce. CCX policies are composed in the console — no YAML editing required. The policy is structured into three sections matching where the engine sits in the packet path: to-firewall (management), through-firewall (the normal forwarding case), from-firewall (anything the firewall VM itself originates).

Note

Nothing reaches a firewall until you explicitly Push. Saving a draft is safe; the engine doesn’t see it until publish runs and the engine pulls.

Policies — every policy in the tenant, with status and version.

1. Create the policy shell

1. Sidebar → Policies → New policy.
2. Name it fleet-default (or whatever you’ll bind broadly). Description optional.
3. Default action: drop. The fail-closed posture — if no rule matches, the packet drops.
4. Create.

2. Allow the engine to reach its dependencies

Add a few rules to the from-firewall section so the engine itself can talk out — DNS, NTP, package updates. Without these the engine still runs (everything it needs to reach the Enforza cloud bypasses policy by design), but operating-system services on the VM start failing.

1. Open the from-firewall section.
2. Add rule:
   • Comment: dns
   • Destination: any
   • Protocol: udp / tcp
   • Port: 53
   • Action: Accept
3. Add another for NTP (UDP 123) and another for HTTPS egress (TCP 443).

Policy editor — three sections, drag-to-reorder rules, first-match wins.

3. Add a couple of through-firewall rules

These are the rules that actually inspect customer traffic. Start permissive while you confirm the policy works, then tighten.

1. Open the through-firewall section.
2. Add rule — allow generic web egress:
   • Comment: web egress
   • Source: any (or your protected subnet’s CIDR)
   • Destination: any
   • Protocol: tcp, port 443
   • Action: Accept
3. Add rule — block SSH from anywhere:
   • Comment: block inbound ssh
   • Source: any
   • Destination: any
   • Protocol: tcp, port 22
   • Action: Drop, with Log ticked so you can see attempts in live logs.
4. Save.

Note

Rules are first-match wins within a section. Reorder by dragging the row handle on the left of each rule.

4. (Optional) Attach a guardrail set

On the policy’s Compliance tab you can attach one or more guardrail sets in advise (warn) or enforce (block-publish) mode. Skip this for the first push if you don’t have a set yet — you can add it later.

5. Push the policy

1. From the policy editor, click Push.
2. The publish dialog runs two preflight checks:
   • Firewall Policy Schema — validates the rendered policy against the engine’s schema.
   • Guardrails — runs your attached compliance sets. Enforce violations block here.
3. The dialog shows your bound firewalls (none yet — that’s the next step) and the rendered policy in a collapsed accordion.
4. Click Confirm push. The policy ring buffer keeps the last 20 versions; you can roll back any time.

What just happened

• Your structured policy was rendered to the engine’s canonical form.
• The schema validator + guardrails ran in the cloud — engines never see invalid policy.
• A new version row landed in the policy’s history (visible on the policy’s Versions tab).
• Bound engines (you have none yet — that’s next) would have started fetching the new version within seconds.

Next: Bind a policy to a firewall.