Pular para o conteúdo principal
A lista de IPs permitidos compara o endereço de rede de quem chamou com a lista. Atrás de um load balancer ou de um ingress, o endereço que o serviço vê é o do proxy, não o de quem chamou. Esta página diz a um operador BYOC o que configurar para a plataforma descobrir o endereço real.
Esta página vale apenas para deploys BYOC. Na Lerian Cloud, a Lerian opera essa configuração para você. Você gerencia apenas a lista em si.
Para a visão de arquitetura, leia Lista de IPs permitidos do tenant.

​
Proxies confiáveis

Defina TRUSTED_PROXIES nestes serviços Lerian, não apenas no Access Manager:
  • Os serviços Auth e Identity do Access Manager.
  • Os produtos Midaz, Reporter, Lender e Streaming Hub.
  • Os trilhos Pix via JD, Pix via BTG, Pix Lerian e Bank Transfer.
Cada um desses serviços resolve o endereço de quem chamou por conta própria e o encaminha ao serviço Auth do Access Manager. Um serviço sem a variável não encaminha endereço nenhum. O Auth usa um endereço encaminhado apenas de quem chama de dentro de TRUSTED_PROXIES ou PLATFORM_INTERNAL_CIDRS do Auth. No próprio Access Manager, a variável decide se a lista é aplicada ou não, como mostra a tabela abaixo. O valor é uma lista de faixas CIDR separadas por vírgula. Liste apenas os proxies e as redes que se conectam diretamente àquele serviço. No Auth, inclua as redes a partir das quais os produtos e trilhos chamam o Auth.
Regras que a plataforma aplica ao valor:
  • Apenas faixas CIDR. Um endereço solto, sem prefixo, é recusado.
  • Faixas muito amplas são recusadas: mais amplas que /8 para IPv4 ou /48 para IPv6. 0.0.0.0/0 nunca funciona.
  • No Access Manager, um valor malformado interrompe o serviço na inicialização.
O que acontece quando o valor está ausente: Em uma requisição de produto (POST /v1/authorize) de quem chama de fora de TRUSTED_PROXIES e PLATFORM_INTERNAL_CIDRS do Auth, o Auth verifica o próprio endereço de quem chama quando esse endereço é público. Quando ele não é público, como um endereço privado ou CGNAT, o Auth permite a requisição sem verificação. Uma métrica e uma linha de log que nomeia o endereço sinalizam isso. Na entrada e na emissão de tokens, o Auth verifica o próprio endereço de quem chama, público ou não.

​
Validar o deploy

Rode esta verificação uma vez depois de definir as variáveis, a partir de um workspace cuja lista você controla.
1

Ative uma lista com o seu próprio endereço

Envie a lista pela API do Identity com "scopes": ["console", "api"]. Inclua o endereço de onde você se conecta e o endereço de onde o seu cliente de teste chama.
2

Entre a partir de um endereço listado

Entre a partir desse endereço. A entrada deve dar certo.
3

Entre a partir de um endereço não listado

Entre a partir de outra rede, como uma conexão móvel. Espere uma recusa.
4

Chame um endpoint do Midaz a partir dos dois endereços

Chame qualquer endpoint protegido do Midaz a partir do endereço listado e depois do não listado. Espere 200 e depois 403 com o código AUT-0021.
Se a plataforma aceita uma requisição do endereço não listado, ela não descobre o endereço real. Verifique TRUSTED_PROXIES no serviço que respondeu e no Auth, e PLATFORM_INTERNAL_CIDRS no Auth e no Identity.

​
Páginas relacionadas

Arquitetura da lista de IPs permitidos do tenant

Como o Auth, o Identity e cada produto compartilham a verificação.

Gerencie a lista no Console

O guia do administrador para a página Segurança.