|The performance of this plugin is being improved as a part of Google Summer of Code 2019. Help us understand how you use this plugin through our Gitter chat.|
Adds a new role-based strategy to manage users' permissions.
This plugin adds a new role-based strategy to ease and fasten users management. This strategy allows:
- Creating global roles, such as admin, job creator, anonymous, etc., allowing to set Overall, Slave, Job, Run, View and SCM permissions on a global basis.
- Creating project roles, allowing to set only Job and Run permissions on a project basis.
- Creating slave roles, allowing to set node-related permissions.
- Assigning these roles to users.
Table of contents
|Table of Contents|
Using the plugin is fairly simple:
- Activate the Role-Based Strategy by using the standard Manage Jenkins > Configure System screen:
- Define and assign roles by using the Manages Roles item which appears in the Manage Jenkins screen:
You then get following options:
#* Manage Roles is the place where to set up roles:
There's nothing much to say here, this is self-explanatory. The only tricky field is the Pattern one. This field consists in a regular expression aimed at matching the full name (including the folder name, if you're using Cloudbees Folders Plugin) of the jobs which the role will apply to. For example, if you set the field to "
Roger-.*", then the role will match all jobs which name starts with "Roger-". Note that the pattern is case-sensitive. To perform a case-insensitive match, use
(?i)notation: upper, "
Roger-.*" vs. lower, "
roger-.*" vs. case-insensitive, "
(?i)roger-.*". If you have a nested folder structure where you want to provide the particular access to the second folder (or deeper), consider having a two-level security structure as well (Say you want to provide exclusive write/ modify type access to foo/bar and not everything else under "foo": First, assign that user/ group to read/ discover permissions with pattern " ^foo.* ", then assign that same user/ group to the more particular permissions with pattern " ^foo/bar.* " - Similar to what you'd do in a Unix/ Linux environment.
- #* Assign Roles is the place where to assign the defined roles to users:
Global Roles vs. Project Roles
It should be noted that the Global Roles override anything you specify in the Project Roles. That is, when you give a role the right to Job-Read in the Global Roles, then this role is allowed to read all Jobs, no matter what you specify in the Project Roles.
It may therefore be advisable to leave most (all) options unchecked in Job, Run and SCM in the Global Roles section for normal users.
There are two built-in roles:
*Anonymous* — Users who have not logged in
authenticated — Logged in users
Macros support (since 2.1.0)
Macros allow to extend analysis of user's access rights (see @RoleMacroExtension). If user's sid meets criteria in Roles and Assignments, then analysis will be propagated to extension, which makes decisions according to instance and parameters.
You can get list of available macros and theirs descriptions at the JENKINS_URL/role-strategy/list-macros page. At the current state, plugin has minimal set of available macros, but they can be added by extensions from plugins.
- Built-in: @BuildableJob
- Ownership plugin: Ownership-based roles: @Owner and @CoOwner (will be released in ownership-0.2)
Macros can be used in the following fields:
- RoleMacros - name of the role
- UserMacros - Not supported yet
Macro format: @macroName[:id][(parameter1, parameter2, ...)]>
- macroName - name of the macro (see available macros in the table below)
- id - identifier of the macro. Technical parameter, which allows to use same macros for multiple patterns
- parameter - additional parameters. At the current state, they don't support variables or TokenMacros
Macro string examples:
- @BuildableJob - Primitive macro invocation. Such invocation can be used only once in each roles category.
- @BuildableJob:1 - Macro with id
- @ParameterizedMacro(param1) - Invokes macro with one parameter
- @ParameterizedMacro:2(param1,param2) - Invokes macro with two parameters. Id prevents naming conflicts
The management interface becomes difficult to use with a large number of users and/or roles. Several Greasemonkey userscripts exist to make the UI easier to use (Jira issue):
Jenkins Role Strategy UI enhancer
This userscript adds a tooltip to the checkboxes indicating the row (e.g. user name) and column (e.g. permission).
Jenkins Role Strategy Role Management Enhancer and Jenkins Role Strategy Role Assignment Enhancer
These userscripts rotate the text in the column title cells on the Role Strategy configuration pages by 90 degrees so they use less horizontal space. Additionally, the first (header) column is repeated at the end of the table.
See the plugin documentation on GitHub: https://github.com/jenkinsci/role-strategy-plugin/blob/master/README.md
Version 2.11 and newer versions
See the changelog here
Version 2.10 (Feb 11, 2019)
- Jenkins 2.60.3 is now the minimal requirement of the plugin
- JENKINS-44472 - "Manage roles" table now supports preview of jobs matching the regular expression
- PR #45 - REST API: getRole now also returns SID assignments
- JENKINS-55804, JENKINS-55803 - Improve performance of the plugin on instances with many roles
- JENKINS-49102 - "Manage roles" page now displays patterns in quotes to properly visualize whitespace patterns
- JENKINS-45942 - REST API: Throw error when a non-existent permission is added in the addRole call
- JENKINS-54900 - REST API: Prevent concurrency issues when permissions are checked in parallel with REST API calls