draft networking v0.2.0 Created 2026-04-21 · Updated 2026-07-24

Palo Alto Firewall GitOps Automation

Objective

Move Palo Alto firewall configuration from manual Panorama GUI changes to a GitOps workflow, so that every policy change is attributable, reviewable, and visible to the wider IT community. Specifically:

• Bring firewall configuration under the same GitOps discipline as the rest of our infrastructure — version-controlled, peer-reviewed, and automatically deployed
• Increase accountability by ensuring every change is attributable to a specific author and review cycle
• Reduce configuration errors through automated validation and peer review
• Provide the broader IT community with a readable interface into the current firewall posture — what rules exist, what traffic is allowed or blocked, and how the configuration has changed over time
• Upskill the network team on the new workflow so they can operate independently within the GitOps model

Context

Today, engineers make changes directly in Panorama's GUI. This creates audit gaps, configuration drift, and no peer review on security policy changes. Moving to a GitOps model enforces code review, versioned history, and automated deployment — aligning firewall management with the same SDLC used for the rest of our infrastructure.

Four physical Palo Alto firewalls are managed centrally through Panorama.

Tools In Use

• OpenTofu — infrastructure-as-code engine
• Jenkins — CI/CD pipeline for plan/apply workflow
• Git (GitHub) — source of truth for all firewall configuration
• Panorama — pushes committed configuration to managed firewalls

Under Evaluation

• PAN-OS OpenTofu provider — candidate for managing Panorama resources via OpenTofu
• BLAST — internal product for firewall rule management; candidate for handling standard rule changes, with complex rules falling back to custom OpenTofu
• LLM Agent — candidate for reviewing firewall policy changes against team standards, generating OpenTofu config from natural language requests, and creating or approving PRs; would be built on AWS Bedrock (likely AgentCore)
• Nautobot — network source of truth; candidate for providing authoritative IP/prefix/zone data consumed by OpenTofu and validation pipelines
• IP Fabric — network assurance / digital-twin platform; candidate for validating and testing policy changes. Builds snapshots of discovered network state and runs intent verification checks and end-to-end path simulation, which could confirm that a proposed or applied rule change produces the intended reachability rather than relying on tofu plan review alone
• Network to Code — engaged to produce a proposal covering the automation approach (they maintain Nautobot); proposal scope and recommendations are pending

Scope

Phase 1 — Configuration objects

• Address objects and address groups
• Service objects and service groups
• Panorama templates and template stacks
• Zone configuration
• Import of existing Panorama configuration into OpenTofu state
• Jenkins pipeline for plan, approve, and apply workflow
• Testing strategy for validating changes before production Panorama (e.g., lab Panorama, staging device group, canary rollout, or IP Fabric path simulation / intent verification against a post-change snapshot)
• Codified firewall policy standards document that defines acceptable rule patterns, required fields, prohibited configurations, and classification of changes as "standard" (PR approval only) vs "normal" (requires change process approval) — versioned in the same repo and used by human reviewers during PR review
• Integration with Nautobot as the source of truth for address objects, prefixes, and zone membership — conditional on adopting Nautobot (see Under Evaluation)
• CI validation step that cross-references proposed firewall objects against Nautobot inventory — conditional on the above

Phase 2 — Rule management

• Security rules and policies (managed via Panorama device groups)
• NAT rules
• Rule ordering strategy — how rule sequence is represented in code, reviewed, and kept stable across concurrent changes. PAN-OS evaluates each rulebase top-down and applies the first match, so position is semantically significant and Panorama adds shared / device-group / local layering on top
• The LLM agent items below are conditional on adopting an LLM agent (see Under Evaluation):
• LLM agent that reviews PRs for policy compliance (e.g., no overly permissive rules, descriptions required, correct zone assignments)
• LLM agent capable of generating OpenTofu firewall config from natural language change requests and opening PRs
• LLM agent can push commits (formatting fixes, missing descriptions) and approve/merge PRs that pass all checks
• Exit criterion: read-only access enforcement for human Panorama accounts (automation must be proven and team comfortable before revoking write access)

Phase 3 — Visibility

• Readable interface for the broader IT community into the current firewall posture (rules, allowed/blocked traffic, change history)
• Nautobot as a candidate platform for the visibility interface (firewall rules linked to prefixes/services, changelog linked to Git commits)
• Format TBD (dashboard, auto-generated documentation, self-service portal, etc.)

Out of scope

• Firewall OS upgrades and patching
• Panorama HA configuration
• Log forwarding and SIEM integration changes
• Network interface and routing changes (unless explicitly requested later)
• GlobalProtect VPN configuration

Risks

