คุณจัดการ configuration และ secrets ใน Docker อย่างไร?

Question

Accepted Answer

แอปพลิเคชันแบบ container ควร **กำหนดค่าได้** โดยไม่ต้อง build image ใหม่ — โดยใช้ **environment variables** ไฟล์ config และการ **จัดการ secrets** อย่างเหมาะสม การจัดการ configuration และ secrets อย่างถูกต้องเป็นเรื่องสำคัญต่อความปลอดภัยและต่อการรัน image เดียวกันข้ามหลายสภาพแวดล้อม

## การกำหนดค่าผ่าน environment variables (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** configuration จะมาจาก **environment** (env vars) ตอน runtime — ดังนั้น image เดียวกันจึงรันได้ทั้งใน dev, staging และ production ด้วยค่าที่แตกต่างกัน โดยไม่ต้อง build ใหม่ในแต่ละสภาพแวดล้อม

## Secrets: อย่าฝังไว้ใน image

```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 อย่างเหมาะสม

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

## ทำไมจึงสำคัญ

การจัดการ configuration และ secrets อย่างถูกต้องใน Docker เป็นเรื่องสำคัญทั้งต่อ **ความปลอดภัย** และ **ความยืดหยุ่นในการปฏิบัติงาน** ดังนั้นจึงเป็นความรู้เชิงปฏิบัติที่มีคุณค่า

หลักการของ configuration — การให้ค่าผ่าน **environment variables ตอน runtime** แทนที่จะฝังลงใน image (ตามหลัก twelve-factor) — เป็นเรื่องสำคัญเพราะช่วยให้ **image เดียวกันรันได้ทั่วทุกสภาพแวดล้อม** (dev, staging, production) ด้วยค่าที่ต่างกัน โดยไม่ต้อง build ใหม่ในแต่ละสภาพแวดล้อม ซึ่งเป็นพื้นฐานของการ deploy ที่ทำซ้ำได้และพกพาได้ และเป็นแนวปฏิบัติหลักของ containerization

ที่สำคัญยิ่งกว่าคือ **การจัดการ secrets** ซึ่งเป็นเรื่องความปลอดภัยที่ร้ายแรง: กฎหลัก — **อย่าฝัง secrets (passwords, API keys, tokens) ลงใน image เด็ดขาด** — เป็นเรื่องจำเป็นเพราะ image layers สามารถตรวจสอบดูได้ และ secrets ที่ฝังอยู่ในนั้นสามารถถูก **ดึงออกมา** ได้ (และยังคงอยู่ใน layer ก่อนหน้าแม้จะ "ลบ" ไปแล้วในภายหลัง) ดังนั้นใครก็ตามที่มี image ก็จะได้ secrets ไปด้วย นี่เป็นข้อผิดพลาดที่พบบ่อยและอันตราย ซึ่งทำให้เกิดการรั่วไหลของ credential จริง

การเข้าใจ **การจัดการ secrets อย่างเหมาะสม** — environment variables ตอน runtime (ดีกว่า แม้จะมองเห็นได้ตอน inspect) กลไก secrets เฉพาะทาง (Docker/Kubernetes Secrets ที่ mount อย่างปลอดภัย, secrets managers อย่าง Vault หรือ AWS Secrets Manager ที่ดึงตอน runtime, BuildKit build secrets สำหรับความต้องการตอน build) และการเก็บไฟล์ `.env` ออกจาก version control และ image — จำเป็นต่อการจัดการ secrets อย่างปลอดภัย

เนื่องจากการรัน image เดียวกันข้ามสภาพแวดล้อม (ผ่าน config ที่อิง environment) และการปกป้อง secrets (ไม่ฝังไว้ใน image) ล้วนสำคัญต่อการ deploy แบบ container ที่ปลอดภัยและยืดหยุ่น และเนื่องจากการจัดการ secrets ผิดพลาดเป็นความล้มเหลวด้านความปลอดภัยที่ร้ายแรงและพบบ่อย การเข้าใจการจัดการ configuration และ secrets ใน Docker — ทั้ง config ที่อิง environment และการจัดการ secrets อย่างเหมาะสม — จึงเป็นความรู้ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการ deploy container อย่างปลอดภัยและยืดหยุ่น โดยเฉพาะแง่มุมของ secrets ที่เป็นความรู้ด้านความปลอดภัยที่สำคัญยิ่งซึ่งช่วยป้องกันการเปิดเผย credential จริง