TLS pós-quântico híbrido em um ingress Kubernetes

Em um cluster Kubernetes, o TLS pós-quântico híbrido é configurado no ponto onde o handshake realmente termina, quase nunca no contêiner da aplicação. Esse ponto costuma ser o pod do ingress controller, um load balancer de nuvem à frente dele ou um sidecar de service mesh. O trabalho tem quatro etapas: encontrar o ponto real de terminação, verificar a versão da biblioteca TLS em execução nele, colocar um grupo híbrido como X25519MLKEM768 antes de um grupo clássico na lista de preferência e, por fim, verificar a partir de fora do cluster.

Etapa 1: descubra onde o handshake realmente termina

Com frequência, as equipes configuram o componente errado e concluem que o controller não oferece suporte à troca de chaves pós-quântica. Mapeie primeiro o caminho de um pacote do cliente. Somente o componente que detém a chave privada e envia o ServerHello decide o grupo de troca de chaves.

Confirme a topologia com comandos somente leitura antes de alterar qualquer coisa:

kubectl get ingress -A -o wide
kubectl -n ingress-nginx get svc -o wide
kubectl -n ingress-nginx get svc ingress-nginx-controller -o jsonpath='{.metadata.annotations}'

As anotações de load balancer no Service do controller indicam se a camada de nuvem termina o TLS ou o repassa. Se ela termina, nenhuma configuração do ingress mudará o grupo negociado.

Etapa 2: verifique o que a biblioteca TLS do controller suporta

Os grupos híbridos são uma propriedade da pilha TLS compilada na imagem do controller, não do Kubernetes. Para builds baseados em OpenSSL, é necessário o OpenSSL 3.5 ou posterior para os grupos ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). Data planes baseados em BoringSSL, como o Envoy, usam nomenclatura de grupos e matriz de suporte próprias, portanto leia as notas de versão da versão exata que você executa.

kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- openssl version

Se essa versão for anterior à 3.5, pare aqui e planeje uma atualização do controller. Nenhuma chave de configuração consegue habilitar um grupo que a biblioteca não implementa.

Os nomes de grupos e os codepoints IANA que você pode usar legitimamente são publicados no registro de parâmetros TLS (iana.org):

• X25519MLKEM768 (0x11EC, 4588), o padrão de fato dos navegadores atualmente, descrito na nossa página sobre X25519MLKEM768.
• SecP256r1MLKEM768 (0x11EB, 4587) e SecP384r1MLKEM1024 (0x11ED, 4589), para ambientes que exigem curvas NIST.
• Grupos ML-KEM puros MLKEM512, MLKEM768 e MLKEM1024 (512, 513, 514). Eles não são híbridos: a maioria dos leitores ainda não deve implantá-los na borda pública.

O acordo de chaves híbrido para TLS 1.3 é especificado na RFC 10024 (rfc-editor.org). O próprio ML-KEM é o FIPS 203, final desde 13 de agosto de 2024 (csrc.nist.gov). O grupo pré-padrão do rascunho Kyber X25519Kyber768Draft00 (0x6399) está obsoleto: se ele aparecer em qualquer ponto da sua configuração, remova-o.

Etapa 3: configure os grupos, com fallback clássico

Apenas um grupo de troca de chaves é negociado por conexão, e o servidor escolhe entre os grupos oferecidos pelo cliente. Listar primeiro um grupo híbrido e depois um grupo clássico é, portanto, seguro por construção: os clientes que conhecem o grupo híbrido o utilizam, e os clientes mais antigos recorrem a X25519 ou P-256.

ingress-nginx

O controller expõe a chave de ConfigMap ssl-ecdh-curve, que corresponde à diretiva nginx ssl_ecdh_curve e é passada à biblioteca TLS como uma lista ordenada de grupos (seu valor padrão é auto). Confirme a chave na referência de ConfigMap da versão do controller que você executa e, em seguida, aplique:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  ssl-protocols: "TLSv1.3 TLSv1.2"
  ssl-ecdh-curve: "X25519MLKEM768:X25519:prime256v1"

Aqui, prime256v1 é o nome OpenSSL para secp256r1. Manter dois grupos clássicos após o híbrido preserva os clientes TLS 1.2 e qualquer cliente TLS 1.3 que não implemente ML-KEM. A mesma lógica de ordenação se aplica a um servidor web autônomo, conforme descrito no nosso guia para habilitar ML-KEM no nginx, Apache, HAProxy e Caddy.

