ConfigMap vs Secret: Quản Lý Biến Môi Trường Và Bảo Mật Dữ Liệu

Nguyên tắc thứ 3 trong bộ quy chuẩn The Twelve-Factor App chỉ rõ: "Lưu trữ cấu hình trong môi trường, tách biệt hoàn toàn code và cấu hình". Trong Kubernetes, hai đối tượng chịu trách nhiệm thực thi việc này là ConfigMap và Secret.

1. ConfigMap: Lưu trữ cấu hình không nhạy cảm

Dùng để lưu các biến môi trường thông thường, file cấu hình nginx.conf, timeout, URL endpoint của các dịch vụ khác.
- Dữ liệu lưu dưới dạng plaintext.
- Có thể inject vào Pod dưới dạng:
1. Biến môi trường (env / envFrom).
2. File cấu hình gắn vào thư mục thông qua Volume (mountPath).

Ví dụ ConfigMap dạng Volume:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  nginx.conf: |
    server {
        listen 80;
        server_name api.vibedevops.net;
    }

2. Secret: Lưu trữ thông tin nhạy cảm và sự thật về Base64

Secret sinh ra để chứa: Mật khẩu database, Private key SSH, API Secret Token, TLS Certificate.

Sự thật trần trụi về Kubernetes Secret mặc định:

Rất nhiều người lầm tưởng Secret trong K8s được mã hóa an toàn. Thực tế KHÔNG PHẢI VẬY!
- Mặc định, Secret chỉ được mã hóa Base64 (chỉ là encoding, ai cũng có thể giải mã bằng lệnh echo -n '...' | base64 -d).
- Dữ liệu Secret được lưu nguyên vẹn vào etcd. Nếu ai đó có quyền truy cập etcd hoặc quyền kubectl get secrets, họ sẽ đọc được toàn bộ mật khẩu!

3. Cách bảo mật Secret chuẩn Production (DevSecOps)

Bật Encryption at Rest trong etcd: Cấu hình KMS (Key Management Service) của AWS/GCP để etcd tự động mã hóa dữ liệu Secret bằng thuật toán AES-CBC trước khi ghi xuống đĩa.
Sử dụng External Secrets Operator (ESO): Không lưu mật khẩu trong git hay file yaml K8s. Đồng bộ trực tiếp từ các kho bí mật chuyên dụng:
- HashiCorp Vault
- AWS Secrets Manager
- Google Secret Manager
Dùng Sealed Secrets: Mã hóa Secret bằng khoá bất đối xứng (Asymmetric encryption) để có thể an tâm commit file .yaml vào Git theo mô hình GitOps.