Melhores ferramentas de gerenciamento de segredos do Kubernetes em 2026: Vault, ESO, Sealed Secrets e mais

Cada cluster Kubernetes vem com um objeto Secret integrado. Parece segurança. Parece segurança. Não é segurança.

Um segredo do Kubernetes é, por padrão, apenas uma string codificada em base64 armazenada no etcd - legível por qualquer pessoa com acesso ao cluster e trivialmente decodificável com uma linha: echo "c2VjcmV0" | base64 -d. A menos que você tenha habilitado explicitamente a criptografia em repouso (e a maioria das equipes não o fez), as senhas do banco de dados, os tokens de API e as chaves privadas TLS permanecem sem criptografia no armazenamento de dados do plano de controle do cluster. Envie um manifesto do Kubernetes contendo um Segredo para o Git, e essa credencial permanecerá no histórico do seu repositório para sempre.

Este é o problema que uma nova geração de ferramentas de gestão de segredos surgiu para resolver — e em 2026, o ecossistema amadureceu significativamente. Este guia aborda as seis ferramentas mais importantes para gerenciar segredos em ambientes Kubernetes: o que fazem, o que não fazem e qual delas se adapta ao nível de maturidade da sua equipe.

Leitura relacionada: Se você estiver preocupado com o vazamento de segredos em seu pipeline de CI/CD, consulte nosso resumo das melhores ferramentas de pipeline de CI/CD. Para uma visão mais ampla da segurança de contêineres, confira nosso guia de ferramentas de verificação de vulnerabilidades.

Por que os segredos padrão do Kubernetes são insuficientes

Antes de mergulhar nas ferramentas, vale a pena ser preciso sobre o que falta aos segredos do Kubernetes – porque entender a lacuna é o que permite escolher a solução certa.

Sem criptografia em repouso por padrão. O etcd armazena segredos do Kubernetes como base64, não criptografados. Ativar a criptografia em repouso é uma etapa de configuração em nível de cluster que os provedores gerenciados do Kubernetes (EKS, GKE, AKE) tratam de maneira diferente, e muitos clusters autogerenciados a ignoram completamente.

Sem rotação de segredo. Não há mecanismo integrado para um segredo do Kubernetes saber que sua credencial de apoio foi alterada. Você alterna uma senha de banco de dados externamente e seus pods continuam usando a senha antiga até que você atualize manualmente o segredo e reinicie os pods afetados.

Nenhum log de auditoria para acesso secreto. Registros de log de auditoria padrão do Kubernetes Modificações de objetos secretos, mas a maioria das configurações não registra leituras individuais - o que significa que você não pode responder “qual serviço acessou esse token e quando?”

Git-hostil por design. O conselho padrão é “nunca submeter segredos ao Git”. Mas em um mundo GitOps onde tudo como código é o objetivo, essa é uma exceção dolorosa de manter.

RBAC como um instrumento contundente. O RBAC do Kubernetes permite conceder ou negar acesso a objetos secretos no nível do namespace. Ele não pode expressar “O serviço A pode ler o segredo X, mas não o segredo Y” ou “este segredo expira em 24 horas”.

Nenhum desses são motivos para abandonar o Kubernetes – são motivos para usar ferramentas dedicadas de gerenciamento de segredos.

TL;DR — Comparação de recursos

⚠️ = requer componentes adicionais

1. HashiCorp Vault – O padrão ouro para segredos empresariais

HashiCorp Vault é a referência pela qual todas as outras ferramentas de gerenciamento de segredos são avaliadas. Ele foi testado em ambientes corporativos por quase uma década e seu conjunto de recursos reflete essa profundidade.

O recurso principal do Vault são segredos dinâmicos: credenciais que são geradas sob demanda e expiram automaticamente. Em vez de armazenar uma senha estática do PostgreSQL, o Vault gera um par de nome de usuário/senha exclusivo para cada serviço solicitante, válido por um período de concessão configurável (por exemplo, uma hora). Quando o arrendamento expira, a credencial é revogada. Isso elimina classes inteiras de expansão de credenciais e facilita drasticamente a contenção de violações.

