TL;DR — A Microsoft tornou GA a integração do Application Gateway for Containers com o Istio service mesh, automatizando mutual TLS (mTLS) para tráfego norte-sul. Para empresas brasileiras que rodam Kubernetes no Azure, isso reduz complexidade operacional, elimina bypass de segurança em ingress e facilita compliance. A novidade elimina a necessidade de configurar manualmente gateways e sidecars para tráfego externo, unificando políticas de segurança em um único controlador.
O que essa integração resolve de fato?
Até recentemente, times de engenharia que adotavam o Istio para gerenciar o tráfego leste-oeste (entre serviços) enfrentavam um problema clássico: o tráfego norte-sul (entrada externa) muitas vezes contornava as políticas do mesh. Era comum ver um Application Gateway tradicional encaminhando requisições diretamente para um serviço, ignorando a criptografia mTLS e as regras de autorização definidas no Istio. Para corrigir isso, era necessário configurar manualmente um Istio Ingress Gateway, ajustar certificados e garantir que o gateway on-premises se comunicasse corretamente com o mesh — um processo propenso a erros e com alto custo operacional.
A novidade agora disponível em GA é a integração nativa do Application Gateway for Containers com o Istio. Ela automatiza a conexão mTLS entre o gateway e os workloads no mesh. Na prática, isso significa que o tráfego que chega pelo Application Gateway já chega criptografado e autenticado dentro do Istio, sem que o time precise configurar manualmente gateways intermediários ou políticas de criptografia duplicadas.
Como funciona a automação de mTLS no fluxo norte-sul?
A integração se apoia em dois componentes principais: o Application Gateway for Containers (que agora atua como um proxy de entrada com capacidade de se conectar ao Istio) e o Istio service mesh (que gerencia a identidade e a criptografia dos serviços). O gateway descobre dinamicamente os endpoints dos serviços dentro do mesh por meio do controlador do Istio e estabelece automaticamente túneis mTLS com cada pod. Não há mais necessidade de criar Gateway e VirtualService do Istio para tráfego externo — o Application Gateway se encarrega de aplicar as mesmas políticas de segurança que você define no mesh.
Para o time de operações, o ganho é duplo: redução de configuração manual (menos YAML para versionar) e eliminação de brechas de segurança (todo tráfego externo passa a ser obrigatoriamente mTLS). Para empresas brasileiras que precisam atender a requisitos de LGPD e compliance de setor regulado, essa uniformidade reduz o risco de um incidente por um endpoint mal configurado.
Quais os cenários práticos para empresas brasileiras?
Imagine um e-commerce que usa Kubernetes no Azure com Istio para controlar a comunicação entre microsserviços de catálogo, carrinho e pagamento. Antes, o tráfego vindo do load balancer externo (via Application Gateway tradicional) chegava ao serviço de frontend sem passar pelas políticas de mTLS do Istio. Qualquer vulnerabilidade no frontend poderia expor dados sensíveis. Com a nova integração, o Application Gateway for Containers estabelece mTLS direto com o pod do frontend — e o Istio garante que qualquer tentativa de acesso não autorizado seja barrada.
Outro cenário comum é o uso de múltiplos clusters (multicluster Istio). A integração permite que um único Application Gateway for Containers se conecte a serviços em diferentes clusters, desde que eles estejam no mesmo service mesh. Isso facilita a adoção de estratégias de disaster recovery e deploy canário sem duplicar a camada de entrada.
Pontos de atenção ao adotar a integração
Apesar dos benefícios, a novidade não é uma bala de prata. Primeiro, ela está disponível apenas para o Application Gateway for Containers, que é um recurso mais recente e com um modelo de precificação diferente do Application Gateway clássico. Empresas que já investiram pesado em automação em torno do gateway clássico precisarão avaliar o custo da migração.
Em segundo lugar, a integração depende de uma versão compatível do Istio (certifique-se de que seu mesh está atualizado). Além disso, todo o tráfego norte-sul fica centralizado no Application Gateway — se houver um pico inesperado, o gateway pode se tornar um gargalo. Times de FinOps devem considerar o custo do gateway provisionado versus o tráfego real.
Por fim, lembre-se de que a automação de mTLS reduz o atrito operacional, mas não substitui uma boa estratégia de observability. Monitore métricas de handshake TLS e latência para garantir que a integração não introduza degradação perceptível.
Como essa novidade se encaixa no cenário de cloud brasileiro?
O mercado brasileiro de cloud tem adotado Kubernetes de forma acelerada, especialmente em setores como fintechs, varejo e saúde. A exigência de segurança fim a fim é cada vez maior, e soluções que simplificam a implementação de mTLS sem sacrificar a performance são bem-vindas. Além disso, a automação reduz a dependência de engenheiros seniores para configurações manuais de gateway — um gargalo comum em times enxutos.
A integração também sinaliza uma tendência: grandes provedores estão eliminando a fronteira entre o balanceador de carga externo e o service mesh. Isso empurra o mercado para uma arquitetura onde a segurança de rede é definida de forma declarativa e aplicada consistentemente, independentemente da direção do tráfego. Para empresas que ainda usam soluções híbridas (gateway tradicional + sidecar manual), essa é uma oportunidade de simplificar e reduzir riscos.
Perguntas Frequentes
-
Essa integração funciona com qualquer versão do Istio?
A integração foi validada com o Istio upstream e também com o Azure Service Mesh (baseado em Istio). É recomendável verificar a compatibilidade com a versão específica do Istio em uso, especialmente em ambientes com customizações avançadas no mesh. -
Preciso substituir meu Application Gateway atual?
Não. A funcionalidade está disponível exclusivamente no Application Gateway for Containers (recurso mais recente), não no Application Gateway clássico (v1/v2). Se você usa o gateway clássico, precisará avaliar uma migração ou manter ambos para cenários híbridos. -
O mTLS automático afeta a latência do tráfego norte-sul?
Sim, há um overhead adicional devido à negociação TLS mútua. No entanto, a automação elimina a latência gerada por configurações manuais e possíveis loops de renegociação. Em testes da Microsoft, o impacto médio fica abaixo de 5ms, aceitável para a maioria dos workloads. -
Essa integração é útil para ambientes multicloud?
Indiretamente. O Application Gateway for Containers é um recurso nativo do Azure. Se sua estratégia multicloud inclui Azure como nuvem principal para Kubernetes, a integração traz benefícios. Para tráfego que transita entre clouds, você ainda precisará de soluções adicionais como gateways multicloud ou políticas de mesh distribuído.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
