Jenkins DSL seed job

Create Jenkins DSL seed job

Install plugins

Install plugins. Click on Manage Jenkins → Manage Plugins in the navigation on the left and select the following plugins for installation (you can search for “authorize”, “git”, “groovy” and “dsl” using the filter function):

Authorize Project (required to run Groovy code loaded from a Git repository)
Git Parameter (enables the selection of a branch)
Groovy (allows us to use groovy code within a job)
Job DSL (provides the possibility to create jobs via a DSL; more about this in the second part of the article series)

Jenkins security system Script Security

We configure Jenkins to download scripts from the Git repository. Downloaded scripts are not executable by regular users or the “SYSTEM” user.
By default, a job is executed as the “SYSTEM” user – even if an admin starts it. Jenkins’ security system protects us from potentially dangerous groovy code that could be infiltrated by downloading from the git repository.

How to make downloaded scripts executable

There are different ways to make downloaded Groovy scripts executable:

• Non-executable scripts automatically end up in a validation queue. An admin can manually approve them under “Manage Jenkins” → “In-process Script Approval”.
  However, he would have to do this again each time we changed the Groovy code. This procedure could prove to be impracticable – depending on the composition of the team.
  Configure the security system so that the seed job always runs as an admin (by default, it runs as the SYSTEM user). This is insecure as it could introduce potentially dangerous code. Besides, this variant does not allow us to extract shared code into utility classes.

• Disable Script Security altogether (“Manage Jenkins” → “Configure Global Security” → Disable checkbox “Enable script security for Job DSL scripts”). This is even more insecure, as any user could execute potentially dangerous scripts in any job. In the previous option, we reduced the risk at least to Groovy files downloaded by the seed job.

• Run the code in the “Groovy Sandbox”. In the sandbox, the code is executable in principle but is limited to a fixed set of operations.
  This option only works together with the execution as an admin user. Otherwise, the scripts would have to be unlocked again via the validation queue.
  The sandbox prevents the execution of malicious code. This option is the only one that allows extracting code into utility classes.

Global configuration of Jenkins Script Security

Activate the possibility to configure the permissions for single jobs.
Access the global security settings via “Manage Jenkins” → “Configure Global Security”.
Add the “Per-project configurable Build Authorization” under “Access Control for Builds”:

In the checkboxes tick the options:

• Run as User who Triggered Build
• Run as a specific user

Job creation automation

Loading the Jenkins Job DSL code from the project repository

On the Jenkins homepage, we create a new job via “New Item”. We name it “Jenkins Tutorial Demo – Library 1 (DSL) Loader”, as type, we choose “Freestyle project” once again. Under “Build”, we add a “Process Job DSLs” step.

Instead of selecting “Use the provided DSL script”, we leave the default selection “Look on Filesystem”.
To make the job file available in the file system, we have to clone the Git repository first. So we scroll back up to “Source Code Management”, select “Git” and enter the repository URL “git@gitlab.com:Blaataap/jenkins-tutorial-demo.git”

Enable GitHub hook trigger for GITScm polling under Build Triggers:

Scroll down to “Build” and enter the path of the Groovy file, jobs.groovy, in “DSL Scripts”. We also activate the option “Use Groovy Sandbox”:

Click on “Save”. Before we can execute the job, we must specify that Jenkins has to run the job as an admin user. To do this, we click on “Authorization” on the job page.
If you don’t see this point, please check if you have performed the steps in the Global configuration of Jenkins Script Security section correctly.

On the “Authorization” page we activate “Configure Build Authorization” and select either “Run as User who Triggered Build” or “Run as Specific User” as the strategy. The difference is as follows:

• Run as User who Triggered Build: The job must ultimately be started by an admin user to execute the downloaded Groovy code (unless an admin has already whitelisted it).
• Run as Specific User: Use this option to specify a user with whose rights Jenkins executes the job – independent of the logged-in user. If you provide an admin user here, every logged-in user can start the job.

We save the changes and start the job with “Build Now”. The job aborts with an error message despite all security-relevant settings we have made:

We cannot avoid this error message. It says that calling the specified method is not allowed within the Groovy sandbox.
At the same time, Jenkins has written the method signature into the validation queue, where we can then approve it as follows. We reach the approval form via “Manage Jenkins” → “In-process Script Approval”:

Click on “Approve” and then find the method signature in the list of released signatures.

For the GitHub hook trigger to work, we need to change the “Authorize Strategy” for the seed job. It is currently set to “Run as User who Triggered Build”.
The build trigger executes the job as user “SYSTEM”. This user does not have permission to execute code in the Groovy sandbox. Therefore we have to change the strategy to “Run as Specific User” and specify a user with admin rights.

Source: https://www.happycoders.eu/devops/jenkins-tutorial-implementing-seed-job/