Kaip tvarkote konfigūraciją ir paslaptis Docker?

Question

Accepted Answer

Kontainerizuotos aplikacijos turėtų būti **konfigūruojamos** be atvaizdo perkūrimo — naudojant **aplinkos kintamuosius**, konfigūracijos failus ir tinkamą **paslaptų valdymą**. Teisingai tvarkant konfigūraciją ir paslaptis, svarbu saugumui ir tam, kad tas pats vaizdas veiktų skirtingose aplinkose.

## Konfigūracija per aplinkos kintamuosius (12-veiksniai)

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

Laikydamiesi **dvylikos-veiksnio** principų, konfigūracija pasidaro iš **aplinkos** (aplinkos kintamieji) vykdymo metu — todėl TAS PATS vaizdas veikia kūrimo, paruošos ir gamybos aplinkose su skirtinga konfigūracija, niekada neperkūriant per aplinką.

## Paslaptys: NEJUNKITE jų į atvaizdo

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

## Tinkamas paslaptų valdymas

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

## Kodėl tai svarbu

Teisingai tvarkant konfigūraciją ir paslaptis Docker yra svarbu tiek **saugumui**, tiek **operaciniam lankstumui**, todėl tai vertinga praktinė žinia.

Konfigūracijos principas — konfigūracijos pateikimas per **aplinkos kintamuosius vykdymo metu**, o ne jos įterpimas į atvaizdo (laikantis dvylikos-veiksnio principų) — yra svarbus, nes leidžia **tam pačiam atvaizdui veikti visose aplinkose** (kūrimo, paruošos, gamybos) su skirtinga konfigūracija, niekada neperkūriant per aplinką, kas yra pagrindinis daugiaparametrinių, nešiojamų diegimų principas ir pagrindinė kontainerizacijos praktika.

Dar kritiškai, **paslaptų valdymas** yra rimtas saugumo klausimas: pagrindinė taisyklė — **niekada nejunkite paslaptys (slaptažodžiai, API raktai, žetonai) į atvaizdo** — yra esminė, nes atvaizdų sluoksniai yra inspektuojami ir paslaptys, įterptos juose, gali būti **ištrauktos** (ir likti ankstesniuose sluoksniuose net jei vėliau „pašalintos), todėl bet kas, turintis atvaizdo, gauna paslaptis; tai yra dažna, pavojinga klaida, sukėlusi tikrus kredencialų nuotekius.

Supratimas apie **tinkamą paslaptų valdymą** — vykdymo laiko aplinkos kintamuosius (geriau, nors matomi inspektavime), dedikuotus paslaptų mechanizmus (Docker/Kubernetes Paslaptys montuojamos saugiai, paslaptų valdikliai kaip Vault arba AWS Secrets Manager gauti vykdymo metu, BuildKit statybos paslaptys statybos laiko poreikiams), ir `.env` failų palaikymą iš versijos kontrolės ir atvaizdo — yra būtinas slaptas valdymas saugiai.

Kadangi to paties atvaizdo paleidimas skirtingose aplinkose (per aplinkos konfigūraciją) ir paslaptų apsauga (niekada nejunkite jų į atvaizdo) yra svarbus saugiems, lankstems kontainerizuotiems diegimams, ir kadangi netinkamas paslaptų tvarkymas yra rimtas, dažnas saugumo nepavykimas, supratimas apie konfigūracijos ir paslaptų valdymą Docker — aplinkoje pagrįsta konfigūracija ir tinkamas paslaptų valdymas — yra vertinga, praktiškai svarbi žinia kontainerių diegimui saugiai ir lankstiai, o paslaptų aspektas ypač yra kritiškai svarbi saugumo žinia, kuri nuo tikro kredencialų nuotekio.