- What is Sandbox mode?
- How does script security affect Pipeline job types?
- How do I know if I am running in the Groovy Sandbox?
- Why am I getting
- In what order are blacklists and whitelists applied?
- Why can’t I approve a script?
- How are Shared Libraries affected by Script Security?
- Why is a whitelisted method rejected when running in the Groovy Sandbox?
- CloudBees Jenkins Enterprise - Managed controller (CJE-MM)
- CloudBees Jenkins Team (CJT)
- CloudBees Jenkins Platform - Client controller (CJP-CM)
- Jenkins LTS
- Script Security
- Pipeline: Groovy
- Groovy Sandbox
- In-process Script Approval
- Job DSL plugin - Script Security
- Template plugin - Template Security
- JENKINS-28178 - Option to disable sandbox in CpsScmFlowDefinition
- Permissive Script Security
- Access Control
Jenkins Pipeline scripts can either be run inside or outside of a Groovy sandbox. Scripts that run outside the sandbox must be approved in their entirety by an administrator (unless they are created or changed by an administrator). Scripts that run inside the sandbox must have every method call (other than native Pipeline steps provided by Jenkins) approved. Pipeline scripts that are loaded from an SCM (i.e. Jenkinsfiles) may only be run inside the sandbox.
Script Security - User’s Guide gives more context.
Pipeline jobs can optionally be configured to run in the Groovy sandbox by checking “Use Groovy Sandbox.” If checked, this Pipeline code will be run in a sandbox with limited abilities. If unchecked, and you are not a Jenkins administrator, you will need to wait for an administrator to approve the script.
Multibranch Pipeline jobs or Pipelines from SCM (Jenkinsfiles) may only run in the sandbox. This means that these jobs may have their execution rejected. Users will see the results as
RejectedAccessExceptions in the console output.
If it is a Multibranch Pipeline job, or it uses a Jenkinsfile from SCM, it is running in the sandbox.
Otherwise, there are a couple of ways to check:
- Look at the job config in the UI - Is “Use Groovy Sandbox” selected?
- Look at the job config.xml directly - Either by appending /config.xml to the job URL, or by navigating directly to
$JENKINS_HOME/jobs/<job_name>/config.xml. There, look for
Scripts run inside the Sandbox are subject to the following:
- generic-whitelist - This file contains a list of accepted Groovy methods. Any attempt to use a Groovy method not listed here will result in a
- jenkins-whitelist - This file contains a list of accepted Jenkins methods. Any attempt to use a Jenkins method not listed here will result in a ‘RejectedAccessException’.
Blacklists are not “applied”. The blacklist is merely a list of methods which we know should never be added to a custom whitelist. There is no runtime effect beyond a warning displayed if you were to go to approve such a method. The runtime system is a whitelist one; nothing is permitted unless it is in some whitelist.
This is caused by jobs running inside the Sandbox that also use unsafe methods (see “Why am I getting
RejectedAccessException?”). Jobs running inside the Sandbox cannot have unsafe methods approved.
Multibranch Pipeline jobs or Pipelines from SCM (Jenkinsfiles) may only run in the sandbox.
Shared Libraries run inside or outside the Groovy Sandbox depending on where they are declared.
Global Shared Libraries always run outside the sandbox.
Folder-level Shared Libraries always run inside the sandbox.
It’s possible this is caused by no configured ACL.
Running Pipelines allows access to ACL-aware methods. See ACL-aware methods section of Script Security wiki for details.
When using the Approve assuming permission check option, it is expected that Access Control is already configured. If no Access Control is configured then Jenkins cannot perform the required access control checks.
- In versions of the ‘Pipeline: Groovy’ plugin older than 2.67, if you
throwit onward to cause the build to fail, you’ll never be asked to approve the method or script. This bug (JENKINS-34973) has been fixed, and it is recommended that users upgrade to the latest version of ‘Pipeline: Groovy.’ If you are unable to upgrade, see this article for a workaround.