Jenkins CasC角色策略配置：按规则限制文件夹访问权限

核心思路 #

解决这个问题的关键是全局只保留最基础的登录访问权限，不授予任何全局级别的任务/文件夹读取权限，完全通过项目级角色精确控制用户能看到的范围。

完整配置示例 #

authorizationStrategy:
  roleBased:
    permissionTemplates:
    - name: "build_execute_perm_template"
      permissions:
      - "Job/Cancel"
      - "Run/Delete"
      - "Job/Build"
      - "Run/Update"
      - "Job/Discover"
      - "Job/Read"
      - "View/Read"
      - "Run/Replay"
      - "Folder/Read"
      - "Folder/Discover"  # 新增权限，确保能看到完整的文件夹层级
    roles:
      global:
      - entries:
        - group: "devops_team"
        name: "admin"
        pattern: ".*"
        permissions:
        - "Overall/Administer"
      # 全局基础访问角色，解决登录后访问被拒的问题
      - entries:
        - group: "app1_build_team"
        - group: "app2_build_team"
        # 可继续添加其他需要登录的团队组
        name: "basic_login_access"
        pattern: ".*"
        permissions:
        - "Overall/Read"  # 仅允许登录查看仪表盘，无全局任务/文件夹权限
      items:
      - entries:
        - group: "app1_build_team"
        name: "app1_build_access"
        pattern: "Folder1/app1/.*"
        templateName: "build_execute_perm_template"
      - entries:
        - group: "app2_build_team"
        name: "app2_build_access"
        pattern: "Folder1/app2/.*"
        templateName: "build_execute_perm_template"

关键配置说明 #

1. 全局基础角色basic_login_access：

   • 仅授予Overall/Read权限，既能让用户正常登录进入仪表盘，又不会让他们看到所有任务和文件夹。
   • 把所有需要登录的LDAP团队组都加入这个角色。

2. 新增Folder/Discover权限：

   • 这个权限能让用户遍历到指定的文件夹层级（比如Folder1/app1），否则可能只能看到最底层的任务，看不到完整的文件夹结构。

3. 项目级角色区分命名：

   • 将之前重复的build_execute角色名改成对应团队的专属名称（如app1_build_access），避免混淆，也更便于后续维护。
   • 每个项目角色的pattern严格匹配对应团队的文件夹路径，确保用户只能看到该路径下的所有内容。

之前配置问题的原因 #

• 情况1：无全局Overall/Read权限 → 用户连Jenkins仪表盘都无法进入，直接触发访问被拒。
• 情况2：全局授予Job/Read或Folder/Read → 全局权限优先级高于项目级权限，用户能看到所有任务/文件夹，仅操作权限受限制。

内容的提问来源于stack exchange，提问作者New2Python