Docker में configuration और secrets को कैसे handle करते हैं?

Question

Accepted Answer

Containerized applications को image rebuild किए बिना **configurable** होना चाहिए — **environment variables**, config files और उचित **secrets management** का उपयोग करके। configuration और secrets को सही ढंग से handle करना security के लिए और एक ही image को विभिन्न environments में चलाने के लिए महत्वपूर्ण है।

## environment variables के माध्यम से configuration (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** principles का पालन करते हुए, configuration runtime पर **environment** (env vars) से आती है — इसलिए वही image dev, staging और production में अलग-अलग config के साथ चलती है, कभी भी per environment rebuild नहीं किया जाता।

## Secrets: इन्हें images में bake न करें

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

## उचित secrets handling

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

## यह क्यों महत्वपूर्ण है

Docker में configuration और secrets को सही ढंग से handle करना **security** और **operational flexibility** दोनों के लिए महत्वपूर्ण है, इसलिए यह मूल्यवान practical knowledge है।

configuration principle — image में bake करने के बजाय **runtime पर environment variables के माध्यम से config प्रदान करना** (twelve-factor principles का पालन करते हुए) — महत्वपूर्ण है क्योंकि यह **एक ही image को सभी environments** (dev, staging, production) में अलग-अलग configuration के साथ चलने देता है, कभी भी per environment rebuild नहीं करता, जो reproducible, portable deployments के लिए मौलिक है और एक core containerization practice है।

अधिक महत्वपूर्ण रूप से, **secrets handling** एक गंभीर security concern है: मुख्य नियम — **secrets (passwords, API keys, tokens) को कभी भी images में bake न करें** — आवश्यक है क्योंकि image layers inspectable हैं और उनमें embed किए गए secrets **extract** किए जा सकते हैं (और बाद में "हटाए" जाने पर भी earlier layers में बने रहते हैं), इसलिए image रखने वाले किसी भी व्यक्ति को secrets मिल जाते हैं; यह एक common, खतरनाक गलती है जो वास्तविक credential leaks का कारण बनती है।

**उचित secrets handling** को समझना — runtime environment variables (बेहतर, यद्यपि inspect में visible), dedicated secrets mechanisms (Docker/Kubernetes Secrets securely mounted, Vault या AWS Secrets Manager जैसे secrets managers runtime पर fetch किए गए, build-time आवश्यकताओं के लिए BuildKit build secrets), और `.env` files को version control और images से बाहर रखना — secrets को securely manage करने के लिए आवश्यक है।

चूँकि environments में एक ही image चलाना (env-based config के माध्यम से) और secrets की सुरक्षा करना (कभी भी इन्हें images में embed न करना) दोनों secure, flexible containerized deployments के लिए महत्वपूर्ण हैं, और चूँकि secrets को गलत तरीके से handle करना एक गंभीर, common security failure है, Docker में configuration और secrets handling को समझना — environment-based config और उचित secrets management — containers को securely और flexibly deploy करने के लिए मूल्यवान, practically-important knowledge है, जिसमें विशेष रूप से secrets पहलू critical security knowledge है जो वास्तविक credential exposure को रोकती है।