Como inspecionar tráfego mTLS em pods no Kubernetes com cURL

Por que o mTLS blinda microsserviços no Kubernetes?

Em ambientes modernos de infraestrutura, garantir que um container converse apenas com quem deve é uma questão de sobrevivência operacional. É aqui que entra o mTLS, ou Transport Layer Security mútuo, um protocolo que exige que tanto o cliente quanto o servidor apresentem certificados digitais válidos antes de qualquer troca de dados. Na prática, isso significa que não basta apenas criptografar o canal; cada microsserviço precisa provar sua identidade criptográfica na rede do cluster, impedindo que intrusos escutem ou falsifiquem mensagens entre aplicações vizinhas.

Quando adotamos ferramentas de malha de serviços ou Service Mesh, como Istio ou Linkerd, essa blindagem acontece de forma automatizada através de proxies injetados ao lado da nossa aplicação. No entanto, quando um erro de handshake acontece — ou seja, quando a negociação inicial de segurança falha e a conexão é rejeitada —, descobrir a causa exata vira um verdadeiro quebra-cabeça. Muitas vezes, o tráfego é bloqueado silenciosamente, gerando erros crípticos nos logs que parecem não apontar para lugar nenhum.

O desafio de debugar falhas de handshake TLS em ambiente isolado

Debugging de rede em clusters Kubernetes costuma ser estressante porque os pods rodam em namespaces isolados, muitas vezes sem ferramentas tradicionais de diagnóstico instaladas nas imagens de produção. Quando o tráfego é mascarado por criptografia mútua, inspecionar pacotes com ferramentas de captura de pacotes como o tcpdump mostra apenas blocos de dados cifrados ilegíveis, sem revelar o motivo pelo qual o certificado foi recusado pelo servidor de destino.

Para piorar, antes de investigar a rede, vale lembrar que problemas de infraestrutura subjacentes, como falhas de recursos descritas em análises de limites de CPU e memória em containers, podem derrubar o proxy e simular uma falha de conexão inexistente. Por isso, isolar o problema exige simular a chamada exata que o microsserviço faz, injetando manualmente os mesmos certificados que o Service Mesh distribui aos pods, utilizando um cliente HTTP versátil como o cURL.

Como extrair certificados e chaves de um pod no Kubernetes

Antes de disparar comandos cURL, precisamos coletar os segredos criptográficos que o cluster gerou e injetou no pod de origem. O mTLS depende de três elementos principais: o certificado público da autoridade certificadora (CA), o certificado do próprio cliente e a chave privada correspondente que prova a posse daquele certificado.

Normalmente, esses arquivos ficam armazenados em volumes montados dentro do container, muitas vezes no diretório /etc/certs ou em segredos do Kubernetes montados via volumeMounts. Para inspecionar esses arquivos sem alterar o ambiente de produção, podemos abrir um shell interativo em um pod de debug efêmero ou copiar os arquivos diretamente usando o comando de cópia remota do Kubernetes:

kubectl cp meu-namespace/meu-pod-abc:/etc/certs/tls.crt ./tls.crt && kubectl cp meu-namespace/meu-pod-abc:/etc/certs/tls.key ./tls.key

Com os arquivos salvos localmente, podemos inspecionar a validade e os nomes alternativos de sujeito (SANs) usando o utilitário OpenSSL para garantir que o certificado não expirou e realmente pertence ao serviço que estamos tentando depurar.

Executando o cURL com mTLS para simular a chamada entre pods

Com os arquivos de certificado em mãos, o próximo passo é montar o comando cURL apontando para o endereço IP interno do pod de destino ou para o nome do serviço no DNS interno do cluster. Como o servidor exige autenticação mútua, precisamos informar explicitamente o certificado do cliente (--cert), a chave privada (--key) e a CA que valida o certificado do servidor (--cacert).

Para executar esse teste na prática, siga a sequência abaixo de dentro de um pod de apoio ou utilitário com cURL instalado no mesmo cluster:

1. Copie os arquivos de certificado e chave privada para o diretório de trabalho atual do pod de diagnóstico.
2. Execute o comando cURL passando os parâmetros de mTLS apontando para a porta segura do microsserviço alvo.
3. Analise o código de status HTTP retornado e o relatório detalhado de handshake gerado pelo parâmetro de verbosidade.

O comando prático para o teste assume a seguinte estrutura detalhada:

curl -iv --cert /tmp/tls.crt --key /tmp/tls.key --cacert /tmp/ca.crt https://servico-destino.namespace.svc.cluster.local:8443/api/v1/status

As flags -i e -v são cruciais aqui: elas exibem os cabeçalhos de resposta e todo o rastreamento detalhado do estabelecimento da conexão TLS, permitindo identificar exatamente em qual etapa o handshake falhou.

Interpretando os erros comuns de handshake e resolvendo problemas

Quando o comando cURL retorna um erro de conexão, o texto impresso no terminal costuma revelar a raiz do problema. Se o erro for SSL certificate problem: self signed certificate in certificate chain, significa que o servidor apresentou um certificado assinado por uma CA que o cliente desconhece — a solução é garantir que o arquivo apontado em --cacert seja exatamente a CA raiz que emitiu o certificado do servidor.

Outro erro clássico ocorre quando o servidor rejeita o cliente com um código de alerta de handshake, o que geralmente indica que o certificado do cliente expirou ou que o domínio acessado não confere com os nomes alternativos permitidos nas regras de segurança do Service Mesh. Validar esses detalhes elimina gargalos invisíveis e devolve a previsibilidade operacional ao ecossistema de microsserviços.

Considerações finais sobre diagnóstico de rede em malhas de serviços

Inspecionar tráfego mTLS em pods do Kubernetes utilizando o cURL é uma habilidade indispensável para engenheiros que lidam com arquiteturas distribuídas complexas. Embora malhas de serviços automatizem grande parte da criptografia, entender os mecanismos subjacentes de certificados e saber forjar requisições manuais acelera drasticamente a resolução de incidentes em produção. Dominar essa técnica transforma falhas obscuras de rede em diagnósticos rápidos e precisos.