Secrets Management — Vault, KMS e rotação automática

Em 2022, a empresa de autenticação Okta sofreu um breach via um contratado terceirizado cujo laptop foi comprometido. Em 2023, a CircleCI notificou seus clientes que segredos armazenados em seus pipelines de CI/CD haviam sido expostos após comprometimento de um token de funcionário. Em 2024, a Microsoft divulgou que tokens de autenticação de desenvolvimento foram expostos inadvertidamente. O padrão em todos esses incidentes é o mesmo: segredos que deveriam estar em storage seguro com acesso auditado estavam em lugares onde o controle era insuficiente — laptops, arquivos de configuração, variáveis de ambiente sem restrição de acesso.

Secrets management é a disciplina de armazenar, distribuir, rodar e auditar credenciais — chaves de API, senhas de banco de dados, certificados, tokens OAuth — de forma que o acesso seja mínimo, auditado, e temporário. É uma área onde a distância entre o que times sabem que deveriam fazer e o que realmente fazem é grande: todo desenvolvedor sabe que "não committar segredos no repositório" é regra básica, mas pesquisas da GitGuardian consistentemente encontram centenas de milhares de segredos hardcoded em repositórios públicos no GitHub.

O espectro de insegurança — de hardcoded a dynamic secrets

Os diferentes níveis de maturidade de secrets management podem ser visualizados como um espectro, do menos ao mais seguro:

1. Hardcoded no código-fonte: o pior cenário. A senha do banco está na string de conexão no código. Aparece em git history para sempre, mesmo após remoção (git log ainda mostra o commit). Qualquer pessoa com acesso ao repositório tem o segredo.
2. Em arquivos de configuração não versionados: o arquivo config.prod.json com as senhas está em .gitignore. Melhor que hardcoded, mas o arquivo existe no disco de todo desenvolvedor que precisou rodar o sistema — e provavelmente em backups não controlados.
3. Em variáveis de ambiente "simples": o segredo está em .env ou passado como variável de ambiente no deploy. Melhor que arquivo — mas o .env frequentemente acaba no repositório, em logs quando o processo imprime o ambiente, em dumps de crash, e em docker inspect que mostra variáveis de ambiente de containers.
4. Em secrets manager (AWS SM, GCP SM, Azure Key Vault): segredos armazenados centralmente com controle de acesso (IAM), rotação gerenciada, e audit log de cada acesso. A aplicação busca o segredo no startup e o usa. Muito melhor — o segredo não fica em nenhum artefato de deploy.
5. Dynamic secrets (HashiCorp Vault): a aplicação solicita credenciais ao Vault no momento de uso; o Vault gera credenciais temporárias com lease de horas; quando o lease expira, as credenciais são revogadas automaticamente. Nenhuma credencial de longa duração existe em nenhum lugar.

HashiCorp Vault — o secrets manager de referência

HashiCorp Vault é o sistema de secrets management open source mais adotado, com suporte a dezenas de tipos de segredo, múltiplos backends de autenticação (AppRole, AWS IAM, Kubernetes, LDAP, GitHub), e a funcionalidade de dynamic secrets que o diferencia de outros sistemas.

Dynamic secrets é o conceito central do Vault: em vez de armazenar senhas estáticas de banco de dados, o Vault se conecta ao banco e gera um usuário e senha exclusivos para cada solicitação, com lease de tempo limitado. Quando a aplicação solicita credenciais para o PostgreSQL, o Vault cria um usuário como v-appname-k8s-1234567890 com a senha gerada, concede as permissões necessárias, e retorna as credenciais com um lease de 1 hora. Quando o lease expira (ou é revogado explicitamente), o Vault revoga as credenciais no PostgreSQL — o usuário temporário é deletado. Nunca há uma senha de banco estática que possa ser roubada.

# Configurando Vault secrets engine para PostgreSQL
vault secrets enable database

vault write database/config/postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-role" \
  connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/mydb" \
  username="vault-admin" \
  password="vault-admin-password"

vault write database/roles/app-role \
  db_name=postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
    VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT, UPDATE ON ALL TABLES \
    IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# Aplicação solicita credenciais
vault read database/creds/app-role
# Key                Value
# ---                -----
# lease_id           database/creds/app-role/ABC123
# lease_duration     1h
# username           v-appname-k8s-1234567890
# password           A1b2C3d4E5f6G7h8

Para autenticação da aplicação ao Vault em Kubernetes, o Kubernetes auth method é o padrão: o pod apresenta seu service account token ao Vault; o Vault verifica com a Kubernetes API que o service account tem permissão para solicitar aquele role. Nenhum segredo estático (como um AppRole secret_id) precisa ser injetado no pod — a identidade do pod (service account) é suficiente.

# Vault Agent Sidecar — injeta segredos como arquivos no pod
# Anotações no pod spec
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "app-role"
  vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/app-role"
  vault.hashicorp.com/agent-inject-template-db-creds: |
    {{- with secret "database/creds/app-role" -}}
    export DB_USERNAME="{{ .Data.username }}"
    export DB_PASSWORD="{{ .Data.password }}"
    {{- end }}

