Kako upravljaš konfiguracije in skrivnosti v Dockerju?

Question

Accepted Answer

Kentirizovane aplikacije morajo biti **nastavljive** brez ponovnega gradenja slike — z uporabo **okoljskih spremenljivk**, konfiguracijskih datotek in pravilnega **upravljanja skrivnosti**. Pravilno upravljanje konfiguracije in skrivnosti je pomembno za varnost in za poganjanje iste slike v različnih okoljih.

## Konfiguracija preko okoljskih spremenljivk (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
```

V skladu s **twelve-factor** načeli konfiguracija prihaja iz **okolja** (okoljske spremenljivke) ob izvajanju — tako da ISTA slika teče v razvoju, testiranju in produkciji z različno konfiguracijo, brez ponovnega gradenja za vsako okolje.

## Skrivnosti: jih NE vključuj v slike

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

## Pravilno upravljanje skrivnosti

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

## Zakaj je to pomembno

Pravilno upravljanje konfiguracije in skrivnosti v Dockerju je pomembno tako za **varnost** kot za **operativno fleksibilnost**, zato je to dragoceno praktično znanje.

Načelo konfiguracije — zagotavljanje konfiguracije preko **okoljskih spremenljivk ob izvajanju** namesto vključevanja v sliko (v skladu s twelve-factor načeli) — je pomembno, ker omogoči **isto sliko tečejo v vseh okoljih** (razvoj, testiranje, produkcija) z različno konfiguracijo, brez ponovnega gradenja za vsako okolje, kar je temeljno za ponovljive, prenosljive uvajanje in osnovni postopek kontejnerizacije.

Še bolj kritično je **upravljanje skrivnosti** — resno varnostno skrb: ključno pravilo — **nikoli ne vključuj skrivnosti (gesla, ključe API, žetone) v slike** — je bistveno, ker so plasti slike pregledljive in skrivnosti, ki so vključene v njih, je mogoče **ekstrahirati** (in ostanejo v prejšnjih plasteh tudi če jih kasneje "odstraniš"), zato ima vsakdo, ki ima sliko, tudi skrivnosti; to je pogosta, nevarna napaka, ki povzroči prave uhajanja poverilnic.

Razumevanje **pravilnega upravljanja skrivnosti** — okoljske spremenljivke ob izvajanju (bolje, čeprav vidne v inšpekciji), namenski mehanizmi za skrivnosti (Docker/Kubernetes Secrets pritrjeni varno, upravljavci skrivnosti kot Vault ali AWS Secrets Manager pridobljeni ob izvajanju, BuildKit skrivnosti gradnje za potrebe v času gradnje) in držanje `.env` datotek izven kontrole različic in slik — je potrebno za varno upravljanje skrivnosti.

Ker sta poganjanje iste slike v različnih okoljih (preko konfiguracije na osnovi okoljskih spremenljivk) in zaščita skrivnosti (nikoli jih ne vključuj v slike) oba pomembna za varno, fleksibilno uvajanje kotizirovanih aplikacij, in ker je napačno upravljanje skrivnosti resna, pogosta varnostna napaka, je razumevanje upravljanja konfiguracije in skrivnosti v Dockerju — konfiguracija na osnovi okoljskih spremenljivk in pravilno upravljanje skrivnosti — dragoceno, praktično pomembno znanje za varno in fleksibilno uvajanje kontejnerjev, pri čemer je vidik skrivnosti še posebej kritično varnostno znanje, ki preprečuje pravo izpostavljenost poverilnic.