9.2 XML and REST API Automation with Palo Alto Networks Firewalls

9.2 XML and REST API Automation with Palo Alto Networks Firewalls

PAN-OS Programmability: XML API vs. REST API

Modern network security management demands programmatic automation for configuration deployment, threat intelligence updates, and operational monitoring. Palo Alto Networks PAN-OS provides robust API interfaces that allow network engineers and DevOps teams to control every aspect of firewall administration without using the web graphical user interface (GUI).

Evolution of PAN-OS API Frameworks

PAN-OS supports two primary programmatic interfaces:

1. XML API: The foundational API present since early PAN-OS releases. It uses XML payloads and relies on XPath (XML Path Language) queries to target specific configuration nodes within the PAN-OS XML configuration tree. For example, referencing a virtual system configuration requires specifying XPath expressions such as /config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']. In addition to configuration management (type=config), the XML API supports operational commands (type=op), log retrieval (type=log), user mapping updates (type=user-id), and system commits (type=commit).
2. RESTful API (JSON): Introduced to provide modern JSON-centric endpoints for software developers and automation tools. Located under /restapi/v10.0/ or /restapi/v11.0/, the REST API exposes structured URIs corresponding to configuration resources (such as /restapi/v10.0/Policies/SecurityRules or /restapi/v10.0/Objects/Addresses). Payloads are submitted as standard JSON objects, returning JSON responses with standard HTTP status codes (200 OK, 400 Bad Request, 403 Forbidden, 409 Conflict).

API Authentication & Key Generation

Before making API calls to a PAN-OS firewall or Panorama, client applications must authenticate and obtain an API Key.

Generating an API Key

An API key is requested by issuing an HTTP GET or POST request to the key generation endpoint: https://<firewall-ip>/api/?type=keygen&user=<username>&password=<password>

The firewall responds with an XML document containing the generated key token inside the <key> tag:

<response status="success">
    <result>
        <key>LUFRPT14Mk5lR0VWS3NEZzE2...</key>
    </result>
</response>

Utilizing the API Key

For REST API requests, best practice dictates passing the key in the HTTP request header: X-PAN-KEY: LUFRPT14Mk5lR0VWS3NEZzE2...

Alternatively, for XML API requests, the key can be appended as a URL query parameter (?key=LUFRPT14...). API keys inherit the permissions of the administrative user account used during keygen, respecting Role-Based Access Control (RBAC) definitions. If administrative accounts enforce Multi-Factor Authentication (MFA), API keys must be generated using dedicated service accounts configured for API access.

REST API Endpoints & Operational Commands

Configuration Management via REST API

The REST API organizes firewall configurations into logical resources:

• Address Objects: GET /restapi/v10.0/Objects/Addresses?location=vsys&vsys=vsys1
• Creating a Security Rule: POST /restapi/v10.0/Policies/SecurityRules?location=vsys&vsys=vsys1&name=Allow-Web Payload (JSON):

  {
    "entry": {
      "@name": "Allow-Web",
      "from": {"member": ["trust"]},
      "to": {"member": ["untrust"]},
      "source": {"member": ["any"]},
      "destination": {"member": ["any"]},
      "application": {"member": ["web-browsing", "ssl"]},
      "service": {"member": ["application-default"]},
      "action": "allow"
    }
  }
  

Executing Operational Commands (/api/?type=op)

While the REST API handles standard configuration objects, operational status checks and system commands (e.g., checking interface statistics, clearing sessions, committing candidate configuration) often leverage the operational XML API endpoint or dedicated REST operational URIs: https://<firewall-ip>/api/?type=op&cmd=<show><system><info></info></system></cmd>

Candidate Configuration & Committing Changes

All changes made via the XML or REST API update the firewall's Candidate Configuration. Changes do not take effect in the active data plane until an administrative Commit action is triggered: https://<firewall-ip>/api/?type=commit&cmd=<commit></commit>

Python Automation: pan-os-python vs. pan-python SDKs

Palo Alto Networks maintains Python SDK libraries to streamline API integration:

• pan-python: A low-level, lightweight Python wrapper around the raw XML API. It handles HTTP connections, API key storage, and SSL verification, but requires developers to construct XML strings and XPath queries manually.
• pan-os-python: An advanced, object-oriented SDK built on top of pan-python. It models PAN-OS configuration objects (firewalls, Panorama, security rules, interfaces, zones) as native Python classes organized in a hierarchical tree. Calling .create(), .apply(), or .delete() on a Python object automatically generates and executes the underlying XML/REST API calls.

from panos.firewall import Firewall
from panos.objects import AddressObject

fw = Firewall("192.168.1.1", api_username="admin", api_password="Password123!")
addr = AddressObject("DB-Server-IP", "10.0.1.50", description="Database Server")
fw.add(addr)
addr.create()  # Pushes object creation to firewall candidate config

Cortex Data Lake (CDL) API Queries

For cloud-delivered logging and threat telemetry, Palo Alto Networks provides the Cortex Data Lake API. Rather than querying individual firewall storage disks, enterprise analytics applications query CDL centrally over REST:

• OAuth2 Authentication: Clients authenticate against Palo Alto Networks Identity Provider to receive a Bearer Access Token.
• SQL Query Syntax: Queries are submitted via POST requests to /api/v1/queries using SQL-like syntax (e.g., SELECT * FROM panw.traffic WHERE action='drop' LIMIT 100).
• Asynchronous Execution: CDL executes the query asynchronously, returning a queryId. The client polls the status endpoint and fetches paginated result sets upon query completion.

API Comparison Matrix