HashiCorp lança beta público do Vault para gerenciar chaves no Kubernetes

A HashiCorp liberou o beta público do Vault Kubernetes key management, recurso que permite a clusters Kubernetes usarem o Vault Enterprise como provedor de KMS para criptografia em repouso. O anúncio foi feito em 10 de julho, segundo reportou o InfoQ.

A entrega vem na forma de um plugin compatível com a KMS v2 chamado vault-kube-kms. Ele permite que o API server do Kubernetes delegue a criptografia por envelope ao Vault, protegendo os Secrets e outros recursos da API armazenados no etcd, e movendo para fora do cluster as chaves que guardam esses dados.

O problema não é criptografar, é onde ficam as chaves

O ponto central levantado pela HashiCorp não é se o Kubernetes consegue criptografar dados em repouso (ele consegue), mas onde vivem as chaves por trás dessa criptografia. Escrevendo no blog da empresa, Rich DuBose e Steve Almy argumentam que, se o mesmo ambiente que armazena dados sensíveis também controla as chaves usadas para protegê-los, "a fronteira de confiança permanece estreita demais". Isso deixa times de plataforma sem boas respostas sobre onde as chaves de criptografia de chaves estão guardadas, quem consegue acessá-las, como são rotacionadas e como o uso é auditado.

Como funciona a divisão de responsabilidades

O plugin mantém o esquema padrão de criptografia por envelope. O Kubernetes continua gerando e usando data encryption keys (DEKs) para criptografar dados antes de gravá-los no etcd, preservando a vazão que o API server espera. A semente da DEK é protegida por key encryption keys (KEKs) guardadas no Vault, onde o transit secrets engine executa as operações criptográficas. O dado criptografado e a DEK criptografada ficam juntos no etcd. Sem um Vault acessível e corretamente configurado, esses dados não podem ser decifrados.

Essa separação é o benefício prático para times regulados: o Kubernetes lida com o alto volume de chamadas de criptografia e descriptografia, enquanto o Vault fica dono do ciclo de vida das chaves, rotação, aplicação de políticas e auditoria. A documentação lista gerenciamento centralizado com RBAC, fluxos de rotação que preservam a capacidade de decifrar dados existentes, e visibilidade sobre uso, latência e erros via logs de auditoria e métricas do plugin. Não é preciso alterar código de aplicação.

Cenários de uso e o contexto brasileiro

A HashiCorp aponta como cenários principais plataformas Kubernetes corporativas como o Red Hat OpenShift, ambientes multi-cluster em produção, ambientes regulados que exigem segregação de funções e programas de zero trust. A empresa enquadra o gerenciamento de chaves cada vez mais como um problema de identidade de máquina: aplicações, containers, pipelines de CI/CD, automação de infraestrutura e agentes de IA precisam de acesso contínuo a recursos sensíveis sem intervenção humana.

Para quem constrói software no Brasil, o tema conversa direto com exigências de conformidade como a LGPD e com auditorias em setores regulados (financeiro, saúde), onde comprovar onde as chaves ficam e como são acessadas costuma virar dor de cabeça em revisões de segurança. Ter um caminho suportado pelo fornecedor, para times já padronizados em Vault Enterprise, tende a reduzir atrito nessas conversas.

O terreno não é totalmente novo. Plataformas gerenciadas já oferecem integrações parecidas há algum tempo, como o Azure Key Vault KMS para AKS, e projetos de comunidade como o vault-kubernetes-kms preenchiam a lacuna em clusters autogerenciados. A diferença aqui é o caminho oficialmente suportado pela HashiCorp, com suporte testado nas versões menores recentes do Kubernetes.

Restrições para quem for avaliar

Alguns limites merecem atenção no beta:

• Vault Enterprise apenas: não vale para as edições gratuitas.
• Acesso ao control plane: a implantação exige modificar o EncryptionConfig do Kubernetes e o manifesto do kube-apiserver, o que descarta a maioria dos control planes totalmente gerenciados.
• Disponibilidade do Vault: como o provedor de KMS fica no caminho de descriptografar os dados do cluster, é preciso planejar a alta disponibilidade do Vault, sob risco de indisponibilidade dos dados.

A HashiCorp descreve o beta como um primeiro passo rumo ao gerenciamento centralizado de chaves para criptografia no Kubernetes em escala, e convida times de engenharia de plataforma e segurança a avaliar e enviar feedback.

Fonte: InfoQ