Saltar al contenido principal
La lista de IP permitidas compara la dirección de red del llamador con la lista. Detrás de un balanceador de carga o un ingress, la dirección que ve el servicio es la del proxy, no la del llamador. Esta página le dice a un operador BYOC qué configurar para que la plataforma conozca la dirección real.
Esta página aplica solo a despliegues BYOC. En Lerian Cloud, Lerian opera esta configuración por ti. Tú solo gestionas la lista en sí.
Para la vista de arquitectura, lee Lista de IP permitidas del tenant.

​
Proxies de confianza

Define TRUSTED_PROXIES en estos servicios Lerian, no solo en el Access Manager:
  • Los servicios Auth e Identity de Access Manager.
  • Los productos Midaz, Reporter, Lender y Streaming Hub.
  • Los rieles Pix via JD, Pix via BTG, Pix Lerian y Bank Transfer.
Cada uno de estos servicios resuelve la dirección del llamador por su cuenta y la reenvía al servicio Auth de Access Manager. Un servicio sin la variable no reenvía ninguna dirección. Auth usa una dirección reenviada solo de un llamador en TRUSTED_PROXIES o PLATFORM_INTERNAL_CIDRS de Auth. En el propio Access Manager, la variable decide si la lista de IP permitidas se hace cumplir o no, como muestra la tabla de abajo. El valor es una lista de rangos CIDR separados por comas. Lista solo los proxies y las redes que se conectan directamente a ese servicio. En Auth, incluye las redes desde las que los productos y rieles llaman a Auth.
Reglas que la plataforma aplica al valor:
  • Solo rangos CIDR. Una dirección suelta sin prefijo se rechaza.
  • Los rangos muy amplios se rechazan: más amplios que /8 para IPv4 o /48 para IPv6. 0.0.0.0/0 nunca funciona.
  • En el Access Manager, un valor mal formado detiene el servicio en el arranque.
Qué pasa cuando falta el valor: Para una solicitud de producto (POST /v1/authorize) de un llamador fuera de TRUSTED_PROXIES y PLATFORM_INTERNAL_CIDRS de Auth, Auth verifica la propia dirección del llamador cuando esa dirección es pública. Cuando no es pública, como una dirección privada o CGNAT, Auth permite la solicitud sin verificación. Una métrica y una línea de log que nombra la dirección lo señalan. En el inicio de sesión y la emisión de tokens, Auth verifica la propia dirección del llamador, pública o no.

​
Valida el despliegue

Haz esta verificación una vez después de definir las variables, desde un espacio de trabajo cuya lista controles.
1

Activa una lista con tu propia dirección

Envía la lista mediante la API de Identity con "scopes": ["console", "api"]. Incluye la dirección desde la que te conectas y la dirección desde la que llama tu cliente de prueba.
2

Inicia sesión desde una dirección listada

Inicia sesión desde esa dirección. El inicio de sesión debe tener éxito.
3

Inicia sesión desde una dirección no listada

Inicia sesión desde otra red, como una conexión móvil. Espera un rechazo.
4

Llama a un endpoint de Midaz desde ambas direcciones

Llama a cualquier endpoint protegido de Midaz desde la dirección listada, luego desde la no listada. Espera 200 y luego 403 con el código AUT-0021.
Si la plataforma acepta una solicitud desde la dirección no listada, no conoce la dirección real. Revisa TRUSTED_PROXIES en el servicio que respondió y en Auth, y PLATFORM_INTERNAL_CIDRS en Auth e Identity.

​
Páginas relacionadas

Arquitectura de la lista de IP permitidas del tenant

Cómo comparten la verificación Auth, Identity y cada producto.

Gestiona la lista en Console

La guía del administrador para la página Security.