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

2017-07-24 Thread J0991 
Just as a followup, I wanted to give anybody who may stumble across this
question in the future some valuable information that helped me achieve this
setup:

My goal was to have three tiers of users, each with less permissions than
the former:
- Global Administrators:
-- Granted all global permissions within Jenkins. These users can do
anything to any project / job, as well as modify Jenkins global
configuration settings.
- Project Administrators:
-- Granted job configuration permissions within Jenkins. These users can do
anything to a specific job, including modifying configuration and .
- Project Developers
-- Not granted any configuration permissions for jobs within Jenkins. These
users are granted the read permission, as well some job configuration
permissions (build, cancel, etc.).

I ended up going with the  role strategy plugin for Jenkins
<https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin>  . The 
matrix-based security plugin for Jenkins
<https://wiki.jenkins.io/display/JENKINS/Matrix-based+security>   did not
offer sufficient enough functionality to achieve my desired result.

Good luck to anybody out there whom may also need to implement a setup
similar to what I've tried to achieve. It is possible with the Role Strategy
Plugin! Please let me know on here if there are any specific questions and
I'll do my best to follow up with any information I have discovered.



--
View this message in context: 
http://jenkins-ci.361315.n4.nabble.com/Jenkins-Distributed-Builds-Project-Based-Matrix-Authorization-Strategy-tp4900386p4900767.html
Sent from the Jenkins users mailing list archive at Nabble.com.

-- 
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/1500901783502-4900767.post%40n4.nabble.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-07-18 Thread Daniel Beck 

> On 17. Jul 2017, at 21:04, Thiago Carvalho Davila 
>  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 jenkinsci-users+unsubscr...@googlegroups.com.
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.

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

2017-07-17 Thread 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 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.> 
> @csquaredsystems.com>


-


"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 jenkinsci-users+unsubscr...@googlegroups.com.
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.

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

2017-07-17 Thread Daniel Beck 

> 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 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.

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

2017-07-12 Thread 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: jenkinsci-users@googlegroups.com <jenkinsci-users@googlegroups.com> on 
behalf of Jason LeMauk <jason.lem...@csquaredsystems.com>
Sent: 11 July 2017 19:24:30
To: jenkinsci-users@googlegroups.com
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 
jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
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_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 jenkinsci-users+unsubscr...@googlegroups.com.
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.

Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

2017-07-11 Thread Jason LeMauk 
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 (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 jenkinsci-users+unsubscr...@googlegroups.com.
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.