Jak obsługujesz konfigurację i sekrety w Dockerze?

Question

Accepted Answer

Konteneryzowane aplikacje powinny być **konfigurowalne** bez przebudowywania obrazu — używając **zmiennych środowiskowych**, plików konfiguracyjnych i odpowiedniego **zarządzania sekretami**. Prawidłowa obsługa konfiguracji i sekretów jest ważna dla bezpieczeństwa i uruchamiania tego samego obrazu w różnych środowiskach.

## Konfiguracja poprzez zmienne środowiskowe (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
```

Zgodnie z zasadami **twelve-factor**, konfiguracja pochodzi ze **środowiska** (zmienne env) w czasie uruchomienia — dzięki czemu TEN SAM obraz uruchamia się w środowisku dev, staging i produkcji z różną konfiguracją, nigdy nie przebudowując na potrzeby danego środowiska.

## Sekrety: NIGDY nie wbudowuj ich w obrazy

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

## Prawidłowa obsługa sekretów

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

## Dlaczego to ważne

Prawidłowa obsługa konfiguracji i sekretów w Dockerze jest ważna zarówno dla **bezpieczeństwa**, jak i **elastyczności operacyjnej**, dlatego stanowi cenną praktyczną wiedzę.

Zasada konfiguracji — dostarczanie konfiguracji poprzez **zmienne środowiskowe w czasie uruchomienia** zamiast wbudowywania jej w obraz (zgodnie z zasadami twelve-factor) — jest ważna, ponieważ pozwala **temu samemu obrazowi działać we wszystkich środowiskach** (dev, staging, produkcja) z różną konfiguracją, nigdy nie przebudowując na potrzeby danego środowiska, co jest fundamentem dla powtarzalnych, przenośnych wdrożeń i podstawową praktyką konteneryzacji.

Co ważniejsze, **obsługa sekretów** stanowi poważne zagrożenie bezpieczeństwa: kluczowa zasada — **nigdy nie wbudowuj sekretów (hasła, klucze API, tokeny) w obrazy** — jest niezbędna, ponieważ warstwy obrazu są kontrolowalne i sekrety w nich osadzone mogą być **wyodrębnione** (i pozostają w wcześniejszych warstwach, nawet jeśli są "usunięte" później), więc każdy mający dostęp do obrazu uzyskuje sekrety; to częsty, niebezpieczny błąd, który powoduje rzeczywiste wycieki danych logowania.

Zrozumienie **prawidłowej obsługi sekretów** — zmienne środowiskowe w czasie uruchomienia (lepsze, choć widoczne w inspektowaniu), dedykowane mechanizmy sekretów (Sekrety Docker/Kubernetes montowane bezpiecznie, menedżery sekretów takie jak Vault lub AWS Secrets Manager pobierane w czasie uruchomienia, sekrety BuildKit dla potrzeb w czasie budowania), oraz trzymanie plików `.env` poza kontrolą wersji i obrazami — jest konieczne do bezpiecznego zarządzania sekretami.

Ponieważ uruchamianie tego samego obrazu w różnych środowiskach (poprzez konfigurację opartą na zmiennych env) i ochrona sekretów (nigdy nie wbudowywanie ich w obrazy) są oba ważne dla bezpiecznych, elastycznych wdrożeń konteneryzowanych, a nieznajomość obsługi sekretów jest poważnym, częstym błędem bezpieczeństwa, zrozumienie obsługi konfiguracji i sekretów w Dockerze — konfiguracji opartej na zmiennych środowiskowych i prawidłowego zarządzania sekretami — jest cenną, praktycznie ważną wiedzą do wdrażania kontenerów bezpiecznie i elastycznie, a aspekt sekretów w szczególności stanowi krytyczną wiedzę bezpieczeństwa, która zapobiega rzeczywistemu wyciękowi danych logowania.