EmployeePaloAlto API key generator / verifier DataSource
What:
A DataSource that takes paloalto.user and paloalto.pass credentials and uses them to generate the paloalto.apikey.pass property necessary for monitoring.
Why:
As per our PaloAlto documentation page (https://www.logicmonitor.com/support/monitoring/networking-firewalls/palo-alto-firewalls), for API monitoring you need to create an API key using user+pass credentials via an https call, the dig out a key value from the returned XML, then finally set that key in a new property on the resource in LogicMonitor.
This is OK if you have one PaloAlto, but is a bit tedious if you have more, and, recently, I was in discussion with a customer who...
...well, let's just say they have a significant number of PaloAlto resources.
However, your LogicMonitor Collector can make https calls and parse the resultant XML, and the LM API enables you to PATCH properties to Resources, which means this can be automated.
You will need:
LogicMonitor API credentials set as Resource Properties for your PaloAlto resources, for an API user with the rights to manage these Resources. These modules will accept lmaccess.id or logicmonitor.access.id for the API token ID; and lmaccess.key or logicmonitor.access.key for the token key (in those orders of preference).
The script will take the account name directly from collector settings.
You'll also need to set paloalto.user and paloalto.pass properties for your PaloAlto resources in LogicMonitor.
Then what?
In short, this DataSource will attempt to create and set the necessary API key if the resource doesn't currently have a working one.
The DataSource has this logic:
/*
Do we already have a PA API key?
- If yes test it.
- Does it give us a 200 code?
- If yes, bail out with "OK" code. Nothing else needs to be done.
Still here? That means, absent or incorrect key, we'll try to correct that.
Do we have LM API creds and PA user and pass values?
- If not, bail out with "Absent creds" code. We can't do anything even if we wanted to.
As we’re here, we’ve got the bits we need, and if there is a PA API key, it didn’t work.
Http call to the PA using user+pass.
Did we get a 200 code / valid response?
- If not, bail out with "bad PA creds" code. These clearly don’t work.
- If yes, parse the XML to extract the key. (will be done in function and passed back)
Test the new key
- Does it give us a 200 code?
- If NO, bail out with "bad PA key" code.
Still here? Call the LM API for this resource and PATCH the paloalto.api.pass property with
the discovered value.
- report response code
*/There are various diagnostic datapoints to show either successful operation, or failure reasons, which can be alerted on.
Note that, even in the absence of LM API credentials, this DataSource will still check for the presence and validity of a paloalto.apikey.pass property value.
DataSource Name: PaloAlto_KeyGen_and_Verification
v1.5 published with lmLocator: DL37ZT
