Security for team-specific nodes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Security for team-specific nodes

roland.asmann
Hey everybody,

I am a Jenkins admin in my company, but since the introduction of pipelines, I feel like I have lost a lot of control over Jenkins. There are a couple of things in my company that are really important for me to remain in control of, so I was hoping to get some pointers from some/all of you.

As a company, we supply the Jenkins Master with several 'public' nodes. These can be used by all projects and are paid for by all. Then we have some projects that have their own, special nodes, which only they pay for. The thing is, although these slaves are configured to be used only by jobs that request their specific labels, some of the teams have figured out that some of these nodes are a lot faster than our public ones and keep using these 'private' nodes. Since the projects that supplied these servers can sometimes run ONLY on these nodes (eg because they use lots of memory or have some specific hardware connected), they are obviously unhappy when they have to wait because the nodes are running 'illegal' jobs -- not even mentioning the fact they actually pay for these nodes...

Now, I was wondering if it was possible to configure nodes to be only used by certain people/groups/jobs/..., or even better, have the UI hide them from people that are not supposed to use them?

We are currently using Project-based security with LDAP and the Folder Plugin --> Every Project has a Group in LDAP and a folder in Jenkins where they have their jobs. It would be great if I can somehow 'connect' a server to one or more group(s) or folder(s).

Does anybody have any ideas on how to get (something like) this setup? Any suggestions are welcome!

Thanks,
Roland

--
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/6fa22e96-bb24-4362-8bd5-8d25e6ede649%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Security for team-specific nodes

jswager
If you use CloudBees Jenkins and their Folder Plus plugin, there is a feature on Folders that allows exactly this.  There is a Controlled Slave/Folder feature where you can set a mapping between one or more folders to a slave.  Such that only jobs in the mapped folder can execute on the mapped slave.  If a job in an unmapped folder tries to run on the slave, the build won't run on the slave and instead have to find a public one (one with no restrictions) or sit in the queue forever.

On Wednesday, March 25, 2020 at 6:25:22 AM UTC-7, Roland Asmann wrote:
Hey everybody,

I am a Jenkins admin in my company, but since the introduction of pipelines, I feel like I have lost a lot of control over Jenkins. There are a couple of things in my company that are really important for me to remain in control of, so I was hoping to get some pointers from some/all of you.

As a company, we supply the Jenkins Master with several 'public' nodes. These can be used by all projects and are paid for by all. Then we have some projects that have their own, special nodes, which only they pay for. The thing is, although these slaves are configured to be used only by jobs that request their specific labels, some of the teams have figured out that some of these nodes are a lot faster than our public ones and keep using these 'private' nodes. Since the projects that supplied these servers can sometimes run ONLY on these nodes (eg because they use lots of memory or have some specific hardware connected), they are obviously unhappy when they have to wait because the nodes are running 'illegal' jobs -- not even mentioning the fact they actually pay for these nodes...

Now, I was wondering if it was possible to configure nodes to be only used by certain people/groups/jobs/..., or even better, have the UI hide them from people that are not supposed to use them?

We are currently using Project-based security with LDAP and the Folder Plugin --> Every Project has a Group in LDAP and a folder in Jenkins where they have their jobs. It would be great if I can somehow 'connect' a server to one or more group(s) or folder(s).

Does anybody have any ideas on how to get (something like) this setup? Any suggestions are welcome!

Thanks,
Roland

--
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/80930fd7-c433-45ce-a963-ae47b67653ca%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Security for team-specific nodes

Daniel Beck
In reply to this post by roland.asmann


> On 25. Mar 2020, at 14:25, Roland Asmann <[hidden email]> wrote:
>
> Now, I was wondering if it was possible to configure nodes to be only used by certain people/groups/jobs/..., or even better, have the UI hide them from people that are not supposed to use them?
>
> We are currently using Project-based security with LDAP and the Folder Plugin --> Every Project has a Group in LDAP and a folder in Jenkins where they have their jobs. It would be great if I can somehow 'connect' a server to one or more group(s) or folder(s).

The Build Authorization mechanism does that by associating user authentications with running builds, and using the Agent/Build permission to control who gets to use an agent (it's a different permission than Job/Build): https://plugins.jenkins.io/authorize-project

An easier approach would be plugins like https://plugins.jenkins.io/job-restrictions/ that use a different mechanism to limit which jobs are allowed to build on a node that is easier to introduce to an existing setup.

Neither of the plugins is all that well maintained at the moment, I think, but maybe they're good enough in their current state.

--
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/188E47A8-9985-47A6-9C52-227373F1E8FD%40beckweb.net.