AWS Secrets Manager e KMS

AWS Secrets Manager é a solução managed da AWS para armazenamento e rotação de segredos. Integra nativamente com RDS (PostgreSQL, MySQL, Aurora) para rotação automática — sem código customizado, a AWS gera uma nova senha para o banco a cada N dias, atualiza o segredo no SM, e o RDS começa a aceitar a nova senha antes de invalidar a antiga (dual-password period).

# Terraform — Secrets Manager com rotação automática de RDS
resource "aws_secretsmanager_secret" "db_password" {
  name = "prod/myapp/db-credentials"
  recovery_window_in_days = 7  # grace period antes de deletar
}

resource "aws_secretsmanager_secret_rotation" "db_rotation" {
  secret_id           = aws_secretsmanager_secret.db_password.id
  rotation_lambda_arn = aws_lambda_function.rotation.arn
  rotation_rules {
    automatically_after_days = 30  # rotação a cada 30 dias
  }
}

# IAM policy — acesso mínimo necessário por aplicação
resource "aws_iam_policy" "app_secrets" {
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = ["secretsmanager:GetSecretValue"]
      Resource = aws_secretsmanager_secret.db_password.arn
    }]
  })
}

AWS KMS (Key Management Service) complementa o Secrets Manager: as chaves de criptografia dos segredos são gerenciadas pelo KMS, com suporte a Customer Managed Keys (CMK) para organizações que precisam de controle explícito sobre as chaves. KMS também é usado diretamente para envelope encryption: a aplicação chama o KMS para cifrar uma DEK, e usa a DEK para cifrar dados. O KMS nunca recebe os dados em plaintext — apenas a DEK.

Kubernetes Secrets — o que funciona e o que não funciona

Kubernetes Secrets armazena dados sensíveis em etcd, codificados em Base64 (não criptografados por padrão). Qualquer pessoa com acesso de leitura ao etcd (ou ao namespace do Kubernetes) pode decodificar os segredos. A configuração correta requer: encryption at rest do etcd (configurado no API server com uma EncryptionConfiguration), RBAC que limita get/list de secrets aos pods/service accounts que precisam, e audit log de acesso a secrets.

Para organizações que usam Kubernetes e precisam de gestão de segredos mais robusta, as opções preferidas são:

• External Secrets Operator (ESO): sincroniza segredos de fontes externas (AWS SM, GCP SM, Vault, Azure Key Vault) para Kubernetes Secrets nativos. A fonte da verdade é o secrets manager externo; o K8s Secret é apenas um cache local com TTL.
• Vault Agent Sidecar Injector: injeta segredos diretamente nos pods como arquivos ou variáveis de ambiente, sem criar K8s Secrets. Os segredos nunca ficam no etcd.
• Sealed Secrets (Bitnami): criptografa segredos com a chave pública do cluster — o yaml cifrado pode ser commitado no repositório; apenas o cluster com a chave privada pode decifrar. Adequado para GitOps onde tudo precisa estar no repositório.

Rotação automática — por que é necessária e como implementar

Rotação de segredos — trocar periodicamente as credenciais — limita a janela de dano de uma credencial comprometida. Se uma chave de API é comprometida mas rotacionada a cada 90 dias, o atacante perde acesso na próxima rotação sem que a organização precise saber que houve comprometimento. Para credenciais de alto valor (chaves de serviço, tokens de admin), rotação frequente é camada de defesa adicional.

O desafio da rotação é a coordenação: o novo segredo precisa estar ativo antes do antigo ser desativado, e todos os serviços que usam o segredo precisam adotar o novo antes da janela de transição fechar. AWS Secrets Manager resolve isso com o "dual-password period" para bancos de dados RDS — aceita antiga e nova senha por um período. Para secrets arbitrários, a lógica de rotação precisa ser implementada considerando que múltiplos serviços podem estar usando o segredo simultaneamente.

# Padrão de rotação para segredos arbitrários com Vault
# O Vault Agent monitora o TTL e obtém novas credenciais antes da expiração
# O arquivo de segredo é atualizado atomicamente no disco do pod

# Aplicação — ler segredo do arquivo, não de variável de ambiente (para pegar renovações)
def get_db_password():
    with open('/vault/secrets/db-creds') as f:
        creds = json.load(f)
    return creds['password']

# Para conexões de longa duração — checar se o segredo mudou no arquivo
def reconnect_if_needed(conn, current_password: str) -> tuple:
    file_password = get_db_password()
    if file_password != current_password:
        conn.close()
        return new_connection(file_password), file_password
    return conn, current_password

Detecção de segredos em repositório

Apesar das melhores práticas, segredos acabam em repositórios — por acidente, por pressa, por desconhecimento. As ferramentas de detecção existem em dois momentos: pre-commit (antes de o desenvolvedor commitar) e scanning (depois, em repositórios existentes).

Para pre-commit, o hook mais eficaz é o git-secrets (AWS) ou o Gitleaks — um binário que scanneia o diff antes de cada commit e bloqueia se encontrar padrões de segredos conhecidos (AWS access keys, tokens GitHub, senhas em strings de conexão, chaves privadas PEM). Configurado como pre-commit hook via Husky (Node.js) ou pre-commit (Python), roda automaticamente sem intervenção do desenvolvedor.

