Restricting API token access to specific IP addresses
You can restrict an API token so that it is accepted only from the IP addresses and subnets that you specify. The list of addresses is called the allowed list. If a request presents a valid token from an address that is not in the allowed list, the appliance rejects the request with HTTP status 403 (Forbidden). Use an allowed list to limit the exposure if a token is copied from the system that you issued it for.
You can configure an allowed list for the following token types:
Personal API tokens. You can configure the allowed list for your own token only.
Predefined API tokens, which include the metrics token and the support token.
The allowed list is optional. You can configure it when you generate the token, and you can change it at any time afterwards.
Review the following considerations:
If the allowed list is empty, the token is not restricted and the appliance accepts it from any IP address. The token details show No restriction. Tokens that you generated before you updated the appliance have an empty allowed list, so they continue to work as before until you add entries to them.
An allowed list can contain up to five entries. Each entry must be unique and must be an IPv4 address, an IPv6 address, or a subnet in CIDR notation (for example, 10.10.20.0/24 or fd00::/64).
Unspecified addresses (0.0.0.0 or ::) are not valid entries. If you do not want to restrict the token, leave the allowed list empty.
If a client system uses DHCP or dynamic IP assignment, add a subnet instead of a single IP address.
When you update an allowed list, the change applies to the next request that uses the token. The token itself does not change, so you do not have to distribute a new token to the systems that use it.
If the appliance is behind an external reverse proxy, load balancer, or gateway, the allowed list must contain the IP address of that intermediate system (the IP from which the appliance directly receives the connection), rather than the original client IP. If the appliance cannot determine the client IP and an allowed list is configured, the request is rejected.
Systems that connect through a VPN or shared egress gateway present the same source IP. An allowed list cannot distinguish between individual clients behind a shared egress IP.
Token-level network access control is evaluated in addition to appliance-level network access control (firewall rules configured for HTTPS and SSH). Both controls are enforced.
Note the following information if API calls fail after you configure or change an allowed list:
If an API request fails with HTTP status 403: The token is valid, but the request originated from an IP address not included in the allowed list. This commonly occurs if the client system's IP changed or traffic was routed through a new proxy. Add the new IP address to the allowed list.
If a request is rejected with HTTP status 401: The allowed list is not the cause. The token is invalid, has expired, or has been revoked or deleted.
If you cannot save an allowed list: In the Flex Appliance Console, check for inline validation messages. Ensure all entries are valid IPv4/IPv6 addresses or CIDR subnets, there are no duplicates, and the total count does not exceed five. If calling the REST API directly, the appliance returns HTTP status 400 (Bad Request).