Hướng dẫn Setup Jenkins cho hệ thống Monolith - Bài 28: Thiết lập cơ chế Phân quyền (Role-based Access Control) cho đội ngũ phát triển
Sau khi hoàn thiện quy trình tự động Deploy và Rollback ở Bài 26 và 27, máy chủ Jenkins của bạn lúc này thực sự đã trở thành "trái tim quyền lực" của toàn bộ hạ tầng công ty. Nó nắm giữ toàn bộ SSH Private Keys của máy chủ Production, mật khẩu cơ sở dữ liệu, API Token và quyền đóng gói/phát hành ứng dụng Monolith.
Nhưng chuyện gì sẽ xảy ra nếu tất cả 20 thành viên trong đội dự án (từ thực tập sinh, Junior Dev, QA/QC cho đến Tech Lead) đều dùng chung một tài khoản admin hoặc ai đăng nhập vào cũng có quyền bấm nút monolith-emergency-rollback trên Production? Một cú click chuột nhầm lẫn của thực tập sinh lúc 3 giờ chiều có thể làm gián đoạn dịch vụ của hàng chục nghìn khách hàng.
Bài học hôm nay sẽ hướng dẫn bạn xây dựng bức tường quản trị định danh và phân quyền chặt chẽ dựa trên vai trò (RBAC - Role-Based Access Control) thông qua plugin Role-based Authorization Strategy.
1. Ma trận phân quyền chuẩn thực tế cho đội ngũ phát triển Monolith
Trong một dự án Monolith tiêu chuẩn, chúng ta không phân quyền lắt nhắt cho từng cá nhân mà chia theo 4 nhóm vai trò (Roles) cốt lõi, kết hợp với quy tắc đặt tên Job theo tiền tố (Prefix Naming Convention):
Nhóm vai trò (Role) |
Quyền hạn trên Hệ thống (Global) |
Quyền hạn trên các Job cụ thể (Item Roles) |
Quyền đối với Credentials |
|---|---|---|---|
| 1. DevOps / SysAdmin | Toàn quyền (Overall/Administer). Cấu hình System, Plugins, Nodes. |
Toàn quyền trên mọi Job (.*). |
Tạo, sửa, xóa mọi khóa bí mật. |
| 2. Tech Lead / Release Manager | Chỉ xem giao diện chung (Overall/Read). |
Xem, Build, Cancel và bấm Approve các Job Production (^monolith-prod-.*, ^monolith-emergency-.*) cũng như Staging/Dev. |
Không được phép xem hay sửa khóa bí mật. |
| 3. Backend / Frontend Developer | Chỉ xem giao diện chung (Overall/Read). |
Chỉ có quyền Xem log và bấm Build các Job thuộc môi trường Dev (^monolith-dev-.*) và CI Test (^monolith-ci-.*). Chỉ được Xem Job Production (không thấy nút Build!). |
Không có quyền truy cập. |
| 4. QA / QC (Tester) | Chỉ xem giao diện chung (Overall/Read). |
Toàn quyền Build và truyền tham số test trên các Job Staging / UAT (^monolith-staging-.*) và chạy bộ Automation Test. |
Không có quyền truy cập. |
2. Cài đặt và kích hoạt Role-based Authorization Strategy Plugin
Mặc định Jenkins chỉ cung cấp chế độ phân quyền rất thô sơ (Logged-in users can do anything hoặc Matrix-based). Để quản lý theo nhóm và lọc Job bằng biểu thức chính quy (Regex), bạn thực hiện theo các bước sau:
Bước 1: Cài đặt Plugin
-
Trên giao diện Jenkins, truy cập Manage Jenkins -> Plugins -> Available plugins.
-
Tìm kiếm từ khóa: Role-based Authorization Strategy.
-
Tích chọn và bấm Install.
Bước 2: Kích hoạt chế độ Role-Based Strategy
-
Truy cập Manage Jenkins -> Security.
-
Tại mục Security Realm (Nguồn xác thực người dùng): Chọn Jenkins’ own user database (Lưu ý: Bỏ tích ô Allow users to sign up để ngăn người lạ tự tạo tài khoản).
-
Tại mục Authorization (Cơ chế phân quyền): Chuyển từ chế độ mặc định sang Role-Based Strategy.
-
Bấm Save để lưu lại. (Lúc này, khi quay lại trang Manage Jenkins, bạn sẽ thấy xuất hiện thêm một biểu tượng chiếc khiên mới tên là Manage and Assign Roles nằm trong nhóm Security).
3. Thiết lập Global Roles và Item Roles (Kèm công thức Regex)
Hãy truy cập vào Manage Jenkins -> Manage and Assign Roles -> Chọn Manage Roles. Tại đây có 2 phần quan trọng nhất bạn cần cấu hình:
Phần A: Cấu hình Global roles (Quyền truy cập nền tảng)
Mọi người dùng muốn nhìn thấy giao diện Jenkins sau khi đăng nhập đều bắt buộc phải có quyền Overall -> Read ở cấp độ Global.
-
Giữ nguyên role
adminmặc định (đã tích sẵn toàn bộ các ô). -
Tại ô Role to add, nhập tên
authenticated_membervà bấm Add. -
Trên dòng
authenticated_member, bạn chỉ tích duy nhất 1 ô là Overall -> Read (nằm ở cột đầu tiên bên trái).
Phần B: Cấu hình Item roles (Quyền hạn chi tiết theo từng nhóm Job của Monolith)
Để Item Roles phát huy sức mạnh, bạn nên quy hoạch tên các Job (hoặc tên Folder) của dự án Monolith theo chuẩn tiền tố rõ ràng:
-
monolith-dev-pipeline -
monolith-staging-pipeline -
monolith-prod-pipeline -
monolith-emergency-rollback
Tại mục Item roles, hãy lần lượt thêm 3 nhóm quyền với công thức Pattern (Biểu thức chính quy - Regex) như sau:
Nhóm vai trò (Role Name) |
Biểu thức Regex khớp tên Job (Pattern) |
Các ô quyền cần tích chọn trong bảng (Permissions) |
Giải thích ý nghĩa |
|---|---|---|---|
| role_developer | ^monolith-(dev|ci)-.* |
Job: Build, Cancel, Read, Workspace | Lập trình viên được phép chạy, hủy và xem log các Job có tên bắt đầu bằng monolith-dev- hoặc monolith-ci-. |
| role_qa_staging | ^monolith-staging-.* |
Job: Build, Cancel, Read | QA/QC được phép bấm chạy và kiểm tra các bản dựng trên môi trường Staging. |
| role_techlead_prod | ^monolith-(prod|emergency)-.* |
Job: Build, Cancel, Configure, Read Run: Replay, Update |
Tech Lead có quyền kích hoạt deploy Production, chạy lại (Replay) Pipeline và bấm nút Emergency Rollback. |
| role_prod_viewer | ^monolith-prod-.* |
Job: Chỉ tích duy nhất ô Read | Cấp cho Developer để họ vào xem được tiến độ và Console Log của bản build Production nhưng không có nút Build hay Cancel. |
All rights reserved