Vault: gerenciamento profissional de segredos com HashiCorp

O que é Vault e por que foi criado

O problema que o HashiCorp Vault resolve em ambientes de produção complexos

O HashiCorp Vault nasceu da observação de que sistemas complexos precisam de uma solução centralizada para gerenciar segredos que seja auditável, segura em repouso, controlável e capaz de emitir credenciais efêmeras. Antes do Vault, equipes gerenciavam credenciais em arquivos de configuração, scripts de deploy ad hoc, variáveis de ambiente sem auditoria e planilhas compartilhadas — cada uma dessas abordagens criando vetores de ataque e dificultando a resposta a incidentes. O Vault resolve isso fornecendo uma API unificada para armazenar segredos estáticos, gerar credenciais dinâmicas para bancos de dados e serviços de nuvem, emitir certificados TLS e controlar acesso com políticas em Hashicorp Configuration Language (HCL). Toda operação no Vault é registrada em audit logs imutáveis, criando rastreabilidade completa de quem acessou qual segredo quando e de onde.

Secrets engines — onde os dados são armazenados

Os diferentes backends que permitem ao Vault gerenciar tipos variados de segredos

Secrets engines são os plugins do Vault responsáveis por armazenar, gerar ou criptografar dados, com diferentes engines especializados para diferentes casos de uso. O engine KV (Key-Value) versão 2 é o mais básico, armazenando pares chave-valor com versionamento automático que permite recuperar versões anteriores de um segredo após rotação. O engine Database gera credenciais dinâmicas para PostgreSQL, MySQL, MongoDB, Redis e outros bancos, criando usuários temporários on-demand com permissões específicas e TTL configurado. O engine AWS gera credenciais IAM temporárias assumindo roles ou criando access keys dinâmicas com políticas limitadas, e o engine Azure oferece funcionalidade similar para o ambiente Microsoft. O engine Transit oferece criptografia como serviço, permitindo que aplicações criptografem dados sem nunca ter acesso à chave de criptografia subjacente.

Dynamic secrets — credenciais geradas on-demand

O modelo mais seguro de credenciais: nascem e morrem com a necessidade

Dynamic secrets são a funcionalidade mais poderosa do Vault, gerando credenciais únicas para cada aplicação ou mesmo cada requisição, com TTL configurado após o qual a credencial é automaticamente revogada no sistema de destino. Para bancos de dados, o Vault cria um usuário temporário com apenas as permissões necessárias para aquela aplicação, revogando-o após o TTL ou quando a aplicação faz checkout sem renovação. Isso significa que mesmo que uma credencial seja roubada de um container comprometido, ela expira em minutos ou horas sem ação manual necessária. A revogação em lease é outra vantagem: ao detectar um incidente, um operador pode revogar todos os leases de uma aplicação específica com um único comando, invalidando imediatamente todas as credenciais emitidas para aquele contexto sem afetar outros sistemas.

Auth methods — como aplicações se autenticam no Vault

Diferentes mecanismos para que aplicações provem sua identidade ao Vault

O Vault suporta múltiplos métodos de autenticação que permitem que diferentes tipos de clientes provem sua identidade antes de receber permissão para acessar segredos. O auth method AppRole é projetado para aplicações e automação, usando um role ID público e um secret ID rotativo para obter um token Vault com políticas específicas e TTL limitado. O auth method Kubernetes permite que pods se autentiquem usando seus Service Account tokens, que o Vault valida contra a API do Kubernetes, eliminando qualquer credencial estática no pod. Auth methods para AWS, GCP e Azure validam identidade de instâncias de nuvem usando metadados da plataforma, permitindo que máquinas virtuais e lambdas se autentiquem sem credenciais hardcoded. OIDC e JWT auth methods integram o Vault com provedores de identidade corporativos como Okta e Azure AD para autenticação humana com SSO.

Policies — controle de acesso granular

Definindo o que cada identidade pode fazer dentro do Vault

Policies no Vault são documentos HCL que definem quais paths de API um token pode acessar e com quais capabilities (create, read, update, delete, list, sudo). A granularidade é no nível do path individual do Vault, permitindo que uma aplicação de produção tenha acesso apenas ao caminho secret/prod/app-name/database e nenhum outro segredo no sistema. Policies são associadas a tokens no momento da autenticação via auth methods, e um token pode ter múltiplas policies cujas permissões são combinadas por union. O princípio de menor privilégio deve guiar a criação de policies: cada aplicação recebe apenas os paths e capabilities estritamente necessários para sua função, com revisão periódica para remover permissões obsoletas. O Vault Enterprise adiciona Sentinel policies, que são regras de segunda camada usando lógica de programação para condições mais complexas como horário de acesso ou atributos do requester.

