Proxy GitHub Actions: Lưu Secrets và cấu hình CI/CD an toàn

Khi workflow cần truy cập kho gói nội bộ hoặc gửi lưu lượng qua điểm kết nối được kiểm soát, proxy GitHub Actions trở thành một phần của hạ tầng CI/CD. Tuy nhiên, đặt mật khẩu trực tiếp trong YAML, in cấu hình để chẩn đoán hoặc dùng chung tài khoản giữa nhiều dự án đều có thể làm lộ thông tin xác thực.

Cách triển khai phù hợp là lưu dữ liệu nhạy cảm trong GitHub Actions Secrets, chỉ cung cấp cho bước cần sử dụng và kiểm soát mã nguồn được phép chạy cùng secret. Bài viết trình bày cách tổ chức, cấu hình và vận hành proxy theo nguyên tắc đặc quyền tối thiểu.

Vì sao thông tin xác thực proxy cần được bảo vệ?

Tài khoản proxy có thể cho phép sử dụng dịch vụ mạng, tiếp cận tài nguyên nội bộ hoặc tạo lưu lượng dưới danh nghĩa tổ chức. Khi thông tin này bị lộ, rủi ro không chỉ nằm ở chi phí sử dụng mà còn liên quan đến phạm vi truy cập được cấp cho proxy.

Trong CI/CD, secret có thể xuất hiện ngoài dự kiến qua thông báo lỗi, chế độ gỡ lỗi, tệp cấu hình, cache hoặc artifact. Vì vậy, bảo mật mật khẩu proxy phải bao gồm cả nơi lưu trữ, cách truyền cho ứng dụng và cách xử lý dữ liệu sau khi chạy.

Chọn phạm vi lưu GitHub Actions Secrets

Chọn phạm vi lưu secret theo nhu cầu và chỉ cấp quyền cho repository hoặc môi trường cần sử dụng.

Repository secrets cho cấu hình riêng của dự án

Repository secrets phù hợp khi thông tin xác thực chỉ phục vụ một repository. Người có quyền quản lý truy cập phần Settings → Secrets and variables → Actions để tạo secret. Không đặt mật khẩu trong tệp workflow hoặc commit tệp cấu hình đã điền sẵn thông tin đăng nhập.

Environment secrets cho từng môi trường triển khai

Nếu quy trình có môi trường kiểm thử và sản xuất, nên dùng tài khoản proxy riêng cùng environment secrets tương ứng. Job phải khai báo environment phù hợp để sử dụng các secret này.

Kết hợp với quy tắc bảo vệ environment, chẳng hạn yêu cầu phê duyệt hoặc giới hạn nhánh triển khai, giúp kiểm soát thời điểm cấp secret. Khả năng áp dụng từng quy tắc phụ thuộc gói dịch vụ và loại repository.

Organization secrets cho nhu cầu dùng chung

Organization secrets hỗ trợ quản lý tập trung nhưng cần giới hạn repository được truy cập. Không nên chia sẻ tài khoản proxy rộng hơn nhu cầu thực tế. Tài khoản riêng cho từng nhóm công việc giúp thu hồi quyền và điều tra sự cố rõ ràng hơn.

Tổ chức thông tin proxy trước khi lưu

Một bộ cấu hình thường gồm địa chỉ máy chủ, cổng, tên đăng nhập, mật khẩu và danh sách đích không đi qua proxy. Có thể đặt tên như sau:

• PROXY_HOST: địa chỉ máy chủ proxy.
• PROXY_PORT: cổng kết nối do đơn vị quản trị cung cấp.
• PROXY_USERNAME: tên tài khoản dành cho CI/CD.
• PROXY_PASSWORD: mật khẩu của tài khoản.
• NO_PROXY: danh sách đích cần kết nối trực tiếp, nếu được chính sách mạng cho phép.

Mật khẩu phải được lưu dưới dạng secret. Host và cổng có thể dùng GitHub Actions Variables nếu không nhạy cảm; nếu chúng tiết lộ cấu trúc mạng nội bộ, cần bảo vệ tương ứng. Không dùng Variables để lưu thông tin xác thực.

Một lựa chọn khác là lưu toàn bộ URL xác thực trong secret PROXY_URL. Cách này giảm thao tác ghép chuỗi nhưng khiến toàn bộ URL trở thành dữ liệu nhạy cảm. Chọn phương án dựa trên yêu cầu của công cụ và quy trình xoay vòng thông tin xác thực.

Cách tạo secret và đưa vào workflow

Tạo secret ở đúng phạm vi

1. Xác định repository, environment hoặc nhóm repository cần sử dụng proxy.
2. Mở trang quản lý Actions secrets tại phạm vi tương ứng.
3. Tạo secret với tên nhất quán, dễ nhận diện.
4. Nhập giá trị thực tế và lưu; không đưa mật khẩu vào mô tả hoặc tài liệu hướng dẫn.
5. Kiểm tra chính sách truy cập trước khi chạy workflow.

