Como você lida com configuração e segredos no Docker?

Question

Accepted Answer

Aplicações containerizadas devem ser **configuráveis** sem reconstruir a imagem — usando **variáveis de ambiente**, arquivos de configuração e **gerenciamento adequado de segredos**. Lidar com configuração e segredos corretamente é importante para segurança e para executar a mesma imagem em diferentes ambientes.

## Configuração via variáveis de ambiente (12-factor)

```bash
# pass config at RUNTIME via environment variables (not baked into the image)
docker run -e DATABASE_URL=postgres://... -e NODE_ENV=production myapp
docker run --env-file .env myapp        # load many from a file
```

```yaml
# in docker-compose.yml
services:
  app:
    image: myapp
    environment:
      - DATABASE_URL=postgres://db:5432/app
    env_file: .env
```

Seguindo princípios **twelve-factor**, a configuração vem do **ambiente** (variáveis de env) em tempo de execução — para que a MESMA imagem funcione em dev, staging e produção com configurações diferentes, nunca reconstruindo por ambiente.

## Segredos: NÃO os bake na imagem

```text
⚠️ NEVER put secrets (passwords, API keys, tokens) in the Dockerfile or image layers:
  → image layers are inspectable → secrets can be EXTRACTED (even if "removed" later,
    they remain in earlier layers)
  → anyone with the image gets the secrets
→ This is a serious, common security mistake.
```

## Tratamento adequado de segredos

```text
✓ RUNTIME environment variables (better than image, but visible in inspect/env)
✓ DOCKER SECRETS (Swarm) / Kubernetes Secrets — mounted securely at runtime
✓ Secrets MANAGERS — HashiCorp Vault, AWS Secrets Manager, etc. (fetch at runtime)
✓ BuildKit build secrets (--secret) — for build-time secrets without baking into layers
✓ Keep .env files OUT of version control (.gitignore) and out of the image (.dockerignore)
```

## Por que isso importa

Lidar com configuração e segredos corretamente no Docker é importante tanto para **segurança** quanto para **flexibilidade operacional**, então é um conhecimento prático valioso.

O princípio de configuração — fornecer config via **variáveis de ambiente em tempo de execução** em vez de bake na imagem (seguindo princípios twelve-factor) — é importante porque permite que a **mesma imagem seja executada em todos os ambientes** (dev, staging, produção) com configurações diferentes, nunca reconstruindo por ambiente, o que é fundamental para deployments reproduzíveis e portáveis e uma prática essencial de containerização.

Mais criticamente, **o tratamento de segredos** é uma preocupação séria de segurança: a regra-chave — **nunca bake segredos (senhas, chaves de API, tokens) em imagens** — é essencial porque as camadas da imagem são inspecionáveis e segredos nelas incorporados podem ser **extraídos** (e permanecem em camadas anteriores mesmo se "removidos" depois), então qualquer pessoa com a imagem obtém os segredos; este é um erro comum e perigoso que causa vazamentos reais de credenciais.

Entender **o tratamento adequado de segredos** — variáveis de ambiente em tempo de execução (melhor, embora visíveis em inspect), mecanismos dedicados de segredos (Docker/Kubernetes Secrets montados com segurança, gerenciadores de segredos como Vault ou AWS Secrets Manager buscados em tempo de execução, segredos de build do BuildKit para necessidades de tempo de build), e manter arquivos `.env` fora do controle de versão e imagens — é necessário para gerenciar segredos com segurança.

Como executar a mesma imagem em ambientes (via config baseada em env) e proteger segredos (nunca os incorporando em imagens) são ambos importantes para deployments containerizados seguros e flexíveis, e como o tratamento incorreto de segredos é uma falha de segurança séria e comum, entender o tratamento de configuração e segredos no Docker — config baseada em ambiente e gerenciamento adequado de segredos — é um conhecimento valioso e praticamente importante para deployar containers com segurança e flexibilidade, com o aspecto de segredos em particular sendo um conhecimento de segurança crítico que previne exposição real de credenciais.