Caminho das requisições

Este diagrama mostra por onde passa cada tipo de tráfego, da internet até os dados. O tráfego regulado e o tráfego público seguem caminhos separados desde a entrada no cluster.

Entrada

• Balanceador de carga da nuvem. Recebe o tráfego da internet e o entrega aos Gateways do Cilium dentro do cluster.
• Gateway em modo passthrough (api., matls-api., matls-auth.). Não abre o TLS: roteia pelo nome do host e entrega a conexão cifrada ao Kong. Assim, o certificado de cliente chega intacto ao ponto que o valida.
• Gateway que termina TLS (auth., admin., docs.). Usa certificados públicos emitidos e renovados automaticamente pelo cert-manager.

Tráfego regulado

• O Kong regulado atende matls-api. e matls-auth. e exige certificado de cliente, validado contra a cadeia ICP-Brasil informada pela instituição, só com TLS 1.2 e as cifras do perfil FAPI.
• O Kong repassa o certificado ao serviço, que confere de novo a cadeia ICP-Brasil e compara o certificado com o vínculo do token de acesso.
• Registro dinâmico, PAR e troca de código por token passam pela camada FAPI da plataforma antes de chegar ao Keycloak.

Tráfego público e administrativo

• O Kong de API atende api., com certificado de cliente opcional, limites de requisição e identificador de correlação.
• O Keycloak recebe em auth. só os caminhos necessários ao login e ao consentimento; o realm master, de administração do próprio Keycloak, não é exposto.
• O Power Admin e o portal de API da instalação ficam em admin. e docs..

Rede interna e dados

• A rede do cluster nega todo tráfego por padrão. Cada fluxo permitido é declarado: por exemplo, o Keycloak só aceita conexões dos gateways e dos serviços que precisam dele.
• As chamadas de saída para outros participantes saem direto dos serviços, com mTLS, e só para destinos autorizados.
• O PostgreSQL e o Redis gerenciados ficam em sub-redes privadas, sem acesso público. O NATS JetStream roda dentro do cluster.