9.3 Infrastructure as Code: Terraform and Ansible Automation for PAN-OS

9.3 Infrastructure as Code: Terraform and Ansible Automation for PAN-OS

Infrastructure as Code (IaC) for PAN-OS

Managing firewall configurations manually via the web GUI or CLI creates operational bottlenecks, configuration drift, and potential security gaps across enterprise hybrid cloud environments. Infrastructure as Code (IaC) applies software engineering best practices to network security, treating security policies, network interfaces, virtual routers, security zones, and address objects as version-controlled, auditable code artifacts.

Terraform Automation with the paloaltonetworks/panos Provider

HashiCorp Terraform is a leading declarative IaC tool that enables security engineers to provision and manage Palo Alto Networks firewalls and Panorama using HashiCorp Configuration Language (HCL).

Provider Setup and Authentication

The official Terraform provider is maintained by Palo Alto Networks (paloaltonetworks/panos). Provider configuration requires firewall hostname/IP details and API credentials:

terraform {
  required_providers {
    panos = {
      source  = "paloaltonetworks/panos"
      version = "~> 1.11.0"
    }
  }
}

provider "panos" {
  hostname = var.panos_hostname
  api_key  = var.panos_api_key
}

Declarative Resource Provisioning

Terraform resources declare the desired end state of firewall objects and security rules. Terraform compares this declared state against its terraform.tfstate tracking file and the live firewall state to generate execution plans (terraform plan):

resource "panos_address_object" "web_server" {
  name        = "Web-Server-01"
  value       = "10.0.2.100"
  description = "Production Web Server"
  comment     = "Managed via Terraform"
}

resource "panos_security_rule" "allow_web" {
  name                  = "Allow-Inbound-Web"
  source_zones          = ["untrust"]
  source_addresses      = ["any"]
  destination_zones     = ["trust"]
  destination_addresses = [panos_address_object.web_server.name]
  applications          = ["web-browsing", "ssl"]
  services              = ["application-default"]
  action                = "allow"
}

Candidate vs. Committed State in Terraform

By default, creating or modifying resources with terraform apply pushes changes to the PAN-OS Candidate Configuration. The panos provider can be configured with commit options (e.g., commit = true on provider or resource level, or using explicit panos_commit resources) to automatically execute firewall commits upon state application. Furthermore, remote state backends (such as AWS S3 with DynamoDB locking) ensure team collaboration without state collision or race conditions.

Ansible Automation with paloaltonetworks.panos

While Terraform excels at declarative infrastructure lifecycle management, Ansible provides procedural, task-driven configuration management, compliance auditing, and workflow orchestration.

The paloaltonetworks.panos Collection

Palo Alto Networks provides a dedicated Ansible collection available on Ansible Galaxy (paloaltonetworks.panos). It includes specialized modules for PAN-OS operations:

• panos_address_object: Manage address objects and groups.
• panos_security_rule: Create, update, or remove security policy rules.
• panos_commit: Execute candidate configuration commits with optional description and filter options.
• panos_type_cmd: Run raw XML API commands for custom status reporting or maintenance operations.

Example Ansible Playbook

---
- name: Automate PAN-OS Security Rule Deployment
  hosts: firewalls
  connection: local
  gather_facts: false

  tasks:
    - name: Create Database Server Address Object
      paloaltonetworks.panos.panos_address_object:
        provider: "{{ panos_provider }}"
        name: "DB-Server-Primary"
        value: "192.168.10.50"
        description: "Primary DB Host"

    - name: Ensure Database Access Rule Exists
      paloaltonetworks.panos.panos_security_rule:
        provider: "{{ panos_provider }}"
        rule_name: "Allow-App-to-DB"
        source_zone: ["trust"]
        destination_zone: ["db-zone"]
        source_ip: ["any"]
        destination_ip: ["DB-Server-Primary"]
        application: ["mysql"]
        action: "allow"
        commit: true

GitOps Deployment Pipelines for Firewall Policy

GitOps leverages Git repositories as the single source of truth for firewall security policy declarations. Any modification to security policies must follow a pull request (PR) code review and CI/CD automated validation workflow before impacting production firewalls.

GitOps Pipeline Architecture

1. Developer / Security Engineer Work: Engineer creates a new branch, adds/modifies rule definitions in YAML or HCL format, and opens a Pull Request (PR).
2. CI/CD Static Linting & Syntax Check: The CI pipeline (e.g., GitHub Actions, GitLab CI) triggers automatically to check HCL/YAML syntax, validate JSON schemas, and run static security rules.
3. Automated Dry-Run (plan / --check): CI executes terraform plan or ansible-playbook --check against a sandbox firewall to generate a diff report attached directly to the PR comments.
4. Peer Review & Security Approval Gate: Senior security architects review the proposed rule change, verifying business justification and compliance requirements.
5. Merge & Automated Deployment: Merging the PR to main triggers the CD pipeline, executing terraform apply or Ansible playbooks against Panorama / production firewalls, followed by an automated commit.
6. Post-Deployment Verification: Automated API health checks verify session tables, routing tables, and threat log flow to validate policy efficacy.

CI/CD Automated Policy Validation & Shift-Left Security

Integrating automated policy validation into CI/CD pipelines enforces governance before changes enter candidate configurations:

• Shadow Rule Detection: Automated linters analyze rule order to ensure new rules are not rendered useless by pre-existing broad catch-all rules.
• Any/Any Inspection: Pipeline scripts reject PRs containing overly permissive rules (e.g., source any, destination any, application any, action allow).
• Required Metadata: Verification scripts enforce mandatory rule fields such as owner tags, ticket reference numbers, and log forwarder profile bindings (log_setting).

Tool Comparison Matrix