APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Service mesh usa proxies para gerir tráfego entre workloads. mTLS estabelece identidade e protege transporte no caminho configurado; intentions definem relações permitidas. Um certificado válido não autoriza todas as chamadas. Identifica origem e destino: permitir frontend para pricing não equivale à direção inversa. Define explicitamente a política por omissão e valida ausência de regra, permissão e negação. Para decisões por método ou path HTTP, usa permissões L7 e configuração de protocolo adequada. Uma regra L4 que permite ligação não se transforma num filtro GET apenas porque a aplicação utiliza HTTP. Normalização de pedidos e comportamento efetivo do proxy também merecem revisão quando o controlo depende do path.
Aplicação guiada
Num piloto fictício, o teste pelo proxy é negado mas a porta direta responde. A política pode estar correta no proxy e o desenho continuar incompleto. Restringe listeners e caminhos de rede para que a comunicação relevante atravesse o ponto de controlo. Loopback ajuda num host, mas processos locais sem isolamento podem continuar a alcançar o serviço; o modelo de confiança precisa de refletir isso. Na aceitação, inclui testes de acesso autorizado, negado e tentativas pelo caminho direto. Regista identidade observada, destino e regra efetiva. Evita distribuir credenciais mais amplas para esconder falhas de configuração e não declares toda a rede protegida a partir de um único pedido bem-sucedido.
Deny aplicado no proxy não prova controlo sobre uma porta acessível fora dele.
Armadilhas comuns
Certificado como permissão universal; direção invertida; teste só pelo caminho previsto.
Tópicos relacionados: Descoberta, arquitetura e quorum · Deployment e bootstrap · Registo, health checks e DNS
Demonstra identidade, autorização e ausência de bypass para o âmbito aceite.
Referência: Service intentions and L7 permissions · Historical Consul Associate (003), retired 2026-07-15; technical references inspected 2026-09-30