Skip to main content
The IP allowlist is a list of network addresses that your workspace trusts. Think of it as the guest list at the entrance of a building. The list belongs to the whole workspace, not to one person or one application.

​
What the allowlist protects

The allowlist has two switches. You can turn on one, the other, or both. The two switches are independent. A workspace can restrict where people sign in from and still accept API calls from anywhere, or the other way around.
Do not turn on API access before you list every address your integrations call from. Those addresses are usually not the same ones your team uses to reach the Console. An integration that calls from an unlisted address stops at once.

​
How the platform decides

Every request to a protected route goes through the same check, in this order:
  1. A request arrives at the platform with your workspace’s credentials.
  2. The platform works out the network address the request came from. Behind your load balancer, it reads the address your proxy forwards. On BYOC, see Deployment requirements. On Lerian Cloud, Lerian handles this for you.
  3. The platform checks whether the list is active for that kind of access: Console or API.
  4. If the list is active, the platform compares the address with every entry on the list.
  5. If the address matches an entry, the request continues. If it does not, the platform refuses it.
The platform repeats this check on every request. It does not decide once per session.

​
What a refused person or system sees

A system that calls the API from an unlisted address receives an HTTP 403 response with this body:
The code AUT-0021 always means the same thing: the caller’s address is outside an active list. It can come back from any protected endpoint of any Lerian product. See the Access Manager error list.

​
What you can register

An entry is a single address or a range of addresses, in IPv4 or IPv6. Rules that apply to the list:
  • Use CIDR notation for ranges. The platform does not accept “from-to” ranges such as 203.0.113.1-203.0.113.50.
  • The platform merges duplicates. 203.0.113.5 and 203.0.113.5/32 are the same entry.
  • The platform rejects a range broader than /24 for IPv4 or /48 for IPv6.
  • The allowlist shares its 200-character budget with the platform ranges. A refusal names the characters that remain. Prefer ranges over long lists of single addresses.

​
The three states of the list

The Console shows the current state in a banner at the top of the IP allowlist tab.

​
How fast a change applies

A change applies to the next request. The platform reads the list and the caller’s address on every request. This also means a token does not keep access alive. A person or system that already holds a valid token is refused on its next request if its address is no longer on the list.

​
What the allowlist does not cover

  • Lerian’s own platform services keep working. Requests that carry a platform-internal token bypass the list, so your workspace does not stop by accident.
  • There is no administrator exemption. An administrator who connects from an unlisted address is refused like anyone else. Keep at least one address you control on the list.
  • Break-glass. If every administrator is locked out, contact Lerian support to restore access.

​
Next steps

Manage the list in the Console

Read the status of the list and deactivate it.

Manage the list via API

Read and replace the list with two Identity API operations, with examples.

Deployment requirements

What a BYOC operator configures so the platform learns the caller’s real address.

Error list

Every code the allowlist can return, with title and message.