Hur hanterar du konfiguration och hemligheter i Docker?

Question

Accepted Answer

Containeriserade applikationer bör vara **konfigurerbara** utan att behöva återskapa avbildningen — genom att använda **miljövariabler**, konfigurationsfiler och korrekt **hemlighetshantering**. Att hantera konfiguration och hemligheter på rätt sätt är viktigt för säkerhet och för att köra samma avbildning i olika miljöer.

## Konfiguration via miljövariabler (12-faktor)

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

Enligt **twelve-factor**-principerna kommer konfigurationen från **miljön** (miljövariabler) vid körning — så SAMMA avbildning körs i dev, staging och produktion med olika konfiguration, utan att behöva återskapas för varje miljö.

## Hemligheter: BAKA INTE in dem i avbildningar

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

## Korrekt hemlighetshantering

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

## Varför det är viktigt

Att hantera konfiguration och hemligheter på rätt sätt i Docker är viktigt för både **säkerhet** och **operativ flexibilitet**, så det är värdefull praktisk kunskap.

Konfigurationsprincipen — att tillhandahålla konfiguration via **miljövariabler vid körning** snarare än att baka in den i avbildningen (enligt twelve-factor-principerna) — är viktigt eftersom det gör att **samma avbildning kan köras i alla miljöer** (dev, staging, produktion) med olika konfiguration, utan att behöva återskapas för varje miljö, vilket är grundläggande för reproducerbara, portabla distributioner och en grundläggande containeriseringsteknik.

Ännu viktigare är **hemlighetshantering** ett allvarligt säkerhetsproblem: huvudregeln — **BAKA ALDRIG hemligheter (lösenord, API-nycklar, tokens) in i avbildningar** — är viktig eftersom avbildningslager är granskningsbara och hemligheter inbäddade i dem kan **extraheras** (och förblir i tidigare lager även om de "tas bort" senare), så vem som helst med avbildningen får åtkomst till hemligheterna; detta är ett vanligt, farligt misstag som orsakar verkliga identitetsuppgiftsläckor.

Att förstå **korrekt hemlighetshantering** — miljövariabler vid körning (bättre, men synliga vid inspection), dedikerade hemlighetmekanismer (Docker/Kubernetes Secrets monterade säkert, hemlighetshanterare som Vault eller AWS Secrets Manager hämtade vid körning, BuildKit-byggehemligheter för byggtidsbehov) och att hålla `.env`-filer utanför versionskontroll och avbildningar — är nödvändigt för att hantera hemligheter säkert.

Därför att att köra samma avbildning i flera miljöer (via miljöbaserad konfiguration) och att skydda hemligheter (aldrig baka in dem i avbildningar) båda är viktiga för säkra, flexibla containeriserade distributioner, och eftersom felhantering av hemligheter är ett allvarligt, vanligt säkerhetsproblem, är förståelse för konfiguration och hemlighetshantering i Docker — miljöbaserad konfiguration och korrekt hemlighetshantering — värdefull, praktisk kunskap för att distribuera behållare säkert och flexibelt, där hemlighetsdelen i synnerhet är kritisk säkerhetskunskap som förhindrar verklig identitetsuppgiftsexponering.