Para Kubernetes, o Vault Agent Injector ou o Vault Secrets Operator são os caminhos de integração. O injetor é executado como um webhook mutante que transfere automaticamente um agente do Vault para seus pods, que se autentica no Vault usando a conta de serviço Kubernetes do pod e grava segredos em um volume compartilhado na memória. O Vault Secrets Operator (VSO), a abordagem mais recente, sincroniza os segredos do Vault em objetos secretos nativos do Kubernetes – mais familiares aos operadores, ao custo de segredos existentes brevemente no etcd.

Os mecanismos secretos do Vault cobrem uma gama impressionante:

• Credenciais de banco de dados (PostgreSQL, MySQL, MongoDB e mais)
• Credenciais dinâmicas AWS, GCP, Azure
• Geração de certificados PKI e TLS
• Assinatura de certificado SSH
• Tokens de conta de serviço Kubernetes

O que o Vault faz bem: Credenciais dinâmicas, políticas de acesso refinadas, um registro de auditoria abrangente e um ecossistema de plug-ins maduro. Se você precisa de gerenciamento de segredos de nível de conformidade com rastreamento completo de quem acessou e quando, o Vault geralmente é a única opção razoável.

O que observar: O Vault tem complexidade operacional. Executá-lo no modo de alta disponibilidade requer atenção cuidadosa aos back-ends de armazenamento (Raft agora é a escolha recomendada), procedimentos de abertura e caminhos de atualização. A curva de aprendizado é real. Orçamento para tempo de engenharia de plataforma.

Preço: A versão de código aberto é gratuita e cobre a maioria das necessidades. HashiCorp Cloud Platform (HCP) Vault é a oferta gerenciada com preços baseados em horas de cluster e operações secretas. A mudança de licença BSL de 2023 levou ao fork OpenTofu para Terraform, mas o fork equivalente do Vault (OpenBao) ainda está amadurecendo.

📚 Leitura recomendada: Hacking Kubernetes por Andrew Martin e Michael Hausenblas — excelente cobertura de superfícies de ataque do Kubernetes, incluindo cenários de exfiltração secreta.

2. Operador de segredos externos (ESO) - A camada de integração nativa K8s

Operador de segredos externos adota uma postura arquitetônica fundamentalmente diferente: em vez de ser um armazenamento de segredos em si, é uma ponte entre o Kubernetes e qualquer armazenamento externo que você já tenha. O ESO sincroniza segredos do AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler e uma lista crescente de outros back-ends em objetos secretos nativos do Kubernetes.

A abstração principal é o recurso personalizado ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

O ESO monitora esse recurso, busca o segredo do AWS Secrets Manager (ou qualquer outro lugar) e cria um segredo padrão do Kubernetes. Seu aplicativo lê db-creds como qualquer outro segredo do Kubernetes - nenhuma alteração de código é necessária. Quando refreshInterval marca, o ESO busca novamente e atualiza o segredo automaticamente.

Por que o ESO é tão popular em 2026: Funciona bem com os investimentos existentes. Sua organização já possui AWS Secrets Manager (ou Vault, ou GCP Secret Manager) – o ESO apenas torna esses segredos consumíveis no Kubernetes sem alterar o código do aplicativo ou os fluxos de trabalho de rotação de segredos existentes.

ESO ou operador de segredos do Vault? Se você estiver executando o Vault, o VSO terá uma integração específica mais estreita do Vault (segredos dinâmicos do Vault, Vault PKI). Se você estiver no armazenamento secreto nativo de um provedor de nuvem, o ESO é a escolha mais limpa. Muitas equipes executam ambos – ESO para segredos estáticos armazenados na nuvem, VSO para credenciais dinâmicas gerenciadas pelo Vault.

Preço: ESO é gratuito e de código aberto (Apache 2.0), mantido por um projeto sandbox CNCF com forte apoio da comunidade.

3. Segredos selados – segredos criptografados compatíveis com GitOps

Segredos Selados da Bitnami resolve um problema específico: como você armazena manifestos secretos do Kubernetes no Git sem armazenar o texto simples real? A resposta é a criptografia assimétrica.

