You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
#2613 added a new Palo Alto ARP plugin that fetches data from the built-in REST API on Palo Alto firewalls. This plugin gets API credentials from ipdevpoll.conf, which is not desirable in the long run. This kind of information should rather be stored in its own kind of management profile, so it can be added through the Seed Database tool and be re-used across multiple devices.
Describe the solution you'd like
It is not clear to me at this point whether "Palo Alto API" should be its own management profile type, or if it would be sufficient to have a "REST API" profile that could be re-used across multiple vendors. In reality, there are many ways to authenticate against a even a REST API, so what's required for such a profile in the long run might be more than just an "api token" string. Perhaps "REST API with static token" would be a suitable name?
Describe alternatives you've considered
The current solution is a workable alternative, but not a very good one.
Really, all that we need to store for the time being is a "static API token" - it doesn't even have to be a REST-based API. How the token is used is entirely up to implementations that utilize such a profile.
I'm working on fetching data from a Kea Control Agent's Rest API, so I'm also interested in storing Rest API configurations in a management profile. I'll have a look at this issue as well.
Is your feature request related to a problem? Please describe.
#2613 added a new Palo Alto ARP plugin that fetches data from the built-in REST API on Palo Alto firewalls. This plugin gets API credentials from
ipdevpoll.conf
, which is not desirable in the long run. This kind of information should rather be stored in its own kind of management profile, so it can be added through the Seed Database tool and be re-used across multiple devices.Describe the solution you'd like
It is not clear to me at this point whether "Palo Alto API" should be its own management profile type, or if it would be sufficient to have a "REST API" profile that could be re-used across multiple vendors. In reality, there are many ways to authenticate against a even a REST API, so what's required for such a profile in the long run might be more than just an "api token" string. Perhaps "REST API with static token" would be a suitable name?
Describe alternatives you've considered
The current solution is a workable alternative, but not a very good one.
Additional context
See #2613 for the original implementation.
The text was updated successfully, but these errors were encountered: