Docker'da konfigürasyon ve sırları nasıl yönetirsiniz?

Question

Accepted Answer

Containerized uygulamalar **yapılandırılabilir** olmalı — image'ı yeniden oluşturmadan, **ortam değişkenleri**, config dosyaları ve uygun **secrets yönetimi** kullanarak. Konfigürasyon ve sırları doğru şekilde yönetmek güvenlik ve aynı image'ı ortamlar arasında çalıştırmak için önemlidir.

## Ortam değişkenleri aracılığıyla konfigürasyon (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
```

**twelve-factor** prensiplerini takip ederek, konfigürasyon runtime'da **ortamdan** (env vars) gelir — bu nedenle AYNI image dev, staging ve production'da farklı config ile çalışır, ortam başına hiçbir zaman yeniden oluşturulmaz.

## Sırlar: onları image'lara gömmeyin

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

## Uygun secrets yönetimi

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

## Neden önemli

Docker'da konfigürasyon ve sırları doğru şekilde yönetmek hem **güvenlik** hem de **operasyonel esneklik** için önemlidir, bu nedenle değerli pratik bilgidir.

Konfigürasyon prensibi — image'a gömülü halde yerine runtime'da **ortam değişkenleri aracılığıyla** config sağlama (twelve-factor prensiplerini takip ederek) — önemlidir çünkü **aynı image'ın tüm ortamlarda** (dev, staging, production) farklı konfigürasyon ile çalışmasını sağlar, ortam başına hiçbir zaman yeniden oluşturmadan, bu da reproducible ve portable deployment'ların temelini oluşturur ve containerization'ın temel bir pratiğidir.

Daha kritik olarak, **secrets yönetimi** ciddi bir güvenlik kaygısıdır: ana kural — **sırları (parolalar, API anahtarları, tokenlar) hiçbir zaman image'lara gömmeyin** — çok önemlidir çünkü image katmanları incelenebilir ve onlara gömülü sırlar **çıkarılabilir** (ve daha sonra "kaldırılsalar" bile önceki katmanlarda kalabilir), bu nedenle image'a sahip herkes sırları elde eder; bu yaygın, tehlikeli bir hata olup gerçek credential sızıntılarına neden olur.

**Uygun secrets yönetimini** anlamak — runtime ortam değişkenleri (daha iyi, ancak inspect'te görünür), dedicated secrets mekanizmaları (Docker/Kubernetes Secrets güvenli şekilde mount edilir, Vault veya AWS Secrets Manager gibi secrets manager'lar runtime'da fetch edilir, build-time ihtiyaçları için BuildKit build secrets), ve `.env` dosyalarını version control ve image'ların dışında tutmak — sırları güvenli şekilde yönetmek için gereklidir.

Aynı image'ı ortamlar arasında çalıştırmak (env-based config aracılığıyla) ve sırları korumak (hiçbir zaman image'lara gömmeyin) hem güvenli hem de esnek containerized deployment'lar için önemli olduğundan ve secrets'ın yanlış kullanılması ciddi, yaygın bir güvenlik başarısızlığı olduğundan, Docker'da konfigürasyon ve secrets yönetimini anlamak — environment-based config ve uygun secrets yönetimi — container'ları güvenli ve esnek şekilde deploy etmek için değerli, pratik açıdan önemli bilgidir; özellikle secrets yönü gerçek credential exposure'ını önleyen kritik güvenlik bilgisidir.