💸Save up to $132K/month in CI costs!👉 Try Free
Skip to main content
← Back to workflows

How to Ensure Safe User Scripting in Jenkins?

script-security -
Jenkins Plugin
v.1336.vf33a_a_9863911
67
Required Jenkins: v.2.387.3
ID: script-security
Contributors
Contributor - jglickContributor - dwnusbaumContributor - abayer
Categories

Optimize Your CI/CD Pipeline

Get instant insights into your CI/CD performance and costs. Reduce build times by up to 45% and save on infrastructure costs.

45% Faster Builds
60% Cost Reduction
Installation with the CLI tool
jenkins-plugin-cli --plugins script-security:1335.vf07d9ce377a_e

Script Security logo

Script Security

Script Security plugin ensures safe user scripting.


What is Script Security Plugin?

Jenkins plugins often need users to write custom scripts, usually in Groovy, to tweak how Jenkins behaves. If a person scripting is an admin, they pretty much have the freedom to do anything with Jenkins, like tweaking security or executing server commands, thanks to having Overall/RunScripts permissions. They use these powers to manipulate Jenkins' core with the same tools that plugins use.

On the other hand, if the script writers are just regular users without broad permissions, it’s risky to let them run any script they write. For this, there’s a neat tool called the Script Security library plugin. It fits right into various plugins and manages who gets to do what through script approval and a Groovy sandbox, making sure only safe and approved scripts run.

How Script Security works?

Jenkins has a straightforward system where any script can be executed, but only if an admin approves it first. There's a global list of scripts that are pre-approved as safe.

Whenever someone tries to save a configuration, like setting up a job, they'll see a warning that the script needs approval. Admins can give the green light using the Script Approval page, or via an approval link right in the setup. It's interesting to note that in the past, scripts added by admins were automatically approved. However, they changed this to avoid social engineering attacks. This applies whether you're saving through the web UI, uploading new XML configurations, or even just duplicating an existing item.

If a script in a template has been modified from a previously approved version, it won't run right away. Instead, it gets queued for approval, and a warning pops up in the UI. Admins have to go to 'Manage Jenkins » In-process Script Approval' to see these pending scripts. If everything looks okay, they just click 'Approve', and the script can be used from then on.

If you try running a script that hasn't been approved, it simply won’t work, and you’ll get a message explaining it's waiting for approval. You can try again once it's cleared. How this works can vary depending on the specific plugin used.

How to use Groovy Sandboxing?

Groovy Sandboxing allows scripts to run without admin approval by sticking to safe operations only. This happens in a controlled environment known as a sandbox. Currently, this is only available for Groovy—scripts in other languages still need the usual go-ahead.

To use it, you just tick the 'Use Groovy Sandbox' box below where you enter the Groovy script. This lets any team member, even admins, run the script right away, but with certain restrictions. Every action the script attempts—like calling methods, creating objects, or accessing fields—is checked against a list of safe operations. If the script tries something not on this list, it's stopped in its tracks, and you can't use that feature until the operation is approved.

The Script Security plugin comes with a basic whitelist of safe operations, and additional ones can be added by other plugins. But here’s a cool part: if a script hits a roadblock because an operation isn't whitelisted, that operation gets queued up for approval. Admins can approve these one at a time, which then makes them available for sandboxed scripts.

The operations are pretty specific, detailing the method calls with the class name, method name, and the types of arguments involved. This granularity helps ensure only safe operations are allowed. However, admins need to be judicious about what they whitelist, especially in security-sensitive areas, as some operations can alter the state of persistent objects like Jenkins jobs.