Wie handhabst du Konfiguration und Geheimnisse in Docker?

Question

Accepted Answer

Containerisierte Anwendungen sollten **konfigurierbar** sein, ohne das Image neu zu erstellen — mit **Umgebungsvariablen**, Konfigurationsdateien und ordnungsgemäßem **Secrets Management**. Die korrekte Handhabung von Konfiguration und Geheimnissen ist wichtig für die Sicherheit und für das Ausführen desselben Images über verschiedene Umgebungen hinweg.

## Konfiguration über Umgebungsvariablen (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
```

Nach **Twelve-Factor**-Prinzipien kommt die Konfiguration zur Laufzeit aus der **Umgebung** (Env-Variablen) — daher läuft das gleiche Image in Entwicklung, Staging und Produktion mit verschiedener Konfiguration, ohne dass es pro Umgebung neu erstellt werden muss.

## Geheimnisse: NICHT in Images backen

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

## Ordnungsgemäße Geheimnisse-Handhabung

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

## Warum es wichtig ist

Die korrekte Handhabung von Konfiguration und Geheimnissen in Docker ist wichtig für beide **Sicherheit** und **operative Flexibilität**, daher ist es wertwolles praktisches Wissen.

Das Konfigurationsprinzip — Konfiguration zur Laufzeit über **Umgebungsvariablen** bereitstellen, anstatt sie ins Image zu backen (Twelve-Factor-Prinzipien befolgen) — ist wichtig, weil es dem **gleichen Image ermöglicht, über alle Umgebungen** (Entwicklung, Staging, Produktion) mit unterschiedlicher Konfiguration zu laufen, ohne dass es pro Umgebung neu erstellt werden muss. Dies ist fundamental für reproduzierbare, portable Deployments und eine Kernpraxis der Containerisierung.

Kritischer ist **Geheimnisse-Handhabung** ein ernstes Sicherheitsanliegen: Die Schlüsselregel — **Geheimnisse (Passwörter, API-Schlüssel, Tokens) NICHT ins Image backen** — ist essentiell, weil Image-Layer inspizierbar sind und darin eingebettete Geheimnisse können **extrahiert** werden (und bleiben in früheren Layern bestehen, auch wenn sie später "entfernt" werden), daher bekommt jeder, der das Image hat, die Geheimnisse; dies ist ein häufiger, gefährlicher Fehler, der zu echten Credential-Leaks führt.

Das Verständnis für **ordnungsgemäße Geheimnisse-Handhabung** — Umgebungsvariablen zur Laufzeit (besser, aber sichtbar bei Inspect), dedizierte Secrets-Mechanismen (Docker/Kubernetes Secrets sicher gemountet, Secrets Manager wie Vault oder AWS Secrets Manager zur Laufzeit abgerufen, BuildKit Build Secrets für Build-Zeit-Anforderungen), und `.env`-Dateien aus Versionskontrolle und Images heraushalten — ist notwendig, um Geheimnisse sicher zu verwalten.

Da das Ausführen desselben Images über Umgebungen hinweg (via Env-basierte Konfiguration) und der Schutz von Geheimnissen (Nicht ins Image einbetten) beide wichtig für sichere, flexible containerisierte Deployments sind, und da die falsche Handhabung von Geheimnissen ein ernstes, häufiges Sicherheitsversäumnis ist, ist das Verständnis für Konfiguration und Geheimnisse-Handhabung in Docker — Env-basierte Konfiguration und ordnungsgemäße Secrets Management — wertwolles, praktisch-wichtiges Wissen für das sichere und flexible Deployen von Containern, wobei der Secrets-Aspekt insbesondere kritisches Sicherheitswissen ist, das echte Credential-Exposition verhindert.