Istio vs NGINX

Objetivo

Definir qual ferramenta adotar para ambiente de Desenvolvimento, colocando em pauta, tempo de entrega, retrabalho e recursos disponibilizados por cada uma.

Necessidades

Authenticação dinâmica

Será necessário interceptar chamadas para um serviço broker na camada L7 , e validar a autenticação de maneira dinâmica em um serviço voltado para isso.
Security example

Gerenciamento de Ingress

Deverá controlar as entradas do cluster, sendo que, para isso haverá um microserviço que escreverá no k8s os objetos necessários para receber chamadas de novos hostnames (um por tenant, evitando *.totvs.apps).
K8s API Server

Fazer controle de RateLimit através de RLS de forma dinâmica (futuro)

Deverá calcular o ratelimit para o microserviço broker de forma dinâmica por hostname/path e rotular via cabeçalho chamadas overaged.
RLS

Allow/Deny IP List dinâmico

Deverá validar CIDRs, faixa de ips, ou ips específicos cadastrados pelo usuário e fazer o networking policy.

Comparações

Authenticação

#ext_authz (Envoy/Istio)

  • Onde aparece: recurso nativo do Envoy Proxy, usado pelo Istio (tanto em sidecar quanto em ambient mode).
  • Como funciona: Ao receber uma requisição, o Envoy envia um check request (gRPC ou HTTP) para um Authorization Service externo (ex: Keycloak Adapter, OPA, custom service). Esse serviço responde ALLOW ou DENY, podendo adicionar headers extras ou manipular o request/response.
  • Protocolos: suporta gRPC (mais eficiente) e HTTP.
  • Flexibilidade: muito alto.
    Você pode:
  • Validar tokens (JWT, OAuth2, API Key etc.)
  • Enriquecer a requisição (injetar headers, claims, atributos de tenant)
  • Decidir granularmente em cada rota ou método.
  • Cenários comuns:
  • Multi-tenant auth dinâmico
  • Rate limiting com RLS.

#auth_request (NGINX)

  • Onde aparece: módulo do NGINX (ou NGINX Ingress Controller).
  • Como funciona: O NGINX intercepta a requisição e faz uma sub-requisição HTTP para uma URL interna (/auth). Esse endpoint responde 2xx (permitido), 401/403 (negado). Se permitido, o NGINX encaminha a requisição original para o backend.
  • Protocolos: apenas HTTP.
  • Flexibilidade: mais limitado.
  • Normalmente só decide permitir ou negar.
  • Headers extras podem ser repassados, mas não tem o nível de enriquecimento e padronização do ext_authz.
  • Cenários comuns:
  • Autenticação simples em ingress (NGINX Ingress + Keycloak gatekeeper, por ex.).
  • Situações de baixo tráfego ou quando não precisa de decisões complexas.
  • Mais fácil de configurar rapidamente.

#Objetos k8s

Istio
IstioOperator
NGINX
Ingress NGINX

Ingress

#Kubernetes Gateway API + Istio Ambient (Gateway/HTTPRoute)

  • Padrão K8s: Gateway API (oficial, evolui rápido, semântica portável)
  • Camadas: L4 por ztunnel (sidecarless) + L7 opcional via Waypoint (por SA/namespace)
  • mTLS interno: Nativo (ztunnel cifra tudo pod↔pod)
  • Performance: L4 barato por ztunnel; L7 só onde precisa (waypoint)
  • Complexidade: Mais peças (ztunnel DS, CNI, opcional waypoint, east-west)
  • Cenário ideal: Zero-trust interno + políticas L7 dinâmicas entre serviços + multi-tenant

#Ingress + NGINX Ingress Controller

  • Padrão K8s: Ingress (padrão antigo, semântica limitada, muitas anotações)
  • Camadas: abre um listener L4 Mas toda a lógica real acontece na camada L7 (HTTP/HTTPS); dentro do cluster é tráfego plano
  • mTLS interno: Não tem (precisa mTLS app-to-app ou outro mesh)
  • Performance: L7 muito eficiente na borda; intra-cluster sem aceleração
  • Complexidade: Simples para “apenas expor HTTP/TLS”
  • Cenário ideal: Edge proxy simples/estável, poucas políticas internas, custo/stack mínimos

#Objetos k8s

Istio
Gateway API
NGINX
Ingress NGINX

Custo de tempo para o Projeto

Utilizar o Istio traria mais tempo de desenvolvimento?

Para o MVP — interceptar a chamada ao broker para autenticação e fazer o ingress com rotas dinâmicas por tenant — começar já com Istio (Ambient + Gateway API) reduz o retrabalho e te dá os ganchos certos (ext_authz, RLS, mTLS, telemetria). NGINX pode ser ligeiramente mais rápido para “somente ingress”, mas, no nosso caso, a diferença de prazo é pequena e o custo de migração depois é alto (reescrever objetos, trocar mecanismos de auth/ratelimit, observabilidade e políticas). Recomendação: começar com Istio.

Por que Istio fica pari a pari ou até mais rápido?

Porque o que pesa no MVP é interceptação L7 (auth + allow/deny IP list+ rate-limit). No NGINX isso tende a virar cola de anotações + auth_request + possivelmente Lua/OpenResty; no Istio/Envoy você usa primitivas nativas (ext_authz, RLS) e conecta direto no seu security-server e no Valkey

Custo de migração NGINX → Istio (o tax oculto)

Se começar em NGINX e migrar depois:

  • Objetos de rede: reescrever Ingress (+anotações) para Gateway + HTTPRoute; rever backend policies e filters.
  • Auth: trocar auth_request (ou Lua) por ext_authz; ajustar payloads/enrichment (headers, JWTs, atributos).
  • Rate-limit: sair de limit-req/plugins e implementar Envoy RLS (com esquema/keys no Redis/Valkey).
  • Automação/Helm: refazer templates e values.

Caminho recomendado (curto e seguro) no Istio Ambient

Minimo no cluster

#Feito por cluster admin

  • CRDs da Gateway API
  • Instalar o Istio em Ambient Mode (ztunnel + CNI). Isso dá o data-plane L4 (mTLS, policy L4) e suporte aos recursos Gateway/HTTPRoute.
  • Habilitar namespaces/pods no Ambient com o rótulo
  • Criar um Waypoint para a namespace
  • Criar um Gateway de borda compartilhado (em uma ns “infra”, ex.: istio-ingress), usando a GatewayClass do Istio (istio para ingress) e liberando HTTPRoute de outros namespaces via allowedRoutes

#Permissões para desenvolvimento

  • Permissões para criar/atualizar HTTPRoute na ns.
  • Permissões padrão para service, deployment, hpa, pdb ...

Quando NGINX faria sentido?

  • MVP somente ingress público (sem interceptar L7), prazo ultra curto e certeza de que o produto não exigirá políticas L7/mesh.
  • Time sem nenhuma experiência com Istio/Envoy e sem tempo para aprender (não é o seu caso; você já está montando Ambient + Gateway API).