Network and firewall GitOps — when the tooling supports it

Network and firewall configuration is the slowest surface in the GitOps model. Kubernetes and cloud providers expose declarative APIs that a controller can watch and reconcile against; network devices often expose imperative CLI sessions, proprietary management planes, or partial APIs that do not cover the full configuration. Where the API is declarative and complete, GitOps applies with the same discipline as the rest of this part. Where it is not, the discipline is hybrid: a Git-tracked configuration file, an analysis step (Batfish or Netshot), and a manual or change-window-driven apply.

The four OpenGitOps principles still define the target state. Declarative: a YAML or HCL configuration in Git. Versioned and immutable: branch protection and signed commits. Pulled automatically: a controller or a CI job. Continuously reconciled: a controller loops against the device API and re-applies on drift. The constraint is the device API.

flowchart LR
    A["Git: policy YAML"] --> B["Controller / CI"]
    B -->|"render"| C["Vendor API"]
    C -->|"apply"| D["Firewall / load balancer"]
    D -->|"observed"| C
    C -->|"diff"| B
    B -->|"alert on drift"| E["Operator"]

The diagram looks the same as for Kubernetes or Terraform. The difference is in the Vendor API box: it is the boundary between the GitOps loop and the device. Where the API is declarative and complete, the loop is closed; where it is not, the loop is broken at the vendor boundary and the discipline becomes policy-as-code plus analysis.

Policy-as-code versus device-as-code

The two halves of network GitOps are policy-as-code and device-as-code. Policy-as-code is the desired-state description: an allow-list of CIDR blocks, a list of service-to-service rules, a set of TLS profiles, a routing intent. Device-as-code is the device-specific configuration: the Cisco IOS commands that implement the routing intent on a specific router model.

Policy-as-code GitOps well. The file is declarative, lives in Git, and is rendered into device configurations by a tool that understands both the policy and the device. The render step is the diffable artefact; the apply step is the side effect.

Device-as-code GitOps less well. The file is imperative (IOS commands, Junos set commands), the diff is harder to review, and the apply is a privileged session against a device that may or may not support atomic transactions. A bad apply can take the device out of production. The discipline for device-as-code is closer to the Ansible model than the Kubernetes model.

Vendors that support the loop

Three categories of vendor support the loop well:

• Cloud-native network policy. AWS VPC security groups, Azure NSG, GCP firewall rules. These are cloud APIs in the same sense as IAM; the terraform-controller and Pulumi operator drive them through the same loop. GitOps works fully.
• Software-defined networking with declarative APIs. Cisco ACI, VMware NSX, F5 BIG-IP with AS3. These expose an API that accepts a declarative payload and applies it atomically. A controller can watch Git, render the payload, POST it, and verify the device converged. GitOps works with the same discipline as cloud-native.
• Firewalls with XML or REST APIs. Palo Alto Panorama with the XML API, Check Point with the Gaia API, Fortinet FortiOS with the JSON API. These accept declarative payloads but often require a commit step on the management plane. The loop is partial; the apply is gated by a commit that the controller can drive but the device confirms.

Three categories do not:

• Traditional routers with CLI-only configuration. The device accepts imperative sessions; the diff is hard to review; the apply is per-line. GitOps reduces to policy-as-code plus a separate change-window apply.
• Load balancers without declarative APIs. F5 BIG-IP without AS3, HAProxy without the Data Plane API. The configuration is imperative; the loop is broken at the device boundary.
• Middleboxes with vendor consoles. WAN optimisers, intrusion prevention systems, DLP gateways. These have a vendor console and a partial API; GitOps reduces to policy-as-code plus analysis.

flowchart TB
    subgraph "Full GitOps loop"
      A1[Cloud security groups]
      A2[ACI / NSX]
      A3[Palo Alto with XML API]
    end
    subgraph "Partial GitOps loop"
      B1[Policy-as-code + analysis]
      B2[Device-as-code in change window]
    end
    subgraph "No GitOps loop"
      C1[CLI-only routers]
      C2[Vendor-only consoles]
    end

The diagram partitions the network management landscape. The top row is the green field; the middle is the hybrid that most teams live in; the bottom is the legacy that the controller-driven model cannot reach.

Production discipline

1. Separate policy from device config. Policy lives in Git under strict review. Device config is rendered from policy and lives in a separate repo with looser review; the rendered output is the diffable artefact.
2. Dual-commit high-risk changes. Apply to one device in the routing domain first, observe for a defined period, then apply to the rest. The first device is the canary.
3. Treat the controller as one writer, not the only writer. A network operations team with break-glass access may apply directly during an incident. The controller treats those edits as drift and surfaces them; the recovery is a new commit that re-applies the policy.

Cross-course references

• This course, Part LXXII (GitOps Foundations) - the four principles applied to a vendor API that may not be declarative.
• Ansible for Production Sysadmins - Parts on network automation cover the device-as-code model that fills the gap when the vendor API is imperative.
• Terraform for Production Sysadmins - Parts on cloud-provider resources cover the cloud-native network policy loop (security groups, NACLs).

Quiz