1

I have a situation where I have a Jenkins installation that is used by multiple teams. Each team gets their own Jenkins node, which has access to certain parts of the organization that the team is responsible of.

I want to allow the teams to create their own Jenkins jobs, but they should only be allowed to set those jobs to run on their respective Jenkins node. So I need a way to allow users to create jobs, but restrict the nodes they can choose.

The only thing we found is Job Restrictions plugin, which is no longer maintained at this time and up to adoption. And we had some trouble with it.

What are my options?

bgdnlp
  • 253
  • 2
  • 6

3 Answers3

2

How Do I Restrict Access to Agents (previously called Slaves)?

You haven't specified what Jenkins you're running or whether you have licensed Cloudbees plugins. If you have the Cloudbees folder plugin together with the Cloudbees Folders Plus plugin, there is a "simple" way to do what you ask.

To take advantage of the power of the folder and folder plus plugin, you need a well organized hierarchy of jobs. If all of your jobs live in the top level (root) folder this strategy will require some significant work.

  • Create FOLDERs for each of your job/jobsets. And even better a parent folder to contain them all. E.g. /teams/Team1, /teams/Team2, ... and perhaps a separate folder for all of the agents /agents (or /admin)
  • In essence you'll allow Team1 to have a separate set of resources from Team2 - as well as a SHARED set of resources if appropriate for your situation.
  • Create and label Agents as usual, but set them to "Only accept builds from approved folders" I also HIGHLY suggest you only allow agents to accept builds for matching labels... otherwise chaos can occur.
  • Assign all the agents to the /admin folder. (So that any admin job can use any agent) - optional, but recommended. See below for how to make that assignment.
  • Assign any shared agents to the /teams folder.
  • Assign individual team agents to the /teams/TeamN folder to enforce that Team1 only has the agents available it is allowed to use.
  • Repeat the assignment process for each teamN + Agent combination.

How to Assign Agents to Folders

This is a bit tricky as there are several steps required - and since those steps may change, I'll suggest you consult Jenkins documentation, but here is the generic process. I recommend you open at least two browser windows, one to navigate agents, one (or more) to navigate folder(s).

  1. Select a folder you want to have access to an agent e.g. /teams or /teams/team1
  2. Select "Controlled Agents"
  3. Create a Request. This generates a Request Key.
  4. In another window, navigate to the Agent, select Approved Folders
  5. Paste the request key into the Agent/Approved folders - this generates a Request Secret.
  6. Navigate to the Folder/Controlled agents, paste the key from step 5 into the open request and click Authorize.

Now your agent has been associated with the specific folder. Repeat this process for ALL of your agents and all of the folders you wish to pair them with.

Note if you want shared-agent-1 to be usable by anyone in teams/Team1, or Team2... you only need to add it to the teams folder. However it would NOT be incorrect to add a shared agent to every sub-folder. There are advantages to both approaches.

There are also some subtleties about the use of the request keys... you can reuse them, but the best security is achieved by creating new request keys for every pairing, that way you can revoke one without revoking others.

NOTE:

The Jenkins CLI has the ability to automate all the steps described above.

What if I DO NOT have Licensed Plugins?

I can't answer that question because I believe the assignment of agents to folders is exclusive to the licensed cloudbees plugins.

Steven the Easily Amused
  • 121
  • 4
1

You could use Project-based Matrix Authorization Strategy for user authorisation in Jenkins.

Works well with Folders plugin, then you have each project in a separate folder and permissions on each folder are set to a team that looks after the project.

Each node/slave can have access permissions specified. For example, for node A you will only list Team A as users/team who can have Build and Configure permissions. Team B for node B etc. It is a pain if you have dozens of nodes though.

If integrated with AD, then groups as they are defined in AD can be used to restrict/give access without having to list all members of the team who needs access to which node/project.

Authorisation strategy is defined in "Manage Jenkins" -> “Configure Global Security Option" -> "Authorisation" -> "Project-based Matrix Authorization Strategy" This article describes it to a degree: https://www.thegeekstuff.com/2016/06/jenkins-security/

You could do the same with just Matrix Authorization Strategy, only you won't have projects. You might not need them at all (depends on how many project/teams you have) and then you will only restrict node permissions.

MasterBuilder
  • 11
  • 3
0

If all of the jobs are running k8s agents then you can use a combination of node attributes and podSpec nodeSelector. For example, if you assign an attribute identifying the team ownership these nodes for the purpose of jenkins.

kind: node
apiVerson: v1
-- some node specific stuff like name resource type ..
labels:
   type: jenkins
   team: qa

Than in the agent pod specification you can include a nodeSelector in the pod specification:

[.... yaml ... 
nodeSelector:
     type: jenkins
     team: qa
.... more yaml]

Openshift description of using nodeSelectors

bcolfer
  • 101
  • 2