O controlador Sealed Secrets é executado em seu cluster e contém uma chave privada. A CLI kubeseal criptografa um manifesto secreto do Kubernetes com a chave pública do cluster, produzindo um CRD SealedSecret. Este manifesto criptografado pode ser confirmado no Git com segurança — apenas a chave privada do cluster pode descriptografá-lo, e ele só pode ser descriptografado nesse cluster específico (por padrão, o texto cifrado está vinculado ao namespace + nome).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Quando você aplica o SealedSecret ao cluster, o controlador o descriptografa e cria o objeto Secret correspondente.

O que o Sealed Secrets faz bem: Fluxos de trabalho GitOps. Se você estiver usando Argo CD ou Flux e quiser que todos os recursos do cluster (incluindo segredos) sejam armazenados declarativamente no Git, o Sealed Secrets se encaixa perfeitamente nesse modelo. Não requer nenhuma dependência externa além do controlador no cluster.

O que ele não faz: Rotação, credenciais dinâmicas ou registro de auditoria além dos eventos padrão do Kubernetes. Sealed Secrets é uma solução de armazenamento Git, não uma plataforma completa de gerenciamento de segredos. Se sua senha for alterada, você criptografa novamente e confirma novamente.

O backup da chave privada é fundamental. Se você perder a chave privada do controlador, perderá a capacidade de descriptografar seus segredos lacrados. Faça backup do segredo sealed-secrets-key em um local separado e seguro.

Preço: Totalmente gratuito e de código aberto (Apache 2.0).

4. AWS Secrets Manager com Kubernetes

Se suas cargas de trabalho são executadas principalmente no EKS (ou se conectam fortemente aos serviços da AWS), o AWS Secrets Manager emparelhado com o Driver CSI do Secrets Store ou o Operador de segredos externos é uma opção natural. Você mantém segredos no armazenamento gerenciado, criptografado e registrado por auditoria da AWS e os transfere para o Kubernetes quando necessário.

O Driver CSI do Armazenamento de Segredos (SSCSID) é a abordagem mantida pelo CNCF: os segredos são montados diretamente em pods como arquivos por meio de um volume CSI, nunca gravados no etcd como objetos secretos do Kubernetes. Este é o caminho de maior segurança – os segredos existem na memória do pod, mas não no armazenamento secreto do Kubernetes.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Os recursos nativos do AWS Secrets Manager incluem rotação automática para serviços suportados (RDS, Redshift, DocumentDB e via Lambda para rotação personalizada), acesso entre contas e integração profunda do CloudTrail para trilhas de auditoria de conformidade.

**Consideração de custo:**O AWS Secrets Manager cobra por segredo, por mês e por chamada de API. Para grandes frotas com muitos pequenos segredos, os custos podem aumentar. Consulte nosso guia de otimização de custos de nuvem para conhecer estratégias de gerenciamento de gastos da AWS relacionados a segredos.

Ideal para: equipes nativas de EKS que já investiram no ecossistema AWS e que desejam integração estreita de IAM e rotação de credenciais nativas de RDS.

5. Doppler – Plataforma de segredos SaaS que prioriza o desenvolvedor

Doppler adota uma abordagem SaaS que prioriza a experiência do desenvolvedor em vez da complexidade operacional. Você define segredos na UI do Doppler (ou via CLI/API), organiza-os por ambiente (desenvolvimento, preparação, produção) e o operador Doppler Kubernetes os sincroniza automaticamente com os segredos do Kubernetes.

O operador pesquisa o Doppler em busca de alterações e atualiza o segredo do Kubernetes correspondente, acionando opcionalmente reinicializações do pod quando os segredos mudam. A configuração é uma instalação única do gráfico Helm:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Onde o Doppler brilha: Desenvolvimento local e integração de CI/CD junto com o Kubernetes. A CLI do Doppler substitui totalmente os arquivos de ambiente (doppler run -- your-command), fornecendo os mesmos segredos em ambientes locais, de CI e de produção. Para pipelines de CI/CD, as integrações nativas do Doppler com GitHub Actions, CircleCI e outros eliminam a necessidade de copiar segredos em variáveis ​​de ambiente de pipeline.

