Login

Quản lý secrets trong CI/CD: đừng để lộ mật khẩu lên Git

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Một trong những sự cố phổ biến nhất của lập trình viên là vô tình đẩy khóa API hay mật khẩu database lên kho mã công khai. Bot quét kho mã hoạt động liên tục và có thể phát hiện chúng chỉ sau thời gian rất ngắn. Bài này giúp bạn quản lý bí mật đúng cách trong quy trình CI/CD.

Secret là gì?

Secret là mọi giá trị mà ai biết nó có thể làm hại hệ thống: mật khẩu database, khóa API, token truy cập, khóa riêng SSH, chứng chỉ, chuỗi ký tự dùng để ký phiên đăng nhập. Quy tắc vàng: secret không bao giờ nằm trong mã nguồn.

Những chỗ secret hay bị rò rỉ

  • File .env bị commit nhầm.
  • Ghi cứng giá trị trong mã nguồn hoặc file cấu hình.
  • In biến môi trường ra log của pipeline.
  • Đóng gói secret vào image Docker (kể cả trong lớp đã xóa vẫn có thể lấy lại).
  • Dán đoạn lỗi có chứa token vào diễn đàn hoặc nhóm chat.

Cách lưu secret trong công cụ CI

Mọi nền tảng CI/CD phổ biến đều có chỗ lưu secret được mã hóa:

  • GitHub Actions: Secrets trong phần Settings của kho mã.
  • GitLab CI/CD: Variables, có tùy chọn masked và protected.
  • Jenkins: Credentials.

Trong pipeline, bạn tham chiếu chúng qua biến, không bao giờ viết giá trị thật:

- name: Deploy
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}

Nền tảng sẽ tự che giá trị đã biết trong log, nhưng đừng dựa hoàn toàn vào điều đó. Tránh các lệnh như echo $API_TOKEN hoặc in toàn bộ biến môi trường.

Giữ .env ngoài Git

Thêm vào .gitignore:

.env
.env.*
!.env.example

Đồng thời giữ một file .env.example chứa tên biến với giá trị giả để đồng đội biết cần khai báo những gì. Việc này vừa an toàn vừa giúp tài liệu hóa cấu hình.

Nguyên tắc quyền tối thiểu

  1. Tạo khóa riêng cho từng mục đích, đừng dùng chung một khóa quyền lực cho mọi thứ.
  2. Cấp quyền vừa đủ: khóa chỉ để triển khai không cần quyền xóa tài nguyên khác.
  3. Tách khóa theo môi trường: staging và production dùng secret khác nhau.
  4. Giới hạn secret production chỉ dùng được ở nhánh được bảo vệ.
  5. Đặt thời hạn và xoay vòng khóa định kỳ nếu có thể.

Nếu lỡ lộ secret thì làm gì?

Xóa commit khỏi lịch sử Git không đủ, vì giá trị có thể đã bị sao chép. Hãy làm theo thứ tự sau:

  1. Thu hồi và tạo secret mới ngay lập tức. Đây là bước quan trọng nhất.
  2. Kiểm tra nhật ký truy cập xem khóa cũ có bị lạm dụng không.
  3. Gỡ secret khỏi lịch sử mã nguồn bằng công cụ chuyên dụng nếu cần.
  4. Rút kinh nghiệm: thêm bước quét secret vào pipeline.

Tự động phát hiện secret

Có các công cụ quét mã nguồn tìm chuỗi giống khóa hoặc mật khẩu, và nhiều nền tảng có sẵn tính năng này. Bạn cũng có thể dùng pre-commit hook chạy trên máy trước khi commit. Hàng rào tự động luôn đáng tin hơn trí nhớ con người.

Công cụ quản lý secret chuyên dụng

Khi hệ thống lớn dần, có thể dùng dịch vụ quản lý bí mật của nhà cung cấp cloud hoặc các công cụ chuyên dụng. Ứng dụng lấy secret lúc chạy thay vì được nhúng sẵn. Với dự án nhỏ, secret của nền tảng CI cộng với biến môi trường trên máy chủ là điểm khởi đầu hợp lý.

Kết luận

Hãy coi secret như chìa khóa nhà: không dán lên tường. Không commit, không in log, cấp quyền tối thiểu, và biết cách xoay vòng khi sự cố xảy ra. Thói quen này tốn ít công mà tránh được thiệt hại lớn.

Muốn học cách bảo mật quy trình triển khai trong các dự án thực tế, bạn có thể xem khóa học DevOps trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment