Hvordan håndterer du konfigurasjon og hemmeligheter i Docker?

Question

Accepted Answer

Containeriserte applikasjoner skal være **konfigurerbares** uten å bygge bildet på nytt — ved å bruke **miljøvariabler**, config-filer og ordentlig **hemmelighetsadministrasjon**. Å håndtere konfigurasjon og hemmeligheter riktig er viktig for sikkerhet og for å kjøre samme bilde på tvers av miljøer.

## Konfigurasjon 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
```

Etter **twelve-factor**-prinsipper kommer konfigurasjonen fra **miljøet** (env vars) ved kjøring — slik at SAMME bilde kjører i dev, staging og produksjon med forskjellig konfigurasjon, aldri bygget på nytt per miljø.

## Hemmeligheter: IKKE bak dem inn i bilder

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

```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 betyr noe

Å håndtere konfigurasjon og hemmeligheter riktig i Docker er viktig både for **sikkerhet** og **operasjonell fleksibilitet**, så det er verdifull praktisk kunnskap.

Konfigurasjonsprinsippet — å tilby konfigurasjon via **miljøvariabler ved kjøring** i stedet for å bake det inn i bildet (etterfulgt twelve-factor-prinsipper) — er viktig fordi det lar **samme bilde kjøre på tvers av alle miljøer** (dev, staging, produksjon) med forskjellig konfigurasjon, aldri bygget på nytt per miljø, noe som er grunnleggende for reproduserbare, portable distribusjoner og en kjernepraksis for containerisering.

Mer kritisk er **hemmelighetsadministrasjon** et alvorlig sikkerhetsproblem: nøkkelregelen — **aldri bak hemmeligheter (passord, API-nøkler, tokens) inn i bilder** — er essensiell fordi bildelag er inspiserbare og hemmeligheter som er innebakt i dem kan bli **ekstrahert** (og blir værende i tidligere lag selv hvis de blir "fjernet" senere), så hvem som helst med bildet får hemmellighetene; dette er en vanlig, farlig feil som forårsaker ekte lekkasjer av legitimasjon.

Å forstå **ordentlig hemmelighetsadministrasjon** — miljøvariabler ved kjøring (bedre, selv om synlige i inspect), dedikerte hemmelighetmekanismer (Docker/Kubernetes Secrets montert sikkert, hemmelighetsadministratorer som Vault eller AWS Secrets Manager hentet ved kjøring, BuildKit bygghemmeligheter for behov ved byggetid), og å holde `.env`-filer utenfor versjonskontroll og bilder — er nødvendig for å administrere hemmeligheter sikkert.

Siden å kjøre samme bilde på tvers av miljøer (via env-basert konfigurasjon) og å beskytte hemmeligheter (aldri innebake dem i bilder) er begge viktig for sikre, fleksible containeriserte distribusjoner, og siden feilbehandling av hemmeligheter er en alvorlig, vanlig sikkerhetsfeil, er det å forstå konfigurasjon og hemmelighetsadministrasjon i Docker — env-basert konfigurasjon og ordentlig hemmelighetsadministrasjon — verdifull, praktisk-viktig kunnskap for å distribuere containere sikkert og fleksibelt, med hemmelighetsaspektet spesielt kritisk sikkerhetskunnskap som forhindrer ekte legitimasjonseksponering.