DotW: Restricted access to the API

Is it possible to restrict access to the API? What are some best practices to prevent an API key being used by another host to access the firewall? In this week's Discussion of the Week, we're taking a closer look at a question community member XavierMe asked about access to the API.

The API is part of the features available on a managment interface, and access to the management features can be controlled and restricted in several ways:

The most straightforward restrictions can be set by configuring the Management Interface Settings and the Interface Management Profiles to allow only certain services like SSH and SSL, but not permit Telnet or other unnecessary services. The API is available on the web interface only, so you could disable HTTP/HTTPS on any interface where it is not required, and use only SSH. You can also limit access to management services based on source IP or subnet, preventing unauthorized networks from accessing the services entirely.

If several different administrators require access to the firewall but some are not authorized to access the API, using admin roles allows you to further control which actions are available and what's visible or invisible to each group of administrators. Parts of the GUI can be made read-only or invisible. Some log output can be made anonymous, so an administrator may be able to use logs for troubleshooting but not user enumeration:

Access to the API can also be made entirely impossible to an admin, or only required parts made available. For example, an operator is allowed to collect reports or view logging, but not make configuration changes or run operational commands through the API. An automated User-ID script can add or remove user-to-IP mapping, but the account cannot be used to access any other API functionality:

In the same way, an administrator can also have no CLI access, read-only access, or limited operational or superuser access:

Lastly, if the 'Role' radio button is switched to Virtual System, all the above-mentioned restrictions can be made effective only within the assigned VSYS while the remaining VSYS are inaccessible to the administrator. In the scenario of a shared service provider or administrative boundaries between teams, this can enable admins full access within their own VSYS without accidentally interfering with another customer or team's VSYS.

I hope you found this explanation helpful. Feel free to follow the original discussion here or add comments in the comments section below

Kind regards,

Tom