Issue
-
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
RejectedAccessException? -
In what order are denylists and allowlists applied?
-
Why can’t I approve a script?
-
How are Shared Libraries affected by Script Security?
-
Why is an allowlisted method rejected when running in the Groovy Sandbox?
-
Notes
FAQ
What is Sandbox mode?
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.
How does script security affect Pipeline job types?
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.
How do I know if I am running in the Groovy Sandbox?
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<sandbox>true</sandbox>, or<sandbox>false</sandbox>.
Why am I getting RejectedAccessException?
Scripts run inside the Sandbox are subject to the following:
-
generic allow list - This file contains a list of accepted Groovy methods. Any attempt to use a Groovy method not listed here will result in a
RejectedAccessException. -
jenkins allow list - This file contains a list of accepted Jenkins methods. Any attempt to use a Jenkins method not listed here will result in a 'RejectedAccessException'.
In what order are denylists and allowlists applied?
Denylists are not “applied”. The denylist is merely a list of methods which we know should never be added to a custom allowlist. There is no runtime effect beyond a warning displayed if you were to go to approve such a method. The runtime system is a allowlist one; nothing is permitted unless it is in some allowlist.
Why can’t I approve a script?
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.
How are Shared Libraries affected by Script Security?
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.
Why is an allowlisted method rejected when running in the Groovy 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.
Notes
-
In versions of the 'Pipeline: Groovy' plugin older than 2.67, if you
catchaRejectedAccessExceptionand don’tthrowit 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.