Authorization & RBAC

Jenkins là một hệ thống thực thi code, không chỉ là nơi xem trạng thái CI. Một người có thể sửa job, Jenkinsfile hoặc agent có thể biến quyền đó thành đường chạy code với identity và credential mà job nhận được. Vì vậy, RBAC hiệu quả bắt đầu từ scope hẹp nhất và được chứng minh bằng test deny/allow, không phải bằng tên role nghe có vẻ an toàn.

Mục lụcCopy Anchor Link

• Mô hình authorization của Jenkins
  • Security realm khác authorization strategy
  • Nhóm permission và ý nghĩa của Overall
  • Cây quyết định cấp quyền
• Matrix Authorization Strategy
  • Ma trận global và project based
  • Kế thừa và anonymous access
  • Mẫu ma trận để thảo luận
• Role Strategy
  • Global item và agent roles
  • Regex pattern và role overlap
  • Mẫu role không cấp quyền production
• Folder permissions và ranh giới thực tế
  • Kế thừa theo folder
  • Folder không tự bảo vệ secret
• Rà soát permission theo least privilege
  • Ma trận persona scope và evidence
  • Separation of duties và break glass
  • Thay đổi audit và offboarding
• Lab loopback kiểm thử policy
  • Điều kiện và guard
  • Snapshot thay đổi và rollback
  • Thiết kế test matrix
  • Thực hiện test allow deny
  • Dọn lab và ghi evidence
• Checklist review trước khi áp dụng
• Tự kiểm tra
• Nguồn Jenkins và plugin chính thức
• Đọc tiếp

Mô hình authorization của JenkinsCopy Anchor Link

Security realm khác authorization strategyCopy Anchor Link

Security realm trả lời ai đang đăng nhập: nó xác thực user và, tùy cơ chế, cung cấp group membership từ Jenkins user database, LDAP, Active Directory hoặc identity provider. Authorization strategy trả lời danh tính đó được làm gì trên object nào: nó đánh giá permission, như Job/Read, với user hoặc group hiện tại và resource được yêu cầu.

Hai lớp có thể độc lập. Ví dụ, LDAP có thể là security realm còn Matrix Authorization Strategy là authorization strategy. Đổi group mapping trong realm có thể làm quyền hiệu lực thay đổi dù matrix không đổi; đổi matrix có thể từ chối user vẫn đăng nhập thành công. Khi điều tra 403, kiểm tra identity và group đã nhận trước, rồi mới kiểm tra strategy, permission và scope.

Nhóm permission và ý nghĩa của OverallCopy Anchor Link

Permission Jenkins được kiểm tra trên object và scope liên quan. Tên nhóm là bản đồ để review, không phải danh sách quyền tự động nên cấp cùng nhau.

Ba permission Overall thường bị diễn giải sai:

• Overall/Read là nền tảng để dùng phần lớn Jenkins và API của object user được phép truy cập. Nó không tự cấp Job/Read, Job/Build, Credentials hay quyền thay đổi cấu hình. Một số URL tối thiểu vẫn có thể tồn tại không cần Overall/Read; extension hoặc plugin phải tự kiểm tra server-side cho thao tác nhạy cảm.
• Overall/Manage cho phép một tập con tác vụ quản trị. Nó không tự suy ra mọi permission khác, và tính năng/plugin có thể chưa hỗ trợ nó. Một chức năng có thể cho phép user Manage chạm dữ liệu thường bị permission khác bảo vệ, nên cấp nó theo task đã kiểm thử, không coi là “admin an toàn”.
• Overall/Administer là đặc quyền toàn diện: có thể cài plugin hoặc dùng Script Console để chạy code. Một instance bị user không tin cậy có quyền này phải được coi là đã compromise; rotate/revoke secret liên quan và điều tra theo incident process. Không cấp nó rộng để xử lý 403 hoặc làm một plugin hoạt động.

Job/Configure, Job/Create, quyền thay đổi agent, permission plugin và quyền dùng credential đều có thể là đặc quyền gián tiếp. Permission chính xác, implication và object scope phải được tra trong Permissions của Jenkins core và UI của instance; plugin có thể bổ sung hoặc đổi behavior.

Cây quyết định cấp quyềnCopy Anchor Link

Dùng cây này cho từng yêu cầu, thay vì bắt đầu bằng role có sẵn:

