Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

J0991

Hello Jenkins Community!

 

I am currently doing some preemptive planning for setting up our Jenkins instance.

We are going to use LDAP (Jenkins LDAP plugin), as our security realm, and project-based matrix authorization strategy (<a href="https://wiki.jenkins.io/display/JENKINS/Matrix&#43;Authorization&#43;Strategy&#43;Plugin?focusedCommentId=80642557">Matrix Authorization Strategy plugin), as our authorization strategy.

It should also be noted that we have a distributed build system in place (1 Jenkins Master and several Jenkins Agents (virtual machine’s running on Jenkins host via VirtualBox)). The goal of the distributed build system is to separate build / project environments on a per project basis.

 

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.

 

Is there anything I’m missing here as far as defining our authorization strategy? From everything I’ve read on the Jenkins wiki about the plugins as well as Jenkins itself, this appears to be a viable approach for giving teams as much control over their builds / projects as possible.

Thanks to anyone who has any experience setting up a Jenkins Distributed Build system using project-based authorization!

-        Jason

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599349B594D500AE8612BFA89AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Artur Szostak
If you are going to have a rather large setup running you may want to consider using the Role based authorisation strategy instead.

We have been using the project based matrix authorisation approach in our Jenkins with moderate success. But as the number of jobs, users and projects  increases this option stops being scalable. i.e. trying to maintain all the jobs through the standard Jenkins GUI becomes a real pain. Your only way out becomes scripting, which itself becomes a pain. We have tried to keep administration of the Jenkins jobs manageable using a 3rd party tool: jenkins-job-builder.

I am planning on moving to the Role based strategy myself when we get around to upgrading our Jenkins instance, mainly because it gives us more fine grain control when we need it. However, I will probably still end up using jenkins-job-builder, since the Jenkins GUI is still not much use to configure jobs at scale (Jenkins pipeline jobs only solved this halfway in my opinion).
________________________________________
From: [hidden email] <[hidden email]> on behalf of Jason LeMauk <[hidden email]>
Sent: 11 July 2017 19:24:30
To: [hidden email]
Subject: Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Hello Jenkins Community!

I am currently doing some preemptive planning for setting up our Jenkins instance.
We are going to use LDAP (Jenkins LDAP plugin<https://wiki.jenkins.io/display/JENKINS/LDAP+Plugin>), as our security realm, and project-based matrix authorization strategy (Matrix Authorization Strategy plugin<https://wiki.jenkins.io/display/JENKINS/Matrix+Authorization+Strategy+Plugin?focusedCommentId=80642557>), as our authorization strategy.
It should also be noted that we have a distributed build system in place (1 Jenkins Master and several Jenkins Agents (virtual machine’s running on Jenkins host via VirtualBox)). The goal of the distributed build system is to separate build / project environments on a per project basis.

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.

Is there anything I’m missing here as far as defining our authorization strategy? From everything I’ve read on the Jenkins wiki about the plugins as well as Jenkins itself, this appears to be a viable approach for giving teams as much control over their builds / projects as possible.
Thanks to anyone who has any experience setting up a Jenkins Distributed Build system using project-based authorization!

-        Jason

--
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 [hidden email]<mailto:[hidden email]>.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599349B594D500AE8612BFA89AE0%40BY2PR12MB0599.namprd12.prod.outlook.com<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599349B594D500AE8612BFA89AE0%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cc0a7fcc4a394e6f8899c5325fc228ed%40partner.eso.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Daniel Beck
In reply to this post by J0991

> On 11. Jul 2017, at 19:24, Jason LeMauk <[hidden email]> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Thiago Carvalho Davila
That should be a very good feature. Is it planned for Blue Ocean 1.2?

Em 17/07/2017 14:17:40, Daniel Beck escreveu:
> On 11. Jul 2017, at 19:24, Jason LeMauk  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 [hidden email].
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.

-


"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c27fe2c982f15411c8f48709b49d58676adf3160%40serpro.gov.br.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

Daniel Beck

> On 17. Jul 2017, at 21:04, Thiago Carvalho Davila <[hidden email]> wrote:
>
> Is it planned for Blue Ocean 1.2?

Blue Ocean can show folders already, see https://ci.jenkins.io/blue/

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3F4BE153-A845-4460-8C9A-38AC5D7DCD73%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Loading...