Quản lý secret – Vault, SOPS, ansible-vault, biến môi trường

Secret là mọi thứ cho phép truy cập: mật khẩu thiết bị, TACACS+ key, API token NetBox/Cloudflare, private key TLS/SSH, chuỗi kết nối DB. Mục tiêu không chỉ là "mã hoá" mà là trả lời được: ai đọc được, đọc ở đâu, xoay vòng thế nào, lộ thì biết không.

Các mô hình lưu secret#

flowchart LR
  K["age key / KMS / vault password"] --> A["File mã hoá trong Git (SOPS, ansible-vault)"]
  A -->|"giải mã lúc chạy"| B["Env / file tmpfs"]
  V["Vault / secret manager"] -->|"API + auth, lease"| B
  B --> P["Playbook, app, CI job"]

Hai trường phái:

• Encrypted-in-Git (SOPS, ansible-vault): secret mã hoá nằm cùng code, review qua PR, không cần server. Bài toán chuyển thành bảo vệ một key giải mã.
• Secret store tập trung (HashiCorp Vault/OpenBao, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault): app lấy secret qua API lúc chạy, có audit log, có thể cấp dynamic secret (credential sinh ra theo yêu cầu, tự hết hạn).

So sánh#

Nguyên tắc chung#

• Không commit plaintext, kể cả repo private. Bật gitleaks trong pre-commit để chặn từ máy dev.
• Biến môi trường là kênh truyền, không phải nơi lưu: chúng lộ qua /proc/<pid>/environ, crash dump, log debug, docker inspect. Ưu tiên file mount 0600 hoặc tmpfs cho secret nhạy cảm.
• Một secret, một mục đích: token riêng cho từng tool/môi trường, quyền tối thiểu, để khi lộ chỉ cần thu hồi đúng một cái.
• Có quy trình xoay vòng trước khi cần đến nó. Secret không xoay được là rủi ro tồn đọng.
• Key giải mã (age private key, vault password, KMS IAM) là secret quan trọng nhất: để trong password manager / CI secret, không nằm cạnh repo.
• Log và output của automation phải che giá trị bí mật (Ansible no_log: true, CI masked variables).

Khi nào dùng gì#