Getting started with the APIs from Palo Alto Ntwks

You can talk to firewalls and Panorama from Palo Alto Networks in various ways. The well-known GUI (which I really love, by the way) and the CLI are quite common at first glance. Nearly everyone using the Palos is familiar with these configuration options.

When it comes to automation at some point, either to configure those devices or just to read out some KPIs for your monitoring, APIs are in place. Plural because Palo has two APIs: The so-called “XML API” and the “REST API“. Let’s get started with both of them:

First things first: Why are there two APIs? What are the differences?

Fair question. I’ve no idea why PANW has two different types. It’s probably historically grown. 😂 While the old-fashioned XML API basically uses embedded CLI commands, the JSON-based REST API is orientated towards API standards but can only be used for object, policy and network configuration.

For this post, I’m using Postman v11.1.14 and a PA-440 with PAN-OS 11.2.0. The starting point for all API documentation is https://<FQDN-of-your-firewall-or-panorama>/api.

Authentication

Regardless of which API you’re using, you first have to get an API key which is used for authenticating every single API request later on. Of course, you need an admin account which is allowed to use the API, configurable through “Admin Roles”. (PANW: Enable API Access.) Please use the “POST” method (data in the body) rather than “GET” (data in URL) to avoid presenting your username & password in the web server log! [Thanks to Sven W. for the hint.] Using cURL this looks like:

While the response shows the API key:

Using Postman with some variables my “Get API Key” request looks as follows:

Copy this received API key into its own variable, e.g. {{palo-api-key}}. For the remainder, I’m using several variables within Postman. The “location” and “vsys” variables are mandatory for the REST API later on. Note the “secret” type for passwords/keys:

This API key must be sent in every single API request within the header as a key-value-pair of “X-PAN-KEY“. For Postman, you can add this Authorization of type “API Key” within your collection, leveraging the secret variable just set. That is: Every request within that collection inherits this authorization. 👍🏻

Note that your generated API key is valid indefinitely by default. You can change this behaviour (and/or “expire” all current API keys) at Device -> Setup -> Management -> Authentication Settings:

“XML API”

With the XML-based API, you can do everything which can be done through the GUI/CLI as well. (Internally, the GUI and CLI are using this XML API as well.) That is: Configuring the whole firewall (template/device group) incl. commit, but also showing everything.

Start exploring the API within your browser by accessing the following URL:

You’ll find the CLI command structure, e.g. the “show” commands within the “Operational Commands” section:

Sending a “show system info”, for example, will be this:

A “show counter global filter severity drop” will be this:

debug cli on

Another way to identify the corresponding API request to a known CLI command is the usage of  debug cli on within the CLI itself. With this, you’ll see the XML line when using CLI commands which you can use for your scripts, e.g.:

“REST API”

This API is more standardised compared to the XML API. The REST-based API can be used for CRUDding objects, policies, and network stuff. (It is not implemented to get KPIs such as routing tables, interface statistics, or hardware metrics.) Start exploring the usable objects at your NGFW/Panorama GUI again:

The input and outputs are in JSON now. (This is a good thing compared to the outdated XML API approach.) Anyway, if needed you can specify the output to be XML again.

Getting all address objects, for example, is this (GET). Note the query parameters of the “location” and “vsys”, for which I’m using Postman variables:

Tip: I’m using JSON Crack to visualise such output: (shortened screenshot)

Showing a single address, referenced by its name, is this (GET):

Adding a new address object goes like this (POST):

with a body of:

Editing (PUT) and deleting (DEL) objects are quite similar.

And finally, as always, a commit (POST) without any params:

Soli Deo Gloria.

Photo by Lenny Kuhne on Unsplash.

4 thoughts on “Getting started with the APIs from Palo Alto Ntwks

  1. Hi Johannes,

    nice article! I have one question: Where did you find the REST endpoint for the commit? (/restapi/{{palo-restapi-version}}/System/Configuration:commit)

    I searched in the swagger UI and did quite a lot of research – but never found the REST API method for doing a commit – only the ones for XML API.

    Are there even more things on the “system”-endpoint that we can do via REST API?

    Regards
    Michael

    1. Hey Michael.

      I found it under the REST API doc: https:///restapi-doc/ at the very end (System -> Configuration). Maybe they have added this with PAN-OS 11.2, since I can’t find it on a PAN-OS 11.1 firewall as well. ;) Which PAN-OS version are you using currently?

      1. Moin Johannes, vielen Dank für den Hinweis! Das ist immer wieder blöd gwesen, wenn man alles über Rest macht, aber den commit dann über xmlapi machen musste! Leider muss ich aber erstmal auf 10.2 bleiben.

        Gruß
        Christian

Leave a Reply

Your email address will not be published. Required fields are marked *