Outros controllers e service meshes

Não copie anotações entre controllers. Uma anotação que o controller não reconhece é ignorada silenciosamente, e esse é o modo de falha mais perigoso aqui: o rollout parece bem-sucedido e nada mudou. O princípio é idêntico em todos os casos, o que muda é a interface:

• Data planes baseados em Envoy expõem parâmetros TLS que incluem uma lista de curvas ECDH. Em um mesh, esse campo geralmente é acessado por um mecanismo de patch avançado, e não por uma API de primeira classe, portanto consulte a documentação da sua versão de mesh e de proxy.
• Controllers baseados em HAProxy e Traefik definem a lista de grupos em seus próprios objetos de configuração. Procure a chave exata na documentação do controller para a sua versão e valide-a em staging.
• Se um load balancer gerenciado termina o TLS, sua única alavanca é a política de TLS do provedor. Quando nenhuma política híbrida é oferecida, a alternativa é mover a terminação para dentro do cluster, atrás de um serviço passthrough de camada 4, o que é uma mudança de arquitetura e merece uma revisão própria.

Não mexa na cadeia de certificados por enquanto

O tráfego gravado é protegido apenas pela troca de chaves, e esse é justamente o cerne do harvest now, decrypt later: um atacante que armazena texto cifrado hoje pode decifrá-lo mais tarde se a troca de chaves tiver sido clássica. Nosso artigo sobre harvest now, decrypt later explica por que a troca de chaves vem primeiro na fila. Os certificados podem migrar depois: as autoridades certificadoras públicas ainda emitem certificados ECDSA e RSA, e as assinaturas ML-DSA, padronizadas como FIPS 204, ainda não estão disponíveis de forma geral em cadeias TLS públicas. Mantenha o seu issuer cert-manager atual inalterado nesta fase.

Etapa 4: verifique a partir de fora do cluster

Teste a partir de uma máquina na internet pública, pelo mesmo caminho que um navegador percorre. Nunca verifique com kubectl port-forward: ele contorna o load balancer e a borda, e pode, portanto, exibir um handshake híbrido que nenhum cliente real jamais obterá. Com OpenSSL 3.5 ou posterior:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Um resultado bem-sucedido exibe o grupo negociado. Em seguida, comprove que o fallback continua funcionando, o teste que as equipes costumam esquecer:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Repita os dois testes para cada hostname público, incluindo o domínio apex e qualquer host atendido por uma segunda ingress class ou por um provedor de borda diferente. Um cluster com duas ingress classes frequentemente acaba migrado pela metade. O que um teste externo pode e não pode mostrar está descrito na nossa metodologia do scanner.

Etapa 5: faça o rollout e guarde as evidências

1. Aplique a mudança primeiro em staging, em um controller que execute a mesma tag de imagem da produção.
2. Promova para um único hostname de produção ou para uma ingress class canário, não para toda a frota.
3. Monitore os erros de handshake TLS e o uso de CPU do controller durante pelo menos um ciclo de negócio completo. As key shares ML-KEM são maiores que uma share X25519, portanto as mensagens ClientHello e ServerHello aumentam de tamanho.
4. Mantenha o rollback pronto: reverter a chave do ConfigMap para o valor anterior restaura o comportamento antigo no próximo reload.
5. Registre o resultado no seu inventário criptográfico, com a data e o host testado.

É nessa última etapa que uma mudança de plataforma se torna evidência de conformidade. O mapeamento abaixo é a nossa leitura de como o artefato técnico atende ao requisito, e não uma citação dos textos. Isto é informação, não aconselhamento jurídico.

Próximo passo

Depois que o ConfigMap estiver aplicado e os testes em staging passarem, confirme o resultado visível externamente: escaneie seu domínio com o PQC Status para ver qual grupo de troca de chaves o seu ingress realmente negocia, quais versões de TLS ele oferece e como é a cadeia de certificados. Execute o scan uma vez por hostname público, antes e depois de cada atualização da imagem do controller, porque uma mudança de imagem pode levá-lo silenciosamente de volta a um grupo clássico. Um scan descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade.