Bạn xử lý cấu hình và secret trong Docker như thế nào?

Question

Accepted Answer

Các ứng dụng container hóa nên **có thể cấu hình** mà không cần rebuild image — dùng **biến môi trường**, các tệp config, và **quản lý secret** đúng cách. Xử lý cấu hình và secret đúng cách là quan trọng cho bảo mật và để chạy cùng một image qua các môi trường.

## Cấu hình qua biến môi trường (12-factor)

```bash
# truyền config tại RUNTIME qua biến môi trường (không nhúng vào image)
docker run -e DATABASE_URL=postgres://... -e NODE_ENV=production myapp
docker run --env-file .env myapp        # load nhiều từ một tệp
```

```yaml
# trong docker-compose.yml
services:
  app:
    image: myapp
    environment:
      - DATABASE_URL=postgres://db:5432/app
    env_file: .env
```

Tuân theo các nguyên tắc **twelve-factor**, cấu hình đến từ **môi trường** (biến env) tại runtime — nên CÙNG một image chạy trong dev, staging và production với cấu hình khác nhau, không bao giờ rebuild theo từng môi trường.

## Secret: KHÔNG nhúng chúng vào image

```text
⚠️ KHÔNG BAO GIỜ đặt secret (mật khẩu, API key, token) trong Dockerfile hoặc các layer image:
  → các layer image có thể kiểm tra được → secret có thể bị TRÍCH XUẤT (ngay cả khi "xóa" sau,
    chúng vẫn còn trong các layer trước đó)
  → bất kỳ ai có image đều có được secret
→ Đây là một sai lầm bảo mật nghiêm trọng, phổ biến.
```

## Xử lý secret đúng cách

```text
✓ Biến môi trường tại RUNTIME (tốt hơn image, nhưng hiển thị trong inspect/env)
✓ DOCKER SECRET (Swarm) / Kubernetes Secret — được mount an toàn tại runtime
✓ Các trình QUẢN LÝ secret — HashiCorp Vault, AWS Secrets Manager, v.v. (lấy tại runtime)
✓ BuildKit build secret (--secret) — cho các secret tại thời điểm build mà không nhúng vào layer
✓ Giữ các tệp .env NGOÀI kiểm soát phiên bản (.gitignore) và ngoài image (.dockerignore)
```

## Tại sao điều này quan trọng

Xử lý cấu hình và secret đúng cách trong Docker là quan trọng cho cả **bảo mật** và **sự linh hoạt vận hành**, vì vậy đó là kiến thức thực tế có giá trị.

Nguyên tắc cấu hình — cung cấp config qua **biến môi trường tại runtime** thay vì nhúng nó vào image (tuân theo các nguyên tắc twelve-factor) — là quan trọng vì nó cho phép **cùng một image chạy qua tất cả các môi trường** (dev, staging, production) với cấu hình khác nhau, không bao giờ rebuild theo từng môi trường, điều này là nền tảng cho các triển khai tái tạo được, di động và là một thực hành containerization cốt lõi.

Quan trọng hơn, **xử lý secret** là một mối quan tâm bảo mật nghiêm trọng: quy tắc chính — **không bao giờ nhúng secret (mật khẩu, API key, token) vào image** — là thiết yếu vì các layer image có thể kiểm tra được và các secret được nhúng trong chúng có thể bị **trích xuất** (và vẫn còn trong các layer trước đó ngay cả khi "xóa" sau), nên bất kỳ ai có image đều có được secret; đây là một sai lầm phổ biến, nguy hiểm gây ra rò rỉ thông tin xác thực thực sự.

Hiểu **xử lý secret đúng cách** — biến môi trường tại runtime (tốt hơn, dù hiển thị trong inspect), các cơ chế secret chuyên dụng (Docker/Kubernetes Secret được mount an toàn, các trình quản lý secret như Vault hoặc AWS Secrets Manager được lấy tại runtime, BuildKit build secret cho các nhu cầu tại thời điểm build), và giữ các tệp `.env` ngoài kiểm soát phiên bản và image — là cần thiết để quản lý secret một cách an toàn.

Vì chạy cùng một image qua các môi trường (qua config dựa trên env) và bảo vệ secret (không bao giờ nhúng chúng vào image) đều quan trọng cho các triển khai container hóa an toàn, linh hoạt, và vì xử lý secret sai là một thất bại bảo mật nghiêm trọng, phổ biến, hiểu việc xử lý cấu hình và secret trong Docker — config dựa trên môi trường và quản lý secret đúng cách — là kiến thức có giá trị, quan trọng thực tế để triển khai container một cách an toàn và linh hoạt, với khía cạnh secret đặc biệt là kiến thức bảo mật quan trọng ngăn ngừa việc lộ thông tin xác thực thực sự.