> On 11. Jul 2017, at 19:24, Jason LeMauk <[email protected]> > 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 [email protected]. 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.
