HashiCorp lança beta público do Vault para gerenciar chaves no Kubernetes
Novo plugin permite que clusters Kubernetes usem o Vault Enterprise como provedor de KMS para criptografia em repouso, tirando as chaves de dentro do cluster.
A HashiCorp liberou o beta público do Vault Kubernetes key management, recurso que permite a clusters Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → 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↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → 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↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → 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
EncryptionConfigdo Kubernetes e o manifesto dokube-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
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
