Kubernetes 1.37: Certificados de Pod e Cluster Trust Bundles Elevam Segurança no Core

A introdução de Pod Certificates no Kubernetes 1.37 é um marco significativo para a segurança de workloads. Até então, o principal mecanismo de identidade para pods eram os JWTs de service account. Embora funcionais e bem integrados, JWTs são tokens de portador, o que significa que se um token for comprometido, quem o possuir pode se passar pela workload. Esse é um risco inerente que mitigadores (como binding de tempo e audiência) apenas diminuíam, mas não eliminavam por completo.

Com os Pod Certificates, o Kubernetes adota um modelo de identidade baseado em credenciais de prova de posse, que utilizam certificados X.509 para TLS e mTLS. A workload gera uma chave privada localmente, sem nunca transmiti-la, e então solicita um certificado assinado por uma Certificate Authority (CA) que atesta sua identidade e chave pública. Esse modelo, amplamente adotado em outras áreas da segurança de rede, como a comunicação HTTPS, eleva a barra de segurança ao dificultar a personificação. O mecanismo de rotação automática dos certificados e a flexibilidade para diferentes tipos de provedores de certificado (como SPIFFE) tornam a solução robusta para ambientes de microsserviços.

A principal mudança é a transição de um mecanismo de identidade primário baseado em JWTs (tokens de portador) para um modelo focado em certificados X.509 (prova de posse). Anteriormente, a identidade de um pod era validada principalmente pelo JWT, que, se interceptado, poderia ser usado indevidamente. Agora, os Pod Certificates fornecem uma abordagem mais segura, onde a workload prova que possui uma chave privada sem nunca expô-la. Isso representa uma evolução fundamental na forma como as workloads no Kubernetes estabelecem confiança entre si e com outros sistemas, oferecendo uma fundação de segurança mais forte para as aplicações nativas da nuvem.

Para engenheiros de DevOps e de plataformas, esta novidade simplifica e fortalece a gestão de identidade e segurança de comunicação dentro do cluster. Gerenciar certificados em larga escala sempre foi um desafio operacional. Ao integrar a emissão e rotação de certificados X.509 diretamente no core do Kubernetes, a plataforma reduz a complexidade e a necessidade de soluções externas para mTLS entre serviços. Essa padronização permite uma adoção mais fácil de práticas de segurança como Zero Trust, onde cada workload é autenticada antes de interagir com outra.

Além disso, essa funcionalidade ressoa com a crescente demanda por maior segurança no ecossistema. O CEVIU noticiou em 3 de julho de 2026 que o Argo CD 3.5 introduziu mTLS interno para maior segurança em GitOps. A capacidade nativa do Kubernetes de emitir e gerenciar certificados para pods complementa essa tendência, fornecendo a base necessária para que ferramentas e aplicações nativas da nuvem fortaleçam suas próprias comunicações de maneira mais segura e eficiente.