O que o Doppler não cobre: Credenciais de banco de dados dinâmicos. Doppler é um armazenamento estático de segredos com histórico de versão e registro de auditoria — não é um mecanismo de geração de segredos como o Vault.

Preço: O Doppler oferece um nível gratuito para equipes pequenas. Os planos pagos adicionam SSO, solicitações de acesso e recursos de conformidade. Verifique a página de preços da Doppler para os níveis atuais (alterações de preços; verifique antes de fazer o orçamento).

6. Infisical – Alternativa de cofre de código aberto

Infisical é o mais forte desafiante de código aberto ao duopólio Vault/Doppler. Ele fornece uma UI da web, CLI, SDKs e um operador Kubernetes – auto-hospedado implantável ou consumido como um serviço em nuvem.

Infisical adicionou suporte a segredos dinâmicos em 2024, visando a geração de credenciais de banco de dados semelhante ao mecanismo de segredos de banco de dados do Vault. O operador Infisical Kubernetes sincroniza CRDs InfisicalSecret com segredos nativos do Kubernetes, com intervalos de atualização configuráveis.

Para equipes que desejam UX em nível de SaaS (painel da web, fluxos de trabalho de solicitação de acesso, registros de auditoria), mas não podem usar SaaS externo devido a requisitos de conformidade, o Infisical auto-hospedado é atraente. É significativamente mais fácil de operar do que o Vault e oferece uma experiência de integração mais amigável ao desenvolvedor.

Preço: O núcleo de código aberto é gratuito. A versão hospedada na nuvem possui um nível gratuito e planos pagos para recursos avançados. A licença empresarial auto-hospedada está disponível para ambientes com muita conformidade.

📚 Para um mergulho mais profundo na arquitetura de segurança do Kubernetes: Kubernetes Security and Observability na Amazon cobre segredos, RBAC, política de rede e segurança de tempo de execução em uma estrutura coesa.

Dicas de implementação

Comece com a criptografia em repouso. Antes de adicionar qualquer ferramenta adicional, ative a criptografia em repouso do Kubernetes etcd. Para clusters gerenciados, geralmente é uma única caixa de seleção. Para clusters autogerenciados, siga o guia oficial. Isso aumenta imediatamente sua postura básica de segurança.

Adote RBAC de privilégio mínimo para segredos. Audite quais contas de serviço têm permissões get, list ou watch em objetos secretos. As contas de serviço padrão em muitos gráficos do Helm estão superprovisionadas. Aperte o RBAC antes de encaminhá-lo para um armazenamento externo.

Planeje suas convenções de nomenclatura secreta com antecedência. Os segredos proliferam rapidamente. Uma hierarquia consistente ({env}/{service}/{credential-type}) torna a automação, as políticas RBAC e os fluxos de trabalho de rotação muito mais simples em todas as ferramentas.

Não pule o teste de rotação secreto. Seja qual for a ferramenta que você escolher, execute um exercício de rotação antes de precisar dela. Verifique se seu aplicativo obtém novas credenciais sem tempo de inatividade. Os segredos dinâmicos com Vault ou ESO tornam isso significativamente mais fácil do que os segredos estáticos atualizados manualmente.

Monitore a expansão de segredos. À medida que sua plataforma cresce, os segredos se acumulam. Integre relatórios de gerenciamento de segredos aos painéis de engenharia da sua plataforma. Consulte nosso guia de ferramentas de monitoramento do Kubernetes para ferramentas de observabilidade que podem rastrear padrões de acesso secreto.

Qual ferramenta para qual equipe?

Equipe pequena, nativa da nuvem (AWS/GCP/Azure): Comece com o operador de segredos externos conectando-se ao armazenamento secreto nativo do seu provedor de nuvem. Sobrecarga operacional mínima, integração sólida de auditoria, gratuita.

Equipe GitOps-first (Argo CD / Flux): Segredos selados para configuração armazenada em GitOps, combinados com ESO para credenciais de tempo de execução confidenciais que não deveriam estar no Git, mesmo criptografadas.

