I think you want to look into the following instead of the matrix based strategy: https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin
________________________________________ From: [email protected] <[email protected]> on behalf of Jason LeMauk <[email protected]> Sent: 14 July 2017 15:06:46 To: [email protected] Subject: Jenkins Distributed Builds: Permission tiers for project-based matrix authorization strategy Hello Jenkins Community! I had some questions for those of you fairly experienced with administering / maintaining a Jenkins distributed build system. I have a single Jenkins Master, and three or four Jenkins SSH Agents / Slaves running in VirtualBox (Jenkins host machine is running Ubuntu 14.04 LTS as well as the Jenkins Agents / Slave virtual machines). The goal with the distributed build system is to achieve separate build / test / deployment environments for each project. The concern that having all the software installed on the same machine (Jenkins host machine), could potentially pose issues for Jenkins Master’s machine as well as software needed to build / test / deploy one team’s applications could affect other teams and hold them up unnecessarily. · My question is what is the best method for authorization strategy when dealing with multiple teams in a Jenkins Distributed Builds setup? We are going to be using LDAP for our security realm (via the LDAP plugin), if that makes any difference. My obvious initial thoughts are to use the project-based matrix authorization strategy: 1. Ideally I’d like to have our global Jenkins Administrators setup with permissions to perform any actions within Jenkins globally.. 2. I’d like to have a lower level administrator (Project Administrators, likely team leads), who are granted all permissions on a job / project basis. Jenkins Global Administrators decide the permissions for these users. 3. The last tier of users are average Jenkins Users. The permissions for these users would be set by Project Administrators as they see fit. I believe Global Jenkins Administrators would need to add the users and then Jenkins Project Level Administrators can assign permissions for their team’s project / job. So in the Jenkins distributed build system we have three tiers of users, each with lesser permissions than the last: 1. Global Jenkins Administrators: Manages Project Level Administrators and Average Jenkins Users 2. Project Level Administrators Manages Average Jenkins Users for their project / job. 3. Average Jenkins Users: Lowest level user with the most restrictive permissions. Doesn’t not manage Jenkins for any other users. - Is this a typical setup when administering Jenkins Distributed Build system with multiple teams involved? - Am I understanding the user of the Project-based matrix authorization strategy correctly? - Does anybody have any experience with a different access control approach? Thank you to anyone who has any experience with maintaining a distributed build system involving several teams! - J -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599D6E9BBB864A9B4DD177889AD0%40BY2PR12MB0599.namprd12.prod.outlook.com<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599D6E9BBB864A9B4DD177889AD0%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d105f7f066be401792a1d72a04dc23fa%40partner.eso.org. For more options, visit https://groups.google.com/d/optout.
