> On 11. Jul 2017, at 19:24, Jason LeMauk <jason.lem...@csquaredsystems.com> > wrote: > > As far as using a project-based matrix authorization strategy, I envision the > permissions working like so: > 1. Global Administrators: > - Access to everything within Jenkins (all projects / jobs, > configuration settings, plugins, etc.). > - Access to all Jenkins Agents / Build Nodes (provide with > virtual machine credentials for login). > - Can configure / modify all project’s Jenkins Agents / Slaves. > 2. Project Administrators: > - Access as an administrator to specific project’s / job’s > configurations. > - Access to team’s / project’s specific Jenkins Agents / Build > Nodes (provide with virtual machine credentials for login). > - Can configure / modify project specific Jenkins Agents / > Slaves. > 3. Jenkins Users > - Low level users added by project level administrators. > - Project level administrators have the ability to add users > to their project / job and grant permissions to those users as they see fit. > - Cannot directly configure / modify Jenkins Agents / Slaves > (Jenkins Agent / Slave credentials for login are not provided to low level > users). > - Could possibly modify job configurations for their project > if granted the right by a project administrator.
Seems reasonable; probably best to group 'projects' (jobs) into folders with permissions applying to all descendants if you have many. I expect you'll have a reasonably good experience with this strategy assuming not too many exceptions to these broad rules. -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/E677818B-6B16-4E57-87DF-75B6600DC717%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
