Panorama

Clarity Transform reads centrally authored security policy from Panorama over its XML API, covering every scope a Panorama holds rather than the configuration installed on any one managed firewall. Read-only throughout.

Where to find it

Go to Discover → Integrations, then select the Panorama card. The card's category label is Security. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

Firewall policy is a complementary axis to observed traffic, and the pair is worth more than either alone. Firewall policy describes every conversation that is permitted to happen.

Device and manager are not the same thing, and where both exist we read both

A firewall holds the policy currently installed on it. The manager holds policy authored centrally, which may include rules not present on any one device. Reading only the device would miss centrally authored intent; reading only the manager would miss anything configured locally.

What we collect

Every policy scope a Panorama holds, not just one. That is the part worth understanding, because a rule that governs a device may be defined in any of four places.

• Each device group's pre-rulebase and post-rulebase
• The shared pre- and post-rulebase, which apply to every managed device
• The address objects, address groups and service objects each scope defines
• Inferred device-to-device relationships where both ends of a rule resolve

Objects are resolved per scope, deliberately

A device group may define an object with the same name as a shared object and different contents. Resolving objects globally would silently mix the two and produce relationships that exist in neither scope. Clarity resolves each scope against its own objects, so an override is honoured rather than averaged.

What it adds

Panorama is where intent lives. A rule authored centrally and pushed to fifty firewalls appears here once, with the device groups it applies to, rather than fifty times with no indication that they are the same rule.

App-ID applications used in a rule are resolved to their default ports by asking the appliance itself, rather than from a bundled lookup table that would drift from the installed content version.

What is deliberately not inferred

• No traffic content, packet captures or firewall logs. Configuration only.
• Nothing is written back to the appliance at any point, and the account used has no permission to do so.
• A rule is not a dependency. A rule is promoted to a CMDB relationship only where both its source and destination resolve to a device or network already discovered, and where it is specific enough to describe a dependency rather than a broad policy. An any-to-any rule is a statement about posture, so it is read and discarded.

Rule order is not evaluated

Firewall evidence means "a rule names this pair and port", not "this traffic would pass". A rule shadowed by a preceding deny still produces evidence. Deny, disabled, negated-address, negated-service and port-less rules are refused before they reach inference, so shadowing is the one case that is not detected. Treat a permitted-only finding as a lead to verify rather than a conclusion.

• Push state is not evaluated. A rule present in Panorama may not yet be committed to the devices in its group. Clarity reads authored policy, so treat a Panorama-only finding as intent rather than as installed configuration.
• Log Collector and log data are not read. Configuration only.

What we require

The requirement below is read from rb-pautol-panorama-connect.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Role required: Superreader (Panorama's own equivalent of superuser_read_only - read-everything, change-nothing). Discovery reads every policy scope Panorama holds; it never writes to it.

Connectivity: the Panorama XML API over HTTPS on TCP 443 from Clarity.

Coverage equals what the role can see. Superreader sees the whole device-group hierarchy. A custom role scoped to a subset returns the subset, and a role scoped to none returns an empty device-group list rather than a permission error - so an empty result here is a permission question rather than an empty Panorama.

Panorama calls every named login an "Administrator" regardless of privilege, the same as PAN-OS itself. A Superreader administrator cannot change a single setting: do not let that word read as "privileged" in anything derived from this file.

Verification before handover

1. Confirm the key exchange works. POST to /api/ with type=keygen and the account credential. A key in the response means authentication is working.
2. Confirm the device groups are visible. Request the device group list as this account. An empty result usually means the role is scoped to a subset, or to none, rather than to the whole Panorama.
3. Confirm both rulebases read. Request a device group's pre-rulebase and post-rulebase, and the shared ones. Superreader covers all four. A custom role frequently covers only some, and the gap presents as missing rules rather than as an error.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The Panorama management hostname or IP
Credential	The stored credential for the Superreader account
Job Schedule	A five-field cron expression, for example 0 2 * * * (daily). Central policy changes more often than a single device's
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Delete the account on the appliance. Nothing else is left behind: Clarity creates no objects and holds no session once a run ends. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
Authentication fails at the key exchange	Wrong credential, or the account is locked. The role is not involved.
No device groups returned	The role is scoped to a subset of the hierarchy, or to none of it. Superreader sees all of it.
Some rules missing	A custom role covering only one rulebase. Check pre, post and shared for the device groups in scope.
Rules read but no relationships created	Rule endpoints do not resolve to discovered devices. Run the hypervisor and operating system integrations first, then re-run.
The same rule appears from both Panorama and a firewall	Expected, and useful. The firewall holds what is installed; Panorama holds what was authored. A divergence between them is worth reading.