direction: down
A: "Yêu cầu capability"
B: "Danh tính và group đã xác minh?" {
  shape: diamond
}
C: "Kiểm tra security realm và\nmapping"
D: "Object và scope nhỏ nhất?" {
  shape: diamond
}
E: "Xác định folder job run agent\ncredential"
F: "Có thể sửa code hoặc cấu hình\nthực thi?" {
  shape: diamond
}
G: "Đánh giá agent credential SCM và\nblast radius"
H: "Chọn permission đọc hoặc thao\ntác tối thiểu"
I: "Có separation of duties hoặc\napproval độc lập?" {
  shape: diamond
}
J: "Thiết kế control trước khi cấp"
K: "Chọn strategy và scope hẹp"
L: "Test deny allow bằng user\nsandbox"
M: "Evidence và rollback đầy đủ?" {
  shape: diamond
}
N: "Không áp dụng"
O: "Phê duyệt thay đổi có thời hạn\nreview"

A -> B
B -> C: "Chưa"
B -> D: "Rồi"
D -> E: "Chưa rõ"
D -> F: "Đã rõ"
F -> G: "Có"
F -> H: "Không"
G -> I
I -> J: "Chưa"
I -> K: "Có"
H -> K
K -> L
L -> M
M -> N: "Không"
M -> O: "Có"

Cây này là review tĩnh. Nó không chứng minh plugin hoặc Jenkins runtime thực thi đúng policy. Nút hoặc permission UI bị ẩn chỉ là cách trình bày; endpoint và thao tác thay đổi trạng thái vẫn phải bị Jenkins/plugin kiểm tra server-side. Bước Test deny allow vẫn bắt buộc trên controller cô lập.

Matrix Authorization StrategyCopy Anchor Link

Matrix Authorization Strategy là plugin cung cấp authorization chi tiết theo permission. Nó phù hợp khi cần thấy rõ ô principal × permission và cần policy riêng cho item hoặc agent. Plugin là một dependency: kiểm tra version, dependency, advisory, compatibility với Jenkins core và schema/runtime của chính controller trước mỗi thay đổi.

Ma trận global và project basedCopy Anchor Link

Global matrix cấp permission ở toàn controller. Dùng nó thật tiết chế: Job/Read global mở rộng khả năng xem ra toàn bộ job, và Job/Create global có thể cho tạo item với tên bất kỳ tùy strategy/naming policy. Global matrix phù hợp hơn cho baseline thật sự toàn cục, như mức truy cập Jenkins cần cho một nhóm đã được review.

Project-based matrix cho phép cấu hình permission ở item hoặc agent. Với folder, policy có thể tác động folder và các child tùy inheritance đã chọn. Đây là công cụ để giới hạn team vào namespace riêng, không phải lý do để bỏ review quyền sửa job.

Một user có thể nhận quyền từ nhiều hàng principal hoặc nhiều scope. Cấp quyền thường có tính cộng dồn; đừng cố “deny” một role bằng cách bỏ tick ở role khác. Liệt kê toàn bộ direct assignment, group, global grant, parent folder và plugin-specific grant trước khi kết luận user không có quyền.

Kế thừa và anonymous accessCopy Anchor Link

Project-based matrix mặc định kế thừa global configuration và parent entity. Plugin có thể cung cấp các lựa chọn sau theo loại object:

Không cấp permission đáng kể cho anonymous hoặc authenticated chỉ vì lab cần mở nhanh. anonymous bao gồm người chưa đăng nhập; authenticated có thể gồm mọi account mà realm chấp nhận trong tương lai. Nếu dùng anonymous cho một endpoint/plugin cần thiết, giới hạn capability, xác minh server-side behavior, kiểm tra log truy cập và review lại khi cài plugin hay đổi realm.

Mẫu ma trận để thảo luậnCopy Anchor Link

Bảng dưới là mẫu review, không phải cấu hình để copy vào controller. team-alpha-sandbox là namespace giả trong lab; không có permission production, credential hoặc endpoint thật trong ví dụ.

Nếu maintainer có thể đổi Jenkinsfile, SCM definition, parameter, label hoặc credential binding, phạm vi thực tế rộng hơn một ô Job/Configure. Chỉ thêm quyền sau khi đã review code source, trust của agent, credential scope và hệ thống đích.

Role StrategyCopy Anchor Link