Risk	Likelihood	Impact	Mitigation
State import misses resources, causing drift or destructive plans	High	High	Incremental import with thorough plan review; start with non-production device group; consider a dedicated spike before finalizing MVP scope
PAN-OS provider doesn't cover all resource types we need	Medium	Medium	Audit required resource types against provider docs early; fall back to raw XML API via custom provider/scripts for gaps
Locking humans out before automation is proven causes outages	Medium	High	Phased rollout — run GitOps in parallel with GUI access before revoking write
Panorama commit/push failures leave config in partial state	Low	High	Pipeline handles commit-and-push atomically; alerting on failed pushes
Rule reordering silently changes effective policy	High	High	PAN-OS applies the first matching rule, so a positional change can open or close traffic with no diff to any rule body. Represent order explicitly in code; require tofu plan review to surface position changes; validate with test security-policy-match against representative flows before apply
Merge conflicts on shared policy rulebase	Medium	Low	Enforce linear commit history; OpenTofu state locking
LLM hallucinates valid-looking but incorrect firewall rules	Medium	High	Agent-generated changes still require tofu plan review and human approval before merge; agent cannot bypass pipeline
Agent rubber-stamps its own PRs (creates and approves)	Medium	High	Require at least one human approval on any PR the agent authored; separate author vs reviewer roles
Standards drift — agent enforces stale or incomplete rules	Low	Medium	Codify standards in a reviewable config file the agent references; version it alongside the firewall config
Nautobot inventory is incomplete or stale, causing validation false negatives	Medium	Medium	Require Nautobot data quality gate before enabling cross-referencing; define ownership for keeping prefix/site data current

Success Criteria

• All firewall policy changes originate from an automated, auditable workflow (Git PR, or BLAST if adopted)
• Human Panorama accounts are read-only
• Every change has a Jenkins pipeline run with a recorded tofu plan output before apply
• Existing Panorama configuration is fully represented in OpenTofu state with zero drift
• Rollback is achievable by reverting a Git commit and re-running the pipeline
• Network team members can submit, review, and deploy firewall changes through the automated workflow without assistance

Open Questions

• How is rule order represented and reviewed — explicit sequence numbers, list position in code, or Panorama's shared/device-group/local rule hierarchy? What stops two concurrent PRs from merging cleanly but producing the wrong effective order?
• Which Panorama device group do we start with for the pilot?
• Does the PAN-OS OpenTofu provider cover our required resource types, or do we need an alternative approach (Ansible, direct XML API, etc.)?
• What is the boundary between rules BLAST can handle vs rules that require custom OpenTofu?
• What is the current Panorama admin role structure — can we create a read-only role, or do we need to modify existing ones?
• Do we need to manage shared policy (pre-rules/post-rules) or only device-group-specific policy?
• Are there any existing automation service accounts on Panorama we can reuse?
• What is the approval gate — PR approval only, or a separate change management step?
• What is the testing strategy — lab Panorama, staging device group, canary rollout to one firewall, IP Fabric path simulation / intent verification, or tofu plan only?
• What does the Network to Code proposal recommend, and does it cover validation/testing (IP Fabric or otherwise) or only the OpenTofu/Nautobot pipeline?
• Does IP Fabric's snapshot cadence support pre-merge validation, or is it only usable as post-apply verification? (Snapshots are periodic discovery, not real-time.)
• What are the specific standards the agent should enforce? (e.g., no any source/destination, description required, max rule scope)
• Should the agent be allowed to auto-merge, or always require a human +1?
• Is Nautobot already deployed and populated with our prefix/VLAN/site data, or does that need to happen first?
• Which Nautobot objects map to which Panorama constructs (prefix → address object, VLAN → zone, etc.)?
• Does the OpenTofu pipeline pull from Nautobot at plan time (data source) or at generation time (pre-render step)?

References

• PAN-OS OpenTofu/Terraform provider — candidate engine for managing Panorama resources; resource coverage is an open question
• Panorama — Manage the Rule Hierarchy — how shared, device-group, and local rule layers are ordered and evaluated; the basis of the rule-ordering risk
• Create a Security Policy Rule — confirms first-match evaluation and that specific rules must precede general ones
• Nautobot documentation — candidate network source of truth for prefix, VLAN, and site data
• IP Fabric platform overview — snapshot-based network discovery and analytics; the basis of the validation candidate
• IP Fabric intent checks — intent verification and path diagrams used to confirm intended reachability
• IP Fabric FAQ — confirms discovery is periodic snapshots, not real-time monitoring, which constrains where it fits in the pipeline
• BLAST — internal firewall rule management product under evaluation for standard rule changes

Decisions

Date	Decision	Rationale
—	—	—

Changelog

Date	Status	Change
2026-04-21	draft	Initial draft
2026-06-08	draft	Added Nautobot integration points across phases
2026-07-24	draft	Review pass: added an objective lead sentence; marked Nautobot and LLM-agent scope items conditional on adoption rather than committed, and made the BLAST success criterion conditional; added rule-ordering scope, a High/High risk for silent policy changes from reordering, and a matching open question; added IP Fabric as a validation/testing candidate and recorded the Network to Code proposal engagement; added References; corrected created to the first changelog date