Hoe handle je configuratie en secrets in Docker?

Question

Accepted Answer

Gecontaineriseerde applicaties moeten **configureerbaar** zijn zonder het image opnieuw te builden — door **omgevingsvariabelen**, config-bestanden en juist **secrets management** te gebruiken. Het correct omgaan met configuratie en secrets is belangrijk voor beveiliging en voor het draaien van hetzelfde image in verschillende omgevingen.

## Configuratie via omgevingsvariabelen (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
```

Volgens **twelve-factor** principes komt configuratie uit de **omgeving** (env vars) bij runtime — zodat hetzelfde image in dev, staging en production draait met verschillende configuratie, zonder opnieuw te builden per omgeving.

## Secrets: bake ze NIET in images

```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.
```

## Juist secrets handling

```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)
```

## Waarom het belangrijk is

Het correct omgaan met configuratie en secrets in Docker is belangrijk voor zowel **beveiliging** als **operationele flexibiliteit**, dus het is waardevolle praktische kennis.

Het configuratieprincipe — configuratie via **omgevingsvariabelen bij runtime** in plaats van in het image in te bakken (volgens twelve-factor principes) — is belangrijk omdat het het **dezelfde image in alle omgevingen** (dev, staging, production) met verschillende configuratie laat draaien, zonder opnieuw te builden per omgeving, wat fundamenteel is voor reproduceerbare, portable deployments en een kernpraktijk van containerisatie.

Meer nog: **secrets handling** is een ernstig beveiligingsprobleem: de kernregel — **bake nooit secrets (wachtwoorden, API keys, tokens) in images** — is essentieel omdat image layers inspecteerbaar zijn en secrets die erin zitten kunnen **geëxtraheerd** worden (en blijven in eerdere layers zelfs als ze later "verwijderd" worden), dus iedereen met het image krijgt de secrets; dit is een veelvoorkomende, gevaarlijke fout die echte credential leaks veroorzaakt.

Het begrijpen van **juist secrets handling** — runtime omgevingsvariabelen (beter, hoewel zichtbaar in inspect), dedicated secrets mechanismen (Docker/Kubernetes Secrets veilig gemount, secrets managers zoals Vault of AWS Secrets Manager bij runtime opgehaald, BuildKit build secrets voor build-time behoeften), en `.env` bestanden uit version control en images houden — is nodig om secrets veilig te beheren.

Omdat het draaien van hetzelfde image in omgevingen (via env-gebaseerde configuratie) en het beschermen van secrets (nooit in images embedden) beide belangrijk zijn voor veilige, flexibele gecontaineriseerde deployments, en omdat slecht secrets handling een ernstig, veelvoorkomend beveiligingsprobleem is, is het begrijpen van configuratie en secrets handling in Docker — op omgeving gebaseerde configuratie en juist secrets management — waardevolle, praktisch-belangrijke kennis voor het veilig en flexibel deployen van containers, waarbij het secrets aspect in het bijzonder kritieke beveiligingskennis is die echte credential blootstelling voorkomt.