Role-based Authorization Strategy là plugin tạo role rồi gán role cho user/group từ security realm. Nó hỗ trợ global, item và agent roles. Chọn nó khi đội cần tái sử dụng tập permission theo persona, nhưng đừng coi tên role như enforcement: permission cuối cùng là union của role, assignment, scope và plugin behavior.

Global item và agent rolesCopy Anchor Link

Trong plugin này, permission đặt bằng global role áp dụng ở mọi item và có thể làm policy item role hẹp trở nên vô hiệu về mặt scope. Quyền Job/Create ở item role còn phụ thuộc Role-Based strategy cho Restrict project naming để giới hạn tên item được tạo một cách đáng tin cậy. Khi cấp Job/Create, plugin khuyến nghị xem xét cùng Job/Configure và Job/Read để user thao tác được item vừa tạo; đó là lý do phải đánh giá code-execution risk trước, không phải lời mời cấp cả ba ở production.

Regex pattern và role overlapCopy Anchor Link

Item/agent role dùng regex để khớp toàn bộ tên item. Pattern case-sensitive trừ khi dùng flag như (?i). Folder cần có quyền truy cập chính folder cha; một pattern chỉ khớp job con có thể không đủ để người dùng duyệt tới namespace đó.

Tránh regex quá rộng như .*, prefix thiếu anchor như team, hoặc pattern trùng nhiều team. Một item có thể khớp nhiều roles và permission giao nhau có thể cộng dồn. Khi một user “có quyền lạ”, kiểm tra tất cả group assignment, global role, item role và regex match thay vì chỉ xem role vừa sửa. UI highlight/tooltips hữu ích để quan sát, nhưng test bằng user thật ở sandbox mới xác nhận enforcement.

Mẫu role không cấp quyền productionCopy Anchor Link

Ví dụ chỉ đặt tên policy để review, không phải lệnh hay file cấu hình:

Tên lab-alpha-runner không tự hạn chế quyền; pattern và ô permission mới quyết định. Nếu plugin, naming strategy hoặc version không hỗ trợ behavior được kỳ vọng, dừng rollout và điều chỉnh sandbox, không mở Overall/Administer để “chữa” lỗi.

Folder permissions và ranh giới thực tếCopy Anchor Link

Folder tạo namespace cho job, Pipeline, view và một số cấu hình theo plugin. Khi strategy hỗ trợ ACL theo item, folder là scope tự nhiên để cấp quyền cho một team và kế thừa xuống child. Folder không tự tạo tenant isolation và cũng không tự chặn một grant global.

Kế thừa theo folderCopy Anchor Link

Trước khi đưa folder-based policy vào hiệu lực, trả lời cụ thể:

1. Ai có quyền vào folder? User cần permission để thấy/truy cập parent, không chỉ job con.
2. Child nhận gì? Ghi rõ strategy/inheritance đang dùng: parent + global, chỉ global, hay grant explicit. Kiểm tra folder lồng nhau từng cấp.
3. Ai tạo hoặc di chuyển item? Job/Create và Job/Move có thể phá giả định pattern/path. Với Role Strategy, kiểm tra naming strategy tương ứng; với Matrix, kiểm tra inheritance và object policy.
4. Global grant nào vẫn thắng về scope? Ghi cả role, group hoặc matrix global có Job/Read, Credentials hay permission liên quan.
5. Plugin nào thêm object hoặc permission? Multibranch, SCM, credentials store và folder plugin có thể thêm capability; chỉ tin behavior đã được kiểm thử với bộ plugin đang cài.

Nếu cân nhắc Folder-based Authorization Strategy, đọc trạng thái security advisory trên chính plugin page trước. Trang plugin hiện cảnh báo một lỗ hổng chưa được giải quyết; không đưa plugin đó vào controller chỉ để có mô hình folder. Matrix hoặc Role Strategy cũng không tự an toàn: tất cả plugin authorization cần inventory, advisory review, compatibility test và rollback.

Folder không tự bảo vệ secretCopy Anchor Link

Folder scope hữu ích để giới hạn object Jenkins, nhưng secret chỉ được bảo vệ khi credential store scope, permission Credentials, job/Pipeline configuration, agent isolation và authorization ở hệ thống đích cùng hẹp. Một job trong folder được phép dùng credential rộng, hoặc chạy trên agent có capability khác, vẫn có thể tạo đường đọc/đẩy dữ liệu ngoài folder.