# Gitleaks — pre-commit hook
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Instalação
pip install pre-commit
pre-commit install

# Gitleaks também pode escanear o histórico completo do repositório
gitleaks detect --source . --log-opts "--all" --report-format json --report-path leaks.json

Para repositórios existentes e pipelines CI/CD, as ferramentas de scanning contínuo são GitGuardian (SaaS, integração nativa com GitHub, GitLab, Bitbucket) e TruffleHog (open source). GitGuardian processa commits em tempo real e notifica quando segredos são detectados — incluindo segredos que foram commitados e depois deletados (que ainda aparecem no git history). TruffleHog pode ser executado localmente ou em CI/CD e suporta mais de 700 detectors de diferentes tipos de segredo.

Least privilege para segredos — o princípio que governa tudo

Independente da tecnologia de secrets management, o princípio que governa a política é least privilege: cada serviço tem acesso apenas aos segredos que precisa, com as permissões mínimas necessárias para a função. Um serviço de leitura de relatórios não precisa de credenciais de escrita no banco. Um serviço de notificações não precisa da chave de API do sistema de pagamentos. Segmentar o acesso a segredos limita o blast radius de um comprometimento — um serviço comprometido expõe apenas os segredos que aquele serviço acessava.

A implementação técnica de least privilege varia por plataforma: IAM roles na AWS (cada serviço tem uma role com permissões específicas para os secrets que precisa), policies no Vault (cada AppRole ou K8s service account tem acesso a paths específicos no Vault), e políticas de RBAC no Kubernetes (service accounts diferentes por deployment, cada um com acesso apenas aos secrets necessários).

Como praticar

1. Configurar Vault local com dynamic secrets para PostgreSQL. Suba um Vault em modo dev (docker run -p 8200:8200 hashicorp/vault server -dev) e um PostgreSQL (docker run -p 5432:5432 -e POSTGRES_PASSWORD=admin postgres). Configure o secrets engine de database conforme os exemplos acima e solicite credenciais dinâmicas. Observe no PostgreSQL que o usuário temporário foi criado; aguarde o TTL e observe que o usuário foi revogado automaticamente.
   Critério: Após solicitar credenciais com vault read database/creds/app-role, verificar com psql -c "\du" que o usuário temporário existe. Aguardar o TTL e confirmar que o usuário foi revogado — a conexão com as credenciais antigas deve falhar com "role does not exist".
2. Instalar Gitleaks como pre-commit hook em um projeto existente. Instale pre-commit e configure o Gitleaks hook. Tente commitar um arquivo com uma string que parece uma chave AWS (AKIA + 16 chars aleatórios) — o hook deve bloquear. Execute gitleaks detect --source . --log-opts "--all" no repositório e analise os resultados — provavelmente encontrará algo que não deveria estar lá.
   Critério: O hook deve bloquear um commit com string AKIAIOSFODNN7EXAMPLE em qualquer arquivo, exibindo a detecção com tipo de segredo e linha. O scan de histórico deve completar sem erros de configuração e produzir um relatório JSON analisável.
3. Auditar os segredos da sua aplicação. Liste todos os segredos que sua aplicação usa: senhas de banco, chaves de API, tokens de serviços terceiros, certificados. Para cada um: onde está armazenado? Quem tem acesso? Quando foi rotacionado pela última vez? Existe audit log de acesso? O resultado revela o gap entre a prática atual e o ideal — e prioriza o que corrigir primeiro.
   Critério: Produzir uma tabela com colunas: segredo, localização atual, quem pode acessar, última rotação, existe audit log (S/N). Identificar pelo menos um segredo de alto risco (acesso excessivo ou nunca rotacionado) e propor plano de remediação com tecnologia e timeline específicos.
4. Configurar ESO para sincronizar segredo do AWS Secrets Manager com Kubernetes. Em um cluster Kind local com ESO instalado, crie um SecretStore apontando para AWS SM (use credenciais locais ou fake para Kind) e um ExternalSecret que sincronize um segredo. Verifique que o K8s Secret é criado com o valor correto e que o ESO atualiza o Secret quando o valor muda no AWS SM.
   Critério: kubectl get externalsecret -n app deve mostrar status SecretSynced. Alterar o valor no AWS SM e aguardar o TTL de refresh — kubectl get secret db-credentials -o yaml | base64 -d deve mostrar o novo valor sem intervenção manual.
5. Implementar rotação zero-downtime com Vault e reconexão automática. Usando o setup do exercício 1, configure uma aplicação Python que mantém uma conexão de banco de longa duração. Implemente o padrão de reconexão que lê credenciais do arquivo /vault/secrets/db-creds e detecta mudança de senha. Simule a renovação de credenciais pelo Vault Agent e verifique que a aplicação reconecta sem erro.
   Critério: A aplicação deve operar continuamente durante a renovação de credenciais — sem exceção "password authentication failed" no log e sem restart manual. Registrar no log o timestamp da detecção de mudança de credencial e da reconexão bem-sucedida.