PKI engine — emitindo certificados TLS

Infraestrutura de chave pública gerenciada e automatizada pelo Vault

O PKI engine do Vault permite criar e gerenciar uma Certificate Authority (CA) interna completa, emitindo certificados TLS para serviços internos com TTLs muito mais curtos que os convencionais de 1-2 anos. Certificados de vida curta emitidos pelo Vault — tipicamente de horas a dias — eliminam a necessidade de listas de revogação (CRL) pois certificados expiram antes de qualquer resposta a incidente, e qualquer serviço com certificado comprometido fica automaticamente inoperante após o TTL. Ferramentas como cert-manager no Kubernetes integram-se ao PKI engine do Vault para renovar automaticamente certificados antes do vencimento, tornando o gerenciamento de TLS interno completamente automatizado. CA chains intermediárias permitem separar a root CA (offline e altamente protegida) de CAs intermediárias usadas para emissão, seguindo boas práticas de PKI enterprise.

Vault Agent — injeção automática de secrets

Mantendo configurações e segredos atualizados sem modificar a aplicação

Vault Agent é um daemon que corre ao lado da aplicação, autentica-se automaticamente no Vault, obtém segredos e os injeta como variáveis de ambiente ou arquivos de configuração que a aplicação pode consumir sem modificações em seu código. O modelo de template do Vault Agent usa sintaxe similar ao Consul Template para renderizar arquivos de configuração com valores dos segredos, permitindo que aplicações legadas que leem arquivos .conf ou .properties também se beneficiem do Vault. A renovação automática de leases e a re-renderização de templates quando segredos expiram garantem que a aplicação sempre tem credenciais válidas sem restart manual. Em ambientes Kubernetes, o Vault Agent Injector adiciona automaticamente um sidecar container de Vault Agent a pods anotados com metadata específico, sem necessidade de modificar o deployment da aplicação.

Vault em Kubernetes com annotations

Injeção transparente de secrets em pods usando o Vault Agent Injector

O Vault Agent Injector é um mutating webhook que intercepta criação de pods com annotations vault.hashicorp.com/agent-inject: 'true' e adiciona automaticamente um init container e um sidecar de Vault Agent ao pod. Annotations como vault.hashicorp.com/role definem qual role do Vault usar para autenticação Kubernetes, e vault.hashicorp.com/agent-inject-secret-config.txt especifica qual secret buscar e em qual arquivo armazenar dentro do pod. A aplicação consome os segredos como arquivos regulares montados em /vault/secrets/, tornando a integração completamente transparente para o código da aplicação. Essa abordagem elimina a necessidade de gerenciar Kubernetes Secrets para segredos de aplicação, mantendo a fonte da verdade no Vault com todas as suas capacidades de auditoria, rotação e controle de acesso.

HA e disaster recovery no Vault

Garantindo disponibilidade do Vault em produção sem ponto único de falha

O Vault em modo HA usa um storage backend distribuído como Consul, etcd ou Integrated Storage (Raft) para replicar o estado entre múltiplos nós, com um nó ativo e os demais em standby que assumem automaticamente caso o nó ativo falhe. O Integrated Storage baseado em Raft é a opção recomendada para novos deployments por eliminar a dependência de Consul, usando o algoritmo Raft para consensus entre os nós do cluster. Unsealing é um processo crítico no Vault: após um restart ou failover, o Vault começa sealed e precisa de um número mínimo de key shares (threshold de Shamir) para derivar a master key e descriptografar o storage. O Vault Enterprise adiciona replication cross-datacenter para DR (Disaster Recovery), permitindo promover um cluster secundário em caso de perda total do cluster primário. Auto-unseal com AWS KMS ou Azure Key Vault permite que o Vault seja unsealado automaticamente após restart sem intervenção humana, essencial em ambientes com escala ou auto-scaling.

Conclusão — Vault como plataforma de segurança centralizada

Unificando secrets, certificados e políticas em uma única plataforma auditável

O HashiCorp Vault representa o estado da arte em gerenciamento de secrets para sistemas em produção, combinando armazenamento seguro, credenciais dinâmicas, PKI gerenciado e controle de acesso granular em uma plataforma única com auditoria completa. A adoção do Vault é um investimento de curva de aprendizado não trivial, mas que elimina categorias inteiras de riscos de segurança operacional que nenhuma outra solução aborda de forma tão abrangente. Continue em: Fundamentos obrigatórios antes de produção.