Tương tự, label như trusted-release chỉ route scheduler; user có Job/Configure có thể đổi label hoặc Pipeline. Label không phải authorization và workspace/cache dùng chung không phải secret boundary. Tách pool/identity/filesystem/network theo trust tier, giới hạn ai sửa job và agent, rồi cấp credential đúng folder/job/stage. Đọc Labels & Executors và Kiến trúc Jenkins để đặt policy quyền trong ranh giới controller–agent thật.

Rà soát permission theo least privilegeCopy Anchor Link

Least privilege không phải “ít ô tick nhất” mà là capability nhỏ nhất đủ cho một nhiệm vụ, ở scope nhỏ nhất, với bằng chứng cho phép và từ chối. Rà soát định kỳ sau khi đổi team, SCM trust, plugin, agent pool, credential hoặc hệ thống đích.

Ma trận persona scope và evidenceCopy Anchor Link

Bảng này là điểm bắt đầu để review với owner; permission exact phải đối chiếu Jenkins/core plugin trên runtime.

Không suy ra quyền từ persona name. Ví dụ, maintainer không mặc định được đọc credential hay sửa agent; operator có Manage không mặc định có mọi quyền đọc/sửa khác. Khi UI không hiện permission mong đợi, xác minh plugin/core feature và version trước, rồi test server-side bằng sandbox.

Separation of duties và break glassCopy Anchor Link

Tách các quyết định có blast radius lớn khi tổ chức có đủ người và workflow:

• Người đề xuất quyền không là người duy nhất phê duyệt nếu quyền cho phép sửa job, dùng credential, thay agent hoặc quản trị controller.
• Owner workload review nhu cầu nghiệp vụ; Jenkins/platform owner review strategy, plugin và scope; security/identity owner review group mapping hoặc secret khi liên quan.
• Người phát hành không nên vừa sửa Pipeline, vừa tự cấp quyền deploy và vừa là approver duy nhất của thay đổi. Approval Pipeline không thay authorization tại Jenkins hoặc hệ thống đích.

Break-glass là đường recovery kiểm soát được, không phải shared admin thường ngày. Dùng danh tính riêng, owner rõ ràng, secret lưu trong vault theo policy, audit bắt buộc và drill định kỳ trên môi trường cô lập. Kiểm tra ít nhất một đường quản trị vẫn hoạt động trước khi đổi realm/strategy. Sau một lần dùng break-glass, ghi incident/change, review phạm vi, rotate/revoke material theo policy và quay về access thường ngày.

Thay đổi audit và offboardingCopy Anchor Link

Mỗi permission change cần một record có thể trả lời ai yêu cầu, vì sao, ai phê duyệt, thay đổi gì, hiệu lực ở đâu, test gì và quay lui thế nào. Tối thiểu lưu ticket/change ID, principal/group, role/matrix row, pattern hoặc object path, version Jenkins/plugin, timestamp, reviewer, ảnh/export hoặc config diff đã bảo vệ, và kết quả test deny/allow. Không đưa API token, password, private key, export credential hay URL nội bộ nhạy cảm vào evidence.

Review quyền theo chu kỳ và theo event: nhân sự đổi vai trò/rời đội, group IdP đổi membership, folder/job bị move, agent/credential mới, plugin/core update hoặc advisory. Offboarding phải thu hồi group/role/token/service identity ngay theo policy, xác minh user không còn đăng nhập hay truy cập job, rồi giữ evidence thu hồi. Xóa user trong Jenkins không đủ nếu IdP group, API token, credential mapping hoặc quyền ở hệ thống đích còn hiệu lực.

Cấu hình controller, export và backup là dữ liệu nhạy cảm. Giữ snapshot/diff trong kho được phân quyền; đừng dùng screenshot UI hoặc danh sách role như backup duy nhất. Hướng dẫn ownership, backup và rollback của cấu hình toàn cục có tại Cấu hình hệ thống Jenkins.

Lab loopback kiểm thử policyCopy Anchor Link

Lab này chỉ xác minh enforcement của Jenkins/plugin đang chạy tại chỗ. Nó không chứng minh policy production, tương thích với identity provider thật hoặc an toàn của agent/credential/hệ thống đích. Thực hiện trên controller throwaway, chỉ bind 127.0.0.1, với JENKINS_HOME riêng và user/role giả.

Điều kiện và guardCopy Anchor Link