Empresa com requisitos de conformidade (SOC 2, PCI, HIPAA): HashiCorp Vault — cluster Raft auto-hospedado ou gerenciado pelo HCP Vault. O log de auditoria, as credenciais dinâmicas e o mecanismo de política refinado são difíceis de replicar em outro lugar.

Ambiente misto focado na experiência do desenvolvedor (K8s + local + CI/CD): Doppler para DX unificado em todos os ambientes ou Infisical auto-hospedado se a residência dos dados for importante.

Grande equipe de plataforma gerenciando ambientes com vários clusters: Operador de segredos externos como a camada de abstração do lado K8s, apoiado pelo Vault ou por um armazenamento nativo da nuvem. Centralizar a fonte da verdade em um único armazenamento e ao mesmo tempo usar o ESO como um adaptador universal entre clusters é um padrão comprovado em 2026.

Relacionado: Para saber mais sobre os riscos de segurança introduzidos pelas ferramentas de codificação de IA em seus manifestos do Kubernetes e pipelines de CI/CD, consulte nosso guia sobre riscos de segurança de codificação do Vibe em 2026.

PERGUNTAS FREQUENTES

Os segredos do Kubernetes são criptografados por padrão?

Os segredos do Kubernetes são codificados em base64 por padrão – codificação, não criptografia. Os dados são armazenados no etcd sem criptografia, a menos que você habilite explicitamente a criptografia em repouso. Verifique sempre a configuração do cluster e considere ferramentas externas de gestão de segredos para cargas de trabalho de produção.

Qual é a diferença entre Segredos Selados e Operador de Segredos Externos?

Sealed Secrets criptografa manifestos secretos para armazenamento seguro do Git — é uma solução GitOps. O operador de segredos externos busca segredos ativos de armazenamentos externos (Vault, AWS Secrets Manager, etc.) e cria segredos nativos do Kubernetes a partir deles. Eles resolvem problemas diferentes e costumam ser usados ​​juntos.

O que são segredos dinâmicos e por que eles são importantes?

Segredos dinâmicos são credenciais geradas sob demanda com expiração automática — em vez de senhas estáticas armazenadas indefinidamente. HashiCorp Vault é a principal fonte de segredos dinâmicos para Kubernetes. Se uma credencial dinâmica for comprometida, ela expirará de acordo com sua própria programação. Isso limita drasticamente o raio de explosão da violação em comparação com segredos estáticos de longa duração.

Devo usar Doppler ou HashiCorp Vault para Kubernetes?

O Doppler vence na experiência do desenvolvedor e na rápida adoção. O Vault vence em termos de conformidade empresarial: credenciais dinâmicas, registros de auditoria granulares e políticas refinadas. Para equipes de pequeno e médio porte, o Doppler costuma ser o caminho mais rápido. Para ambientes SOC 2, PCI DSS ou HIPAA, o Vault normalmente é a escolha mais defensável.

Como evito que segredos vazem nos logs do contêiner?

Monte segredos como arquivos em vez de variáveis ​​de ambiente (variáveis ​​de ambiente podem ser expostas por meio de /proc e pontos de extremidade de depuração). Use o driver CSI do Secrets Store para ignorar totalmente o etcd. Verifique se há commits secretos acidentais em seu pipeline de CI/CD com ferramentas como o scanner secreto do Trivy. Consulte nosso guia de ferramentas de verificação de vulnerabilidades para obter detalhes de configuração.

Qual é a melhor ferramenta de gerenciamento de segredos para uma pequena equipe do Kubernetes?

Comece com o External Secrets Operator apoiado pelo armazenamento secreto nativo do seu provedor de nuvem. Sobrecarga mínima de operações, registro de auditoria sólido e gratuito. Adicione o nível gratuito do Doppler se você também quiser uma experiência unificada de segredos de desenvolvimento/CI/produção.

Como faço para integrar o AWS Secrets Manager ao Kubernetes?

Use o operador de segredos externos com um ClusterSecretStore apontando para AWS Secrets Manager. No EKS, use IRSA (IAM Roles for Service Accounts) para autenticação IAM em nível de pod – sem necessidade de credenciais estáticas. Em clusters não EKS, use um usuário IAM com secretsmanager:GetSecretValue com escopo definido para seus ARNs secretos específicos.