Jak řešíte konfiguraci a tajné údaje v Dockeru?

Question

Accepted Answer

Kontejnerizované aplikace by měly být **konfigurovatelné** bez nutnosti přestavby image — pomocí **proměnných prostředí**, konfiguračních souborů a správného **správy tajných údajů**. Správné řešení konfigurace a tajných údajů je důležité z hlediska bezpečnosti a pro spuštění stejného image v různých prostředích.

## Konfigurace prostřednictvím proměnných prostředí (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
```

Odle principů **twelve-factor**, konfigurace pochází z **prostředí** (env vars) za běhu — stejný image se spouští v dev, staging a produkčním prostředí s různou konfigurací bez nutnosti přestavby pro jednotlivá prostředí.

## Tajné údaje: NEVKLÁDEJTE je do image

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

## Správné řešení tajných údajů

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

## Proč je to důležité

Správa konfigurace a tajných údajů v Dockeru je důležitá jak z hlediska **bezpečnosti**, tak **operační flexibility**, a proto představuje cenné praktické znalosti.

Princip konfigurace — poskytování konfigurace prostřednictvím **proměnných prostředí za běhu** spíše než vkládání do image (v souladu s principy twelve-factor) — je důležitý, protože umožňuje, aby **stejný image běžel ve všech prostředích** (dev, staging, produkce) s různou konfigurací bez nutnosti přestavby pro jednotlivá prostředí, což je základem reprodukovatelných, přenositelných nasazení a základní praxí kontejnerizace.

Kritičtěji, **správa tajných údajů** je vážná otázka bezpečnosti: klíčové pravidlo — **nikdy nevkládejte tajné údaje (hesla, API klíče, tokeny) do image** — je nezbytné, protože vrstvy image jsou kontrolovatelné a tajné údaje v nich obsažené mohou být **extrahovány** (a zůstávají v dřívějších vrstvách i pokud byly později "odstraněny"), takže kdokoli s image získá tajné údaje; jedná se o běžnou, nebezpečnou chybu, která způsobuje skutečné úniky pověřovacích údajů.

Porozumění **správné správě tajných údajů** — proměnné prostředí za běhu (lepší, ačkoli viditelné při kontrole), vyhrazené mechanismy tajných údajů (Docker/Kubernetes Secrets bezpečně připojené, správce tajných údajů jako Vault nebo AWS Secrets Manager načítané za běhu, BuildKit build secrets pro potřeby v čase buildu) a udržování souborů `.env` mimo kontrolu verzí a image — je nutné pro bezpečnou správu tajných údajů.

Protože spuštění stejného image v různých prostředích (prostřednictvím konfigurace založené na env) a ochrana tajných údajů (nikdy je nevkládejte do image) jsou oba důležité pro bezpečná, flexibilní kontejnerizovaná nasazení, a protože nesprávné řešení tajných údajů je vážná, běžná bezpečnostní selhání, je pochopení konfigurace a správy tajných údajů v Dockeru — konfigurace založená na prostředí a správná správa tajných údajů — cenné, prakticky důležité znalosti pro bezpečné a flexibilní nasazování kontejnerů, přičemž aspekt tajných údajů je zvláště kritickou bezpečnostní znalostí, která zabraňuje skutečné exposici pověřovacích údajů.