ESENPTFR
Contato
Mudar idioma
ESENPTFR

Configuração e Segredos

Variáveis de ambiente, config maps, gerenciamento seguro de segredos e ferramentas como o Vault para proteger dados sensíveis.

O princípio: separar configuração do código

Uma das regras fundamentais do deploy moderno é que a configuração não deve viver no código. O mesmo artefato (imagem Docker, binário, bundle) deve poder ser executado em qualquer ambiente — a única coisa que muda é a configuração.

Isso inclui:

  • URLs de bancos de dados e serviços externos
  • Credenciais e tokens de acesso
  • Feature flags e parâmetros de comportamento
  • Níveis de logging e timeouts
  • Chaves de API de terceiros

Variáveis de ambiente

As variáveis de ambiente são o mecanismo mais básico e universal para injetar configuração em uma aplicação.

Vantagens

  • Suportadas por todas as linguagens e plataformas
  • Fáceis de configurar em contêineres, CI/CD e provedores de nuvem
  • Não exigem bibliotecas adicionais

Boas práticas

# Nombres descriptivos en UPPER_SNAKE_CASE
DATABASE_URL=postgres://user:pass@host:5432/db
REDIS_URL=redis://localhost:6379
LOG_LEVEL=info
API_TIMEOUT_MS=5000
FEATURE_NEW_CHECKOUT=true
  • Usar um arquivo .env.example no repositório documentando todas as variáveis necessárias (sem valores reais)
  • Nunca commitar arquivos .env com valores reais
  • Validar as variáveis ao iniciar a aplicação — falhar rápido se faltar alguma obrigatória

Validação na inicialização

function validateEnv() {
  const required = ['DATABASE_URL', 'REDIS_URL', 'JWT_SECRET'];
  const missing = required.filter(key => !process.env[key]);
  if (missing.length > 0) {
    throw new Error(`Missing env vars: ${missing.join(', ')}`);
  }
}

ConfigMaps no Kubernetes

No Kubernetes, os ConfigMaps permitem armazenar configuração não sensível como pares chave-valor e montá-los nos pods.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_TIMEOUT: "30s"
  MAX_CONNECTIONS: "100"
  FEATURE_FLAGS: |
    {
      "newCheckout": true,
      "darkMode": false
    }

Injetar como variáveis de ambiente

spec:
  containers:
    - name: my-app
      envFrom:
        - configMapRef:
            name: app-config

Montar como arquivo

spec:
  containers:
    - name: my-app
      volumeMounts:
        - name: config-volume
          mountPath: /app/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Gerenciamento de segredos

Os segredos (senhas, tokens, chaves privadas) exigem um tratamento especial. Nunca devem estar em:

  • No código-fonte
  • Arquivos de configuração commitados
  • Logs da aplicação
  • Imagens Docker

Kubernetes Secrets

O Kubernetes oferece um recurso Secret para dados sensíveis:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  DATABASE_PASSWORD: "mi-password-seguro"
  JWT_SECRET: "mi-jwt-secret"
  API_KEY: "mi-api-key"

Limitação importante: os Secrets do Kubernetes são armazenados no etcd codificados em base64, mas não estão criptografados por padrão. Para maior segurança, habilitar encryption at rest ou usar um gerenciador de segredos externo.

HashiCorp Vault

O Vault é a ferramenta mais popular para gerenciamento centralizado de segredos:

  • Armazenamento seguro: os segredos são criptografados em repouso
  • Acesso controlado: políticas granulares de quem pode ler quais segredos
  • Rotação automática: os segredos podem ser rotacionados sem realizar novo deploy
  • Auditoria: registro completo de quem acessou qual segredo e quando
  • Segredos dinâmicos: gera credenciais temporárias sob demanda (ex: credenciais de BD que expiram em 1 hora)

Outras ferramentas

  • AWS Secrets Manager: gerenciamento de segredos nativo na AWS com rotação automática
  • Google Secret Manager: equivalente no GCP
  • Azure Key Vault: equivalente no Azure
  • SOPS: criptografa arquivos de configuração que podem ser commitados de forma segura

Rotação de segredos

Os segredos devem ser rotacionados periodicamente para minimizar o impacto de um vazamento:

  1. Gerar novo segredo: criar a nova credencial no gerenciador de segredos
  2. Atualizar a aplicação: a aplicação lê o novo segredo (idealmente sem reinício)
  3. Verificar o funcionamento: confirmar que tudo funciona com o novo segredo
  4. Revogar o segredo anterior: eliminar a credencial antiga

Rotação sem downtime

Para rotacionar segredos sem downtime, a aplicação deve suportar dual credentials temporariamente:

  • Aceitar tanto o segredo antigo quanto o novo durante um período de transição
  • Uma vez confirmado que tudo funciona, revogar o antigo

Boas práticas gerais

  1. Princípio do menor privilégio: cada serviço acessa apenas os segredos de que precisa
  2. Não logar segredos: sanitizar os logs para que nunca exibam credenciais
  3. Criptografar em trânsito e em repouso: TLS para comunicação, encryption at rest para armazenamento
  4. Auditar acessos: registrar quem acessa quais segredos e quando
  5. Automatizar a rotação: não depender de processos manuais para rotacionar credenciais
  6. Separar configuração de segredos: a configuração não sensível vai em ConfigMaps, os segredos em um gerenciador dedicado

Resumo

A configuração e os segredos são aspectos críticos do deploy. As variáveis de ambiente e os ConfigMaps gerenciam a configuração não sensível, enquanto ferramentas como o Vault, o AWS Secrets Manager ou os Kubernetes Secrets protegem os dados sensíveis. A chave é separar a configuração do código, validar na inicialização e rotacionar segredos periodicamente.