jenkins必须启用role-based strategy插件并配置三层角色矩阵：全局基础角色限读、凭证域角色按环境隔离使用权限、项目角色绑定job级调用，配合凭证id命名规范与pipeline白名单校验，实现跨部门凭证横向泄露防护。
要防止跨部门项目间因凭证（Credentials）被误用或越权访问导致的横向泄露，Jenkins 控制平面必须启用并严格配置基于矩阵的 RBAC（Role-Based Access Control），而非仅依赖默认全局权限或松散的项目角色。核心在于：凭证本身是全局资源，但其使用权限必须按项目上下文隔离；且凭证读取、绑定、更新等操作需分层控制，不能“一配了之”。
明确 Credentials 的权限作用域与敏感操作类型
Jenkins 中的凭证（如 Username/Password、SSH Key、Secret Text）默认存储在 Jenkins 实例级（JENKINS_HOME/credentials.xml），属于 全局可读资源。但实际风险不在于“能否看到列表”，而在于：
– 是否能在某 Job 配置中 选择并绑定 该凭证（Credentials/View + Credentials/Use）
– 是否能 在 Pipeline 脚本中显式引用（如 withCredentials()）
– 是否能 编辑或删除 凭证（Credentials/Update, Credentials/Delete）
这些操作对应不同权限粒度，必须分开授权，不可混同。
启用 Role Strategy 插件并禁用默认匿名访问
确保已安装并启用 Role-based Authorization Strategy 插件（非 Matrix-based Security，后者无法支持 Pattern 匹配）。在 系统管理 → 全局安全配置 中：
– 授权策略选 “Role-Based Strategy”
– 取消勾选 “允许匿名用户读取权限”（Anonymous Read Access）
– 勾选 “启用安全性” 后保存
⚠️ 若未关闭匿名访问，任何未登录用户都可能通过 /credentials/ 页面枚举凭证 ID 或名称，构成信息泄露起点。
构建三层角色矩阵：全局基础 + 凭证域隔离 + 项目级绑定控制
按最小权限原则拆解角色，避免单角色承载过多能力：
-
全局基础角色（Global Roles）：仅授予最低入口权限
–developer-base：Overall/Read, View/Read, Credentials/View（仅查看凭证列表，不可用）
–devops-cred-manager：Overall/Read, Credentials/Manage（可增删改所有凭证，但仅限授权人员） -
凭证域角色（Credential-Specific Roles）：按部门/环境隔离凭证可见性
– 创建 项目角色（Project Roles），Pattern 设为^cred-(dev|test|prod)-[a-z0-9-]+
– 权限仅含Credentials/Use和Credentials/View（禁止 Update/Delete）
– 例如：cred-dev-backend角色只允许匹配cred-dev-.*的凭证被 Job 使用 -
项目绑定角色（Job-Level Binding Roles）：限制凭证在具体 Job 中的实际调用
– 新建项目角色job-build-with-cred，Pattern 设为^project-(dev|test)-[a-z0-9-]+
– 权限含Job/Build,Job/Configure,Credentials/Use
– 关键点：该角色 不直接关联凭证本身，而是配合 Jenkinsfile 中withCredentials([string(credentialsId: 'cred-dev-db', variable: 'DB_PASS')])的 ID 白名单机制生效
强制凭证 ID 命名规范 + Pipeline 级白名单校验（增强防护）
仅靠 UI 权限不够，需结合代码层约束：
- 制定凭证 ID 命名规则，如：
cred---（例：cred-finance-prod-s3-key） - 在共享 Pipeline Library 中封装
safeWithCredentials()方法，内部校验传入的credentialsId是否匹配当前 Job 名称中的环境标识（如 Job 名为project-finance-prod-deploy，则只允许cred-finance-prod-*类凭证） - 配合 Jenkins Script Security 设置：禁用
groovy.lang.GroovyShell等高危类，防止脚本绕过权限检查动态拼接 credentialsId
这套配置不依赖 Jenkins X 或 Kubernetes RBAC，纯 Jenkins 原生能力即可落地。重点在于把“凭证存在哪”和“谁能在哪用它”彻底解耦，再通过命名规范、Pattern 匹配、Pipeline 封装三重加固，才能真正阻断跨部门横向越权路径。
