Hvordan håndterer du konfiguration og hemmeligheder i Docker?

Question

Accepted Answer

Containeriserede applikationer skal være **konfigurbare** uden at genopbygge billedet — ved hjælp af **miljøvariabler**, konfigurationsfiler og ordentlig **hemmeligheder-håndtering**. Korrekt håndtering af konfiguration og hemmeligheder er vigtig for sikkerhed og for at køre det samme billede på tværs af miljøer.

## Konfiguration via miljøvariabler (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
```

I tråd med **twelve-factor** principper kommer konfiguration fra **miljøet** (env-variabler) ved køretid — så det SAMME billede kører i dev, staging og production med forskellig konfiguration, aldrig genopbygget pr. miljø.

## Hemmeligheder: bak dem IKKE ind i billeder

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

## Ordentlig hemmeligheder-håndtering

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

## Hvorfor det betyder noget

Korrekt håndtering af konfiguration og hemmeligheder i Docker er vigtig for både **sikkerhed** og **operationel fleksibilitet**, så det er værdifuld praktisk viden.

Konfigurationsprincippet — at levere konfiguration via **miljøvariabler ved køretid** i stedet for at bake den ind i billedet (i tråd med twelve-factor principper) — er vigtig, fordi det lader det **samme billede køre på tværs af alle miljøer** (dev, staging, production) med forskellig konfiguration, aldrig genopbygget pr. miljø, hvilket er grundlæggende for reproducerbare, portable deployments og en kernepraksis inden for containerisering.

Mere kritisk er **hemmeligheder-håndtering** en alvorlig sikkerhedsbetænkelighed: nøglereglen — **bak aldrig hemmeligheder (adgangskoder, API-nøgler, tokens) ind i billeder** — er essentiel, fordi billedlag er inspicerbare og hemmeligheder indlejret i dem kan **ekstraheres** (og forbliver i tidligere lag selv hvis "fjernet" senere), så enhver med billedet får hemmeligheder; dette er en almindelig, farlig fejltagelse, der forårsager ægte legitimationslæk.

Forståelse af **ordentlig hemmeligheder-håndtering** — miljøvariabler ved køretid (bedre, selvom synlige ved inspektion), dedikerede hemmeligheder-mekanismer (Docker/Kubernetes Secrets monteret sikkert, hemmeligheder-managere som Vault eller AWS Secrets Manager hentet ved køretid, BuildKit build-hemmeligheder til build-tid behov), og at holde `.env` filer uden for versionskontrol og billeder — er nødvendig for at håndtere hemmeligheder sikkert.

Da det at køre det samme billede på tværs af miljøer (via env-baseret konfiguration) og beskytte hemmeligheder (aldrig indlejre dem i billeder) både er vigtige for sikre, fleksible containeriserede deployments, og da fejlhåndtering af hemmeligheder er en alvorlig, almindelig sikkerhedsfejl, er forståelse af konfiguration og hemmeligheder-håndtering i Docker — miljø-baseret konfiguration og ordentlig hemmeligheder-håndtering — værdifuld, praktisk-vigtig viden for at deploye containere sikkert og fleksibelt, hvor hemmeligheder-aspektet især er kritisk sikkerhedsviden, der forebygger ægte legitimations-eksponering.