• Dùng URL loopback, ví dụ http://127.0.0.1:8080/; không mở port ra LAN/Internet, không dùng controller production hay dữ liệu đã sao chép từ production.
• Cài và kích hoạt một strategy cần kiểm thử theo plugin/core đã được review. Ghi lại Jenkins core, Java, plugin short name/version và strategy hiện hiệu lực. Plugin UI/capability là runtime assumption, không phải fact tĩnh của bài này.
• Dùng một administrator lab cá nhân đã đăng nhập, cộng một recovery path lab đã kiểm thử ở phiên trình duyệt riêng. Không đăng xuất/xóa cả hai trước khi kết thúc test.
• Tạo folder team-alpha-sandbox, smoke job vô hại chỉ in một dòng cố định, và danh tính giả lab-ci-observer, lab-ci-runner, lab-ci-maintainer. Không dùng password, token, credential, SCM thật hoặc agent có quyền deploy.
• Tắt hoặc không cấu hình anonymous grant cho folder/job. Nếu mục tiêu là test anonymous, chỉ kiểm tra behavior xem/deny của namespace lab và giữ recovery session mở.

Đọc Thiết lập ban đầu nếu cần dựng controller local với persistent storage. Lab authorization không yêu cầu cài thêm plugin ngoài strategy đã được phê duyệt; không cài plugin lên production để làm theo ví dụ.

Snapshot thay đổi và rollbackCopy Anchor Link

Trước khi sửa security configuration, ghi lại bằng chứng ở nơi bảo vệ phù hợp: strategy hiện tại, assignment/permission rows, group mapping nhận được, folder path, plugin/core version, thời điểm và administrator thực hiện. Nếu policy được quản lý bằng configuration as code, lưu revision đã biết tốt cùng export/reference của sandbox phù hợp version; không commit secret vào Git.

Xác định rollback trước khi bấm Save: quay lại snapshot policy của chính controller lab, xác minh recovery administrator vẫn có quyền, rồi đăng nhập bằng user sandbox để test lại baseline. Không restart, reload hay thay global security chỉ để thử phỏng đoán. Nếu admin mất truy cập, dừng thao tác và dùng recovery path đã chuẩn bị; không hạ authorization toàn controller hay tạo broad administrator như cách chữa lỗi.

Thiết kế test matrixCopy Anchor Link

Áp dụng mẫu Matrix hoặc Role Strategy tương ứng cho namespace lab, sau đó kiểm tra cả đường được phép lẫn bị từ chối.

Nếu Jenkins che object không được phép bằng 404 thay vì 403, ghi đó là kết quả runtime của strategy/UI và vẫn kiểm tra policy bằng account sandbox. Status code không một mình chứng minh object tồn tại hay không tồn tại.

Thực hiện test allow denyCopy Anchor Link

1. Trong cửa sổ administrator lab, tạo policy nhỏ nhất cho đúng test matrix. Dùng folder path/pattern chính xác; với Role Strategy kiểm tra pattern match full name và case, với Matrix kiểm tra inheritance đang chọn.
2. Mở một browser profile/private window riêng cho từng user sandbox. Đăng nhập từng user và thực hiện đúng một thao tác cho mỗi hàng matrix. Không mượn session administrator để suy luận quyền user.
3. Với phép đọc, kiểm tra folder parent, job child và run riêng. Với phép chạy, dùng smoke job không checkout SCM, không bind credential, không gọi network và không chọn agent đặc quyền.
4. Với phép bị từ chối, thử URL/action qua browser. Có thể quan sát endpoint không thay đổi trạng thái như http://127.0.0.1:8080/whoAmI/api/json để xác nhận session hiện tại; không dán token/password vào command line, history hoặc evidence.
5. So sánh kết quả với matrix. Nếu một deny thành allow, dừng test, tìm mọi grant cộng dồn (group, global role/matrix, parent folder, inheritance, regex overlap và plugin permission), rồi rollback snapshot. Không nới quyền để làm test “xanh”.
6. Ở phiên recovery, xác minh vẫn vào được Manage Jenkins trước và sau Save. Đây là test recovery, không phải lý do mở quyền recovery cho user lab.

Dọn lab và ghi evidenceCopy Anchor Link

Sau khi capture evidence, xóa policy assignment, users/groups giả, job và folder chỉ của lab bằng UI hoặc restore snapshot lab. Xác minh team-alpha-sandbox không còn xuất hiện với user sandbox và recovery administrator vẫn đăng nhập được. Không chạy lệnh xóa volume, prune hoặc cleanup trên path/storage không tạo riêng cho lab.

