Skip to main content
The IP allowlist compares the caller’s network address with the list. Behind a load balancer or an ingress, the address the service sees is the proxy’s, not the caller’s. This page tells a BYOC operator what to configure so the platform learns the real address.
This page applies to BYOC deployments only. On Lerian Cloud, Lerian operates this configuration for you. You only manage the list itself.
For the architecture view, read Tenant IP allowlist. For the enforcement contract, read the August 2026 announcement.

​
Trusted proxies

Set TRUSTED_PROXIES on these Lerian services, not only on the Access Manager:
  • The Access Manager Auth and Identity services.
  • The products Midaz, Flowker, Reporter, Lender, and Streaming Hub.
  • The rails Pix via JD, Pix Lerian, and Bank Transfer.
Each of these services resolves the caller’s address on its own and forwards it to the Access Manager Auth service. A service without the variable forwards no address. When a workspace turns on the API access switch, Auth refuses the requests of that service. If the service calls Auth from a network in PLATFORM_INTERNAL_CIDRS, Auth allows the request without checking the address. On the Access Manager itself, the variable decides whether the allowlist enforces at all, as the table below shows. The value is a comma-separated list of CIDR ranges. List only the proxies that connect directly to that service.
Rules the platform applies to the value:
  • CIDR ranges only. A bare address without a prefix is rejected.
  • Very broad ranges are rejected: broader than /8 for IPv4 or /48 for IPv6. 0.0.0.0/0 never works.
  • On the Access Manager, a malformed value stops the service at startup.
What happens when the value is absent: Each of these services honors the API access switch only when its own deployment has TRUSTED_PROXIES set. With TRUSTED_PROXIES set and an API allowlist configured for the workspace, an Auth that has PLATFORM_INTERNAL_CIDRS unset trusts no forwarded address and refuses every product request to that workspace.

​
Validate the deployment

Run this check once after you set the variables, from a workspace whose list you control.
1

Activate a list with your own address

Send the list through the Identity API with "scopes": ["console", "api"]. Include the address you connect from and the address your test client calls from.
2

Sign in from a listed address

Sign in from that address. The sign-in must succeed.
3

Sign in from an unlisted address

Sign in from another network, such as a mobile connection. Expect a refusal.
4

Call a Midaz endpoint from both addresses

Call any protected Midaz endpoint from the listed address, then from the unlisted one. Expect 200 and then 403 with code AUT-0021.
If the platform accepts a request from the unlisted address, it does not learn the real address. Check TRUSTED_PROXIES on the service that answered and PLATFORM_INTERNAL_CIDRS on Auth and Identity.

Tenant IP allowlist architecture

How Auth, Identity, and each product share the check.

Manage the list in the Console

The administrator’s guide to the Security page.