Manish Singh (Devops-Associate Consultant - Devops)

Overview
 

When a project is in the development phase, more than one developer works on the same project and frequently pushes the code into the remote repository. This updated source code needs to be present in the development server simultaneously, to verify whether the changes made by the developer are reflected on the website(resides in the server) or not.
 

As a DevOps Engineer, we ensure the updated code is pulled and create a build in the Server for testing and serving customers. Doing this manually can be tedious and inefficient, so we made the Jenkins pipeline to automate all the required processes. But, developers commit to the source code multiple times in a day, so we have to run the pipeline build multiple times, and if a DevOps Engineer is in more than one live project, the DevOps engineer won't be available to run those pipelines when it is required most, keeping track of all these builds can be error-prone.

One solution to this problem is providing the Jenkins credentials to the lead developer so that every time their team makes changes and after approving those commit, he/she runs the pipeline build by themself.

The only issue with this approach is that we can't give Jenkins admin credentials to other users , except to the administrator. So, how can we provide access to the other users, and restrict them to doing the required task only?

Jenkins is the go-to choice for CI/CD implementation for the majority of engineers, due to its dynamic and adaptive nature. Using the Jenkins plugin we can increase its capability. One such plugin is the Role-based Authorization Strategy. 

The role-based Authorization Strategy plugin allows the admin to create a role-based strategy and apply it to the users or group of users to maintain the principle of least privilege so that the developer or any other team member can only do the tasks they are required to do.
 
 

Implementation:

Now, enough of the theory part let's do the practical implementation of this RBAC plugin.

A pre-requisite to achieve this is, proper installation, and setup of Jenkins in your system or server can be accessible using the mapped URL (In our case it will be localhost:8081).

Once login, go to the Manage Jenkins option and click on the plugin section.
 

Inside the plugin section, you will see the available plugin, in which search for Role-based Authorization Strategy, and install.

After installing the Plugin, we will create the users we require, so that we can provide those users' credentials to the concerned entity. In this case, it will be a developer, who has access to the Jenkins pipeline only to create a pipeline build, and an intern who can see the pipeline syntax for learning purposes but can't alter the content of the Jenkins pipeline.

Go to Manage Jenkins, In the security section click on Users and create two users (developer & Intern) via the + button.
 

Now, after creating those users, we need to provide role-based access to these users, for a particular pipeline or Jenkins functionality. In the same security section go to Manage and assign roles.
 

First configure global roles, which means what kind of work the users are authorized to perform, only read, read & implement, etc. Now, add a role for both developer and Intern, and click on ADD. Give the required authorization to the role such as reading Overall, reading Job, and reading SCM. 

Once, global roles are configured we can move to item role, where we will define, which pipeline we want to assign to which particular user.
 

In this, we create one role to build the job, and another just to view the job.

Now, after managing role, we will assign these roles to each other, for this go to assign role, and inside that configure global role, add the user you want to add 

Assign these users with the manage role's global roles, in our case, Suraj is our developer and Intern is assigned to the Intern manage role.
 

The above picture  is manage role's global roles

Scroll down and we can see the Item role, In the item role we will assign “manage role” we define with the user we can see in the item role.

The above picture  is manage role's Item roles

Result

And once this is done, we can save it and provide the credential to the respective employee.

Now, when the developer logs in using the developer user credential, he/she will be able to create the build of the job. This user can not perform operations on any other job, example: Suraj can use the build button of the mdms-frontend pipeline, but he can't access the mdms-backend job, because we haven't allowed him.

mdms-frontend

mdms-backend

Similarly, our Intern can only see the Jenkins components, but can't perform any operation until we allow it.
 

Conclusion

By using a Role-based authorization strategy plugin we can securely allow lead developers to create builds of Jenkins build, specific to their project, and reduce the repetitive work, we can also trigger builds using a webhook Hook, but sometimes lead developers want to only run the Jenkins build when he becomes sure all the necessary changes as been merged. That's all for this blog, hope you might learn something new.
Happy Learning!