O TLS padrão autentica apenas em uma direção: o cliente verifica o certificado do servidor, mas o servidor não verifica o cliente. O Mutual TLS (mTLS) resolve essa lacuna — ambos os lados apresentam certificados e se autenticam mutuamente antes de trocar dados. Por isso, o mTLS é a base para comunicação serviço a serviço com confiança zero.
O Alibaba Cloud Service Mesh (ASM) aplica mTLS nas três etapas do tráfego em um ambiente Kubernetes sem exigir alterações no código da aplicação. Você também pode usar os certificados fornecidos pelo mTLS em cada etapa para controle de acesso. Além disso, o ASM gerencia automaticamente a emissão e a rotação de certificados, eliminando a necessidade de manipulação manual.
Etapas do tráfego e como o ASM as protege
O tráfego de ponta a ponta em um ambiente Kubernetes passa por três etapas. O ASM protege cada uma delas de forma específica:
|
Etapa |
Direção |
Como o ASM protege |
|
Ingress |
Clientes externos para serviços dentro do cluster |
Clientes externos acessam serviços internos do cluster por meio do gateway de ingress do ASM. Configure o mTLS e restrinja o acesso a certificados de clientes específicos. |
|
Leste-oeste |
Entre workloads dentro do cluster |
Os proxies sidecar atualizam automaticamente as conexões para mTLS. Não são necessárias alterações na aplicação nem configurações adicionais. |
|
Egress |
Workloads do cluster para serviços externos |
O gateway de egress do ASM intercepta requisições em texto simples dos workloads e as atualiza para mTLS antes de encaminhá-las ao serviço externo. |
Por que usar o ASM para mTLS
|
Benefício |
Descrição |
|
Separação de responsabilidades |
As aplicações focam na lógica de negócios enquanto o ASM cuida da autenticação e criptografia no nível de infraestrutura, acelerando os ciclos de desenvolvimento. |
|
Gestão automatizada de certificados |
O ASM emite certificados com base no ServiceAccount do Kubernetes de cada workload e os rotaciona automaticamente, dispensando operações manuais de certificados. |
|
Adoção sem interrupções |
Aplicações existentes não precisam de alterações no código. A injeção de proxy sidecar e a configuração do gateway ocorrem no nível de infraestrutura. |
Proteja o tráfego de ingress com mTLS
Clientes externos acessam serviços internos do cluster por meio do gateway de ingress do ASM. Para impor o mTLS no ingress:
Configure o gateway de ingress do ASM para exigir certificados de cliente.
Restrinja o acesso a clientes específicos validando os atributos de seus certificados.
Para instruções detalhadas de configuração, consulte Configurar serviço mTLS no gateway de ingress do ASM e restringir acesso a clientes específicos.
Proteja o tráfego leste-oeste com mTLS
O mTLS leste-oeste é uma capacidade nativa do ASM. Após a injeção de proxies sidecar em ambos os lados de uma conexão, o tráfego entre eles é automaticamente atualizado para mTLS — sem necessidade de configuração adicional.
Para injetar proxies sidecar, consulte Instale um proxy sidecar.
O que é coberto automaticamente
Tráfego Pod a Pod: A comunicação entre dois Pods com proxies sidecar injetados usa mTLS automaticamente.
Tráfego Gateway para sidecar: O gateway de ingress do ASM, o gateway de egress e os proxies sidecar conectam-se ao plano de controle do ASM. A comunicação entre quaisquer desses componentes também utiliza mTLS.
Ciclo de vida dos certificados
Os certificados para mTLS leste-oeste são emitidos com base na identidade do ServiceAccount de cada workload. O plano de controle do ASM gerencia tanto a emissão quanto a rotação periódica, eliminando a necessidade de gestão manual de certificados.
Migrar para mTLS estrito
O ASM suporta migração gradual de texto simples para mTLS completo por meio de políticas de autenticação de identidade de pares:
**Durante a migração, defina o modo de autenticação de identidade de pares como
PERMISSIVE**. Nesse modo, os workloads aceitam tráfego em texto simples e mTLS, permitindo que serviços fora do mesh continuem se comunicando durante a transição.**Após a migração, alterne o modo de autenticação de identidade de pares para
STRICT**. Nesse modo, os workloads aceitam apenas tráfego mTLS, garantindo criptografia total para toda a comunicação leste-oeste.
Proteja o tráfego de egress com mTLS
Quando um workload dentro do cluster chama um serviço externo que exige mTLS, a aplicação pode continuar enviando requisições em texto simples. O gateway de egress do ASM intercepta essas requisições, atualiza-as para mTLS e as encaminha ao serviço externo. Isso elimina a necessidade de configuração de TLS no nível da aplicação ao acessar endpoints mTLS externos.
Para instruções de configuração, consulte Usar o gateway de egress do ASM para acessar serviços mTLS externos.