Sau khi lưu, không thể đọc lại giá trị secret qua giao diện quản lý thông thường. Vì vậy, cần có nguồn quản lý thông tin xác thực được phê duyệt để phục vụ cập nhật và thu hồi, thay vì phụ thuộc vào ghi chú cá nhân.

Ánh xạ secret vào biến môi trường của step

Ánh xạ secret qua env ở cấp step để chỉ bước thực sự cần proxy nhận được thông tin xác thực.

Trong workflow YAML, dùng mục env để ánh xạ biến của step tới biểu thức secret. Ví dụ, giá trị của biến PROXY_PASSWORD là ${{ secrets.PROXY_PASSWORD }}. Nếu lưu URL hoàn chỉnh, công cụ hỗ trợ biến HTTP_PROXY hoặc HTTPS_PROXY có thể nhận giá trị từ ${{ secrets.PROXY_URL }}.

Ưu tiên khai báo ở cấp step thay vì toàn workflow. Khi chỉ bước tải dependency cần proxy, bước kiểm thử hoặc đóng gói không nên nhận mật khẩu. Khai báo ở cấp job chỉ khi các bước trong job thực sự cần cùng quyền truy cập.

Không chèn trực tiếp biểu thức secret vào nội dung shell trong run. Ánh xạ qua env rồi tham chiếu biến bằng cú pháp của shell giúp tránh việc giá trị bí mật bị diễn giải như một phần của câu lệnh. Vẫn phải đặt biến trong dấu nháy phù hợp và không dùng cơ chế đánh giá lại chuỗi lệnh.

Cấu hình proxy CI/CD đúng theo công cụ

Không phải ứng dụng nào cũng đọc cùng biến môi trường

Nhiều công cụ hỗ trợ HTTP_PROXY, HTTPS_PROXY và NO_PROXY, nhưng cách nhận tên biến viết hoa, viết thường hoặc cách xử lý danh sách loại trừ có thể khác nhau. Một số trình quản lý gói và công cụ build yêu cầu cấu hình riêng.

Vì vậy, cấu hình proxy CI/CD cần dựa trên tài liệu của từng công cụ. Nếu phải đặt cả biến viết hoa và viết thường để tương thích, hãy giữ giá trị nhất quán và chỉ cung cấp trong phạm vi cần thiết.

Xử lý ký tự đặc biệt trong thông tin đăng nhập

Khi username hoặc password được đặt trong URL, các ký tự như dấu @, dấu hai chấm hoặc dấu gạch chéo có thể làm thay đổi cách phân tích địa chỉ. Cần mã hóa phần thông tin đăng nhập theo quy tắc URL, không mã hóa tùy tiện toàn bộ chuỗi.

Giá trị sau mã hóa vẫn là bí mật. Không in URL đã ghép để kiểm tra vì cơ chế che secret không bảo đảm nhận diện mọi dạng biến đổi. Nếu công cụ hỗ trợ trường username và password riêng, nên cân nhắc sử dụng để giảm lỗi xử lý URL.

Giữ nguyên kiểm tra chứng chỉ TLS

Biến HTTPS_PROXY thường chỉ proxy phục vụ yêu cầu tới đích HTTPS; tên biến không tự bảo đảm kết nối tới proxy được mã hóa. Cần xác nhận giao thức kết nối và cơ chế xác thực mà máy chủ hỗ trợ.

Nếu tổ chức dùng CA nội bộ, hãy cài chứng chỉ tin cậy theo hướng dẫn của công cụ. Không tắt xác minh TLS để xử lý nhanh lỗi kết nối. Thông tin xác thực cũng cần được bảo vệ trên đường truyền tới proxy, đặc biệt khi dùng cơ chế xác thực không tự mã hóa mật khẩu.

Ngăn rò rỉ mật khẩu qua log và dữ liệu đầu ra

GitHub Actions có cơ chế che secret trong log, nhưng đây không phải bảo đảm toàn diện. Giá trị bị mã hóa, chia nhỏ hoặc biến đổi có thể không được nhận diện như giá trị ban đầu.

• Không in toàn bộ biến môi trường bằng các lệnh như env hoặc printenv trong bước có secret.
• Không bật shell tracing như set -x khi thao tác với thông tin xác thực.
• Hạn chế chế độ verbose có thể hiển thị URL, header hoặc cấu hình kết nối.
• Không đưa mật khẩu vào tên artifact, output của job hoặc phần tóm tắt workflow.
• Không tải lên artifact hay lưu cache chứa tệp cấu hình proxy có mật khẩu.