Nếu một bước lab có dùng thư mục tạm do shell tạo, chỉ dùng đường dẫn từ mktemp -d, kiểm tra nó khác rỗng và nằm dưới thư mục tạm trước khi xóa. Ví dụ guard chỉ áp dụng cho thư mục tạm do chính shell tạo, không áp dụng cho JENKINS_HOME, workspace, volume Docker hay đường dẫn do người dùng nhập:

lab_tmp="$(mktemp -d)"
case "$lab_tmp" in
  /tmp/*) rm -rf -- "$lab_tmp" ;;
  *) printf '%s\n' 'Refuse cleanup outside /tmp' >&2 ; exit 1 ;;
esac

Evidence cuối gồm snapshot trước/sau đã redaction, test matrix kết quả, version/plugin, principal giả, approver, rollback result và thời điểm review lại. Các file này không được chứa credential, token, cookie, config export nhạy cảm hoặc identifier production.

Checklist review trước khi áp dụngCopy Anchor Link

• Security realm, group mapping và authorization strategy được phân biệt; identity thật của principal đã được xác minh.
• Object scope nhỏ nhất đã rõ: controller, agent, folder, job, run, view, SCM hoặc credentials.
• Overall/Read, Overall/Manage và Overall/Administer được đánh giá theo capability thực tế, không theo tên role.
• Matrix inheritance hoặc Role Strategy global/item/agent role, regex và overlap đã được rà soát cùng mọi group assignment.
• anonymous và authenticated không có permission đáng kể nếu không có yêu cầu, owner và test server-side rõ ràng.
• Folder parent, folder lồng nhau, create/move behavior và grant global đã được kiểm tra; folder không bị coi là secret boundary.
• Người có Configure, quyền agent, SCM, plugin permission hoặc credential scope đã được đánh giá như đường thực thi/đặc quyền gián tiếp.
• Labels, views, UI visibility và approval không bị dùng thay authorization, isolation hạ tầng hay quyền hệ thống đích.
• Plugin strategy có version, compatibility, dependency và security advisory review; behavior được xác minh trên runtime sandbox.
• Có separation of duties, owner, evidence change/audit, expiry/review date, offboarding/revoke path và break-glass drill.
• Snapshot/export đã bảo vệ, rollback được định nghĩa trước Save và recovery administrator được kiểm thử mà không cấp broad admin.
• Test matrix có cả allow và deny bằng user browser/API sandbox riêng; log/evidence không chứa secret.

Tự kiểm traCopy Anchor Link

1. Security realm và authorization strategy trả lời hai câu hỏi khác nhau nào? Nếu group từ IdP đổi membership, permission hiệu lực có thể thay đổi ra sao khi matrix không đổi?
2. Vì sao Overall/Manage không nên được mô tả là “admin an toàn”, và tại sao Overall/Administer không phải cách xử lý một 403?
3. Một item role có pattern ^team-alpha-sandbox/.* nhưng user không mở được folder cha. Bạn kiểm tra pattern/role nào trước?
4. Vì sao Job/Configure trên job dùng credential hoặc agent release có thể là đặc quyền cao hơn tên permission gợi ý?
5. Nêu các grant cần tìm khi user bất ngờ có quyền: direct assignment, group, global policy, parent inheritance, regex overlap và plugin permission. Bạn sẽ chứng minh deny bằng cách nào?
6. Vì sao folder, label trusted-release và nút UI bị ẩn không phải secret boundary hoặc authorization enforcement đầy đủ?

Nguồn Jenkins và plugin chính thứcCopy Anchor Link

• Jenkins Access Control — tách authentication/authorization, common mistakes và scope permission.
• Jenkins Permissions — semantics Overall/Read, Overall/Manage, Overall/Administer và các nhóm permission core.
• Managing Security — cấu hình security và vận hành controller.
• Matrix Authorization Strategy — project-based matrix, inheritance và caveat Configure.
• Role-based Authorization Strategy — global/item/agent roles, pattern và naming strategy.
• Folder-based Authorization Strategy — thông tin plugin và security warning hiện có; review advisory trước mọi quyết định cài đặt.
• Jenkins Security Advisories — advisory Jenkins core và plugin.

Đọc tiếpCopy Anchor Link