Differentiation of access rights to Jenkins
At one time, rummaged through a lot of Internet, but could not find a suitable solution. Decided to share a recipe for a solution.
Task: Organize access to jenkins to members of different development teams, so that members of one team do not have access to either tasks or the workspace of tasks of other teams. Those. so that everyone within his project could do what jankins wanted in jenkins, but could not even gaze at the source codes of the project, which he was not supposed to look at.
The solution was not to be doused, but inspired by a vain search for a suitable way.
Further, it is assumed that jenkins will work in a Linux environment, not tested on Windows.
')
It was necessary to solve two problems:
1. In the standard package there are no tools for grouping tasks, and, accordingly, it is impossible to distribute rights to a group of users for a group of tasks.
2. Even if the first problem is solved, the second will remain - users may have access to the workspace of tasks at the operating system level. For example, without much difficulty, you can run a bash-script in which to archive the entire jenkins home directory and send it to yourself by mail.
So, the description of the solution.
Total, we have:
1. Sharing access between teams at the OS level.
2. Sharing access between teams at the Jenkins level.
3. The ability to give users access to the working directories of the relevant users of the OS, so that they can independently install / configure / copy something.
4. One Jenkins instance at all, which greatly simplifies the administration and maintenance of up to date.
5. If necessary, it is very easy to add more nodes if required. The solution will already be run.
I hope this recipe will be useful, thank you for your attention!
Task: Organize access to jenkins to members of different development teams, so that members of one team do not have access to either tasks or the workspace of tasks of other teams. Those. so that everyone within his project could do what jankins wanted in jenkins, but could not even gaze at the source codes of the project, which he was not supposed to look at.
The solution was not to be doused, but inspired by a vain search for a suitable way.
Further, it is assumed that jenkins will work in a Linux environment, not tested on Windows.
')
It was necessary to solve two problems:
1. In the standard package there are no tools for grouping tasks, and, accordingly, it is impossible to distribute rights to a group of users for a group of tasks.
2. Even if the first problem is solved, the second will remain - users may have access to the workspace of tasks at the operating system level. For example, without much difficulty, you can run a bash-script in which to archive the entire jenkins home directory and send it to yourself by mail.
So, the description of the solution.
- We put jenkins. I have Fedora, so:
- dnf install jenkins
- sudo service jenkins start
- after which we observe localhost : 8080
- Creating Jenkins Users
- Go to the Jenkins settings section “Configure Global Security”, where we put the necessary checkboxes:
- While we will issue an anonymous user all rights
- After saving the settings, the link “Register” appears in the header, registering the Jenkins administrator and the necessary users (members of the development teams)
- Finally, we set up global user rights, namely: we give the administrator full access, ordinary users only read, and anonymously prohibit everything:
- Go to the Jenkins settings section “Configure Global Security”, where we put the necessary checkboxes:
- Install the plugin (Plugin Management) "CloudBees Folders Plugin". The plugin allows you to create directories - task groups, arbitrary nesting. Directories can be issued rights to specific users. Further:
- Under the administrator, we create a task of the “Folder” type, one task of the “Folder” type per development team, for example:
- We configure access rights to each of the top-level directories: go to the directory and select “Configure” → “Enable project-based security”.
- So, at the global level, we have banned users from creating and viewing tasks; accordingly, no one except the administrator can create top-level tasks, but within the directories, users who have the corresponding rights are not limited by anything. Check the visibility of directories, go under one of the users:
We see that only one project is available for which rights are granted. Inside the catalog, you can do everything, for example, create new tasks:
Half done.
- Under the administrator, we create a task of the “Folder” type, one task of the “Folder” type per development team, for example:
- Next, we need OS users, create them (I will not give examples here, Google will always tell). Now we are considering an installation option when Jenkins is working on the same machine where the assemblies will be made. Our OS users will need ssh access, sshd should work. So, users are created: jenkins1 and jenkins2, respectively for each development team.
- Access control at the OS level will be implemented through the nodes, each of which will work under the OS user allocated for a specific command. We configure nody.
- First, disable master: Configure Jenkins → Build Environment Management → wizard → Configure, where we set “Number of executing processes = 0”.
- We create two new nodes (nodes) for each project.
- Here it is important for us to specify the number of workers, the root of the remote file system, the host and credentials (Credentials) of the OS user with whom the ssh session will be established, we create them in the system area so that they are not accessible to ordinary users.
- So, the nodes are created and operational:
- First, disable master: Configure Jenkins → Build Environment Management → wizard → Configure, where we set “Number of executing processes = 0”.
- We define groups of tasks performed on each of the nodes. To do this, we need the Job Restrictions Plugin plugin, after its installation, it will be possible to determine the class of tasks that will be executed on a particular node, for example, by a regular expression:
A small nuance, in this example, tasks created before configuring the nodes will be tied to the master node. To change this, you need to create a new task in the appropriate directory, then the magic happens and the tasks start to run on the necessary nodes.
Total, we have:
1. Sharing access between teams at the OS level.
2. Sharing access between teams at the Jenkins level.
3. The ability to give users access to the working directories of the relevant users of the OS, so that they can independently install / configure / copy something.
4. One Jenkins instance at all, which greatly simplifies the administration and maintenance of up to date.
5. If necessary, it is very easy to add more nodes if required. The solution will already be run.
I hope this recipe will be useful, thank you for your attention!
Source: https://habr.com/ru/post/268509/
All Articles