Nếu phải tạo giá trị nhạy cảm mới trong lúc chạy, có thể đăng ký che bằng lệnh workflow add-mask trước khi giá trị xuất hiện trong log. Biện pháp chính vẫn là không ghi bí mật ra đầu ra, thay vì trông chờ vào việc che sau đó.

Kiểm soát workflow nào được sử dụng secret

Không cấp secret cho mã nguồn chưa đáng tin cậy

Pull request từ fork thường không được nhận Actions secrets trong các sự kiện thông thường. Không nên thay đổi luồng thực thi chỉ để cấp mật khẩu proxy cho bài kiểm thử từ nguồn chưa được tin cậy.

Đặc biệt thận trọng với pull_request_target: sự kiện này chạy trong ngữ cảnh repository đích. Việc checkout rồi thực thi mã từ pull request trong job có quyền truy cập secret có thể làm lộ thông tin xác thực. Hãy tách kiểm tra mã bên ngoài khỏi công việc cần bí mật.

Rà soát action, script và workflow tái sử dụng

Bất kỳ action hoặc script nào nhận secret đều có khả năng đọc và gửi giá trị đó ra ngoài. Cần đánh giá nguồn gốc action, ghim phiên bản phù hợp với chính sách tổ chức và giới hạn người được sửa workflow.

Với reusable workflow, chỉ truyền những secret cần thiết. Tránh kế thừa toàn bộ khi không có nhu cầu rõ ràng. Đồng thời đặt quyền GITHUB_TOKEN ở mức tối thiểu; quyền token và quyền sử dụng mật khẩu proxy là hai phạm vi cần kiểm soát riêng.

Quản lý runner và tệp cấu hình tạm

Kết hợp cô lập runner, dọn tệp tạm và build secret để hạn chế mật khẩu tồn tại sau khi chạy.

Biến môi trường không thay thế việc cô lập runner. Tiến trình con có thể kế thừa biến, còn mã chạy cùng quyền có thể tiếp cận dữ liệu trong quá trình thực thi. Self-hosted runner cần đặc biệt chú ý vì trạng thái có thể tồn tại giữa các job.

Nếu ứng dụng bắt buộc đọc tệp cấu hình, hãy tạo tệp trong thư mục tạm, giới hạn quyền đọc theo hệ điều hành và xóa sau khi dùng. Bước dọn dẹp nên chạy cả khi công việc thất bại. Không coi dọn dẹp là biện pháp duy nhất vì runner có thể bị gián đoạn.

Đối với Docker build, không truyền mật khẩu bằng ARG hoặc ghi vào ENV trong Dockerfile để phục vụ bước tải gói. Ưu tiên cơ chế build secret phù hợp, đồng thời kiểm tra để mật khẩu không được ghi vào layer, cache hoặc image cuối cùng.

Xoay vòng thông tin xác thực và xử lý sự cố

Tài khoản proxy dùng trong CI/CD nên tách khỏi tài khoản cá nhân và chỉ có phạm vi cần thiết. Nếu dịch vụ hỗ trợ, hãy giới hạn đích truy cập, nguồn kết nối hoặc sử dụng thông tin xác thực thời hạn ngắn phù hợp với mô hình runner.

Khi đổi mật khẩu, cập nhật secret đúng phạm vi và chạy tác vụ kiểm tra trong ngữ cảnh đáng tin cậy. Tác vụ chỉ nên báo kết quả kết nối hoặc nhóm lỗi, không hiển thị thông tin đăng nhập. Thu hồi thông tin cũ theo quy trình đã thống nhất.

Nếu nghi ngờ rò rỉ, ưu tiên thu hồi hoặc thay đổi thông tin xác thực. Sau đó rà soát log, artifact, cache và lịch sử truy cập. Xóa dòng log không đủ để bảo đảm bí mật chưa bị sao chép.

Checklist trước khi vận hành

• Lưu mật khẩu trong GitHub Actions Secrets, không nằm trong mã nguồn.
• Chọn đúng phạm vi repository, environment hoặc organization.
• Chỉ cấp secret cho step và mã nguồn đáng tin cậy.
• Kiểm tra cách công cụ đọc biến proxy và xử lý ký tự đặc biệt.
• Giữ xác minh TLS và kiểm soát chứng chỉ tin cậy.
• Loại thông tin xác thực khỏi log, artifact, cache và image.
• Chuẩn bị quy trình xoay vòng, thu hồi và điều tra sự cố.

Proxy GitHub Actions an toàn không chỉ là lưu mật khẩu trong Secrets. Hiệu quả bảo vệ phụ thuộc vào toàn bộ vòng đời sử dụng: cấp quyền đúng phạm vi, truyền dữ liệu đúng cách, kiểm soát mã thực thi và thu hồi kịp thời. Khi các nguyên tắc này được áp dụng đồng bộ, cấu hình proxy CI/CD sẽ dễ quản lý và kiểm tra hơn.