Managing Jenkins User Deployment Permissions with RBAC and Role‑Based Authorization Strategy

Preface

In the previous posts we discussed four topics about automated deployment. This article continues the discussion by focusing on how to manage Jenkins users' deployment permissions.

By reading this article you will learn:

Basic concepts of RBAC.

How to use Jenkins' Role Strategy plugin.

Practical steps to manage user deployment permissions through roles.

1. RBAC

Jenkins' built‑in permission model has several shortcomings:

Multiple pipeline jobs, but different users should see different jobs.

A project has multiple environments, and users should only be able to deploy to specific environments.

Some projects should only allow read‑only access without deployment rights.

To address these issues, Jenkins can use the RBAC (Role‑Based Access Control) plugin for fine‑grained permission control.

RBAC（Role-Based Access Control） : A permission control model that assigns permissions to users indirectly through roles.

The diagram below shows three users each associated with a different role, and each role is linked to specific deployment tasks.

2. Role Strategy Plugin

The Role‑based Authorization Strategy plugin is recommended for managing permissions.

Plugin name: Role‑based Authorization Strategy . Install it via the Jenkins plugin manager.

3. Choose Authorization Strategy

Jenkins provides several built‑in authorization strategies. In the global security settings you can select one.

Path to the setting:

Dashboard->Manage Jenkins->Configure Global Security

After installing the Role‑based Authorization Strategy plugin, a new Role‑Base Strategy option appears.

4. Create Demo Users

Three users are created for the demonstration:

Development Lead 1 : username = passjava‑master1

Test Lead 1 : username = passjava‑tester1

Project Manager 1 : username = passjava‑pm1

5. Create Demo Jobs

Four pipeline jobs are created, representing test and production environments for two projects.

Two groups are also defined:

Production group (demo‑prod‑env) – contains passjava‑prod‑project1 and passjava‑prod‑project2 jobs.

Test group (demo‑test‑env) – contains passjava‑test‑project1 and passjava‑test‑project2 jobs.

6. Create Demo Roles

6.1 Role‑creation page path

The role‑creation page can be accessed as shown:

页面地址：
http://<你的jenkins服务ip>:8080/manage/role-strategy/
访问路径：
Dashboard->Manage Jenkins->Manage and Assign Roles->Manage Roles

6.2 Three Role Types

Global roles : e.g., admin, job creator, anonymous – set permissions at the global level.

Item roles : task‑level roles – set permissions for specific jobs or groups.

Agent roles : not used in this article.

6.3 Global Role

A global role applies to any Jenkins item and overrides item‑level settings. Granting Job/Read in a global role allows reading all jobs regardless of item‑role configuration.

For our demo we create a global role named passjava with only the Overall Read permission.

All three demo users are added to this global role.

Note: If a user is not assigned to the global role, login will fail.

6.4 Item Roles

Three item roles are created:

passjava‑master : can deploy both production environments of project 1 and project 2.

passjava‑tester : can deploy the test environments of both projects.

passjava‑pm : can view all environments but cannot deploy.

Explanation of role configuration:

Role : name of the role.

Pattern : regular expression that matches job names, e.g., passjava‑prod.* matches all jobs starting with passjava‑prod .

6.5 Assign Roles

Roles are assigned to users via the Assign Roles function.

After assignment:

Development Lead (passjava‑master) sees and can deploy production jobs.

Project Manager (passjava‑pm) sees all jobs but cannot deploy.

Test Lead (passjava‑tester) sees and can deploy test jobs.

The results demonstrate that users, roles, and permissions are correctly configured, allowing different users to deploy to different environments.

7. Summary

This article introduced RBAC concepts and the Jenkins Role Strategy plugin, and through hands‑on examples showed how to configure users, roles, and job permissions to manage deployment rights securely.

It also revisits the original Jenkins limitations and presents the corresponding solutions:

Separate visibility of pipeline jobs by assigning different roles.

Control deployment to specific environments by creating environment‑specific jobs and roles.

Provide read‑only access without deployment rights by assigning a view‑only role.