ExtensionList.lookup(UnprotectedRootAction).each {
println String.format("URL: '%s/' provided by '%s' in '%s'", it.urlName, Jenkins.get().pluginManager.whichPlugin(it.class)?.shortName?:"Jenkins Core", it.class.name)
}
returnThe following sections describe the access granted to users with (or without) the specified permissions.
These permissions are granted globally, rather than on individual objects.
While Overall/Read is a prerequisite for more extensive access to Jenkins, some features are available without it.
Very basic UI, like the login form, the account signup form (if using the Jenkins user database as security realm), and some error pages ("Oops!").
Access to URLs provided by the security realm (to implement user signup or handle SSO authentication) (/securityRealm/).
agent.jar, remoting.jar, and jenkins-cli.jar files (plus deprecated aliases) to easily download client packages matching the running version of Jenkins (/jnlpJars/).
Agent JNLP files (/computer/…/jenkins-agent.jnlp?encrypted=true plus deprecated alias) to connect inbound agents to Jenkins.
Access to the TCP agent listener endpoint used by agents connecting to Jenkins via the agent TCP port (/tcpSlaveAgentListener/).
Access to some static resources (JS, CSS, and image files) bundled with Jenkins and Jenkins plugins (/adjuncts/).
Additionally, both Jenkins and any plugin may implement an extension point to make URLs available without authentication. SCM plugins commonly do this to let SCM features like post-commit hooks inform Jenkins about new commits, causing jobs to poll for changes.
As of Jenkins 2.290, the following extensions are provided as part of Jenkins (core):
/assets/ provides access to further static resources.
/cli/ handles CLI connections.
CLI documentation is also available here, but those pages are individually protected.
The /whoAmI/ URL allows determining who the current user is.
It is available to users without permissions to troubleshoot permissions issues.
/wsagents/ handles agent connections using web sockets.
/instance-identity/ provides a public key that allows identifying the Jenkins instance and setting up secure communication with it.
See the component documentation for details.
/static-files/ is used to implement the Resource Root URL feature serving user-provided contents from another domain.
See its documentation.
A list of all these extensions is provided on the UI when selecting (but not saving) the Delegate to Servlet container security realm, or can be obtained via the Script Console using:
ExtensionList.lookup(UnprotectedRootAction).each {
println String.format("URL: '%s/' provided by '%s' in '%s'", it.urlName, Jenkins.get().pluginManager.whichPlugin(it.class)?.shortName?:"Jenkins Core", it.class.name)
}
returnWhile these extensions opt out of the built-in Overall/Read permission requirements, they are expected to implement permission checks themselves whenever performing actions typically requiring permissions, or to check for the presence of a previously set up token in place of regular authentication.
In your HTTP access logs, you may see accesses to URLs starting with /static/, followed by a random looking string of letters and numbers.
This is part of a caching feature in Jenkins: Requests to these URLs expect cacheable responses, so HTTP response headers with a long expiration time are set.
The string following /static/ is randomly generated once on startup, ensuring that it changes when the Jenkins version (and therefore the contents of cacheable files) changes.
Any path starting with /static/…/ can be treated for logging purposes as if this prefix wasn’t present.
|
Users with Overall/Read access are expected to be legitimate users of Jenkins.
In addition to the above, a user granted Overall/Read can do all of the following:
Access the basic Jenkins API and the API of any object they have access to.
Access the People directory listing user accounts and known committer identities of anyone involved in visible projects (Jenkins 2.451 and earlier).
List and view all agents configured in Jenkins and access their summary pages.
Use search to find and access all agents and user accounts, and any other objects the user has been granted access to.
To support various features available to legitimate users of Jenkins, the following not as obvious URLs are accessible as well:
Further path prefixes (in addition to adjuncts/, assets/, and core webapp resources) providing static assets, both by Jenkins core and by plugins.
See the developer documentation.
Path prefixes providing access to all URLs implemented in extension lists of all extension points implemented in Jenkins. These URLs are typically used to support form validation and form autocompletion, and the way they’re organized means that some basic access is granted to any user with Overall/Read access.
|
While the vast majority of URLs in Jenkins are by default protected by an Overall/Read permission check, a lack of individual permission checks in endpoints for form validation and similar actions taken through the UI can result in users with only Overall/Read access to be able to access these actions. Lack of necessary permission checks constitutes a security vulnerability. While these are expected to be resolved in a timely manner, this may be worth considering when deciding who to grant Overall/Read permission to. |
In short: Everything.
Administrators can do all of the following:
Install and upload plugins that can run arbitrary code.
Use the Script Console both on the Jenkins controller and on individual agents, running arbitrary code in the Jenkins controller and agent processes.
Use the Script Console (or configure jobs) to run arbitrary shell scripts on the Jenkins controller or any connected agent.
There are no limits to what users with Overall/Administer permission can do in Jenkins. Anything they cannot accomplish through the existing UI they can do through the Script Console or by installing a plugin that does it.
An instance on which an untrusted user gained Overall/Administer permission should be considered fully compromised and should be replaced. All secrets (credentials, etc.) stored on that instance should be rotated or revoked and all artifacts created from that point on should be verified.
This permission allows users to run jobs as them on agents. In default setup where all builds run under SYSTEM user this permission is not relevant, but if build authorization is active this permission defines which users may run jobs on agents.
This permission allows users to configure agents. Users with this permission can make all jobs run on a computer where they have root access, gaining access to all information used by the build (content of files, environment variables including credentials).
This permission allows users to connect agents or mark agents as online.
This permission is implied by Agent/Disconnect.
This permission allows users to create agents. Security implications are the same as for Agent/Configure.
This permission allows users to delete existing agents.
This permission allows users to disconnect agents or mark agents as temporarily offline.
Though these permissions use the word "Job" in their name, they refer to any items you can create using the New Item menu option (freestyle jobs, folders, pipelines, …)
This permission grants the ability to start a new build.
This permission grants the ability to cancel a scheduled, or abort a running, build.
Change the configuration of a job.
Create a new job.
Delete a job.
This permission grants discover access to jobs. Lower than read permissions, it allows you to redirect anonymous users to the login page when they try to access a job url. Without it they would get a 404 error and wouldn’t be able to discover project names.
This permission is only useful if anonymous users have Overall/Read permission, but not Job/Read. It is implied by Job/Read.
Required to move a job from one folder (or Jenkins root) to another.
See a job. (You may deny this permission but allow Discover to force an anonymous user to log in to see the job.)
This permission grants the ability to retrieve the contents of a workspace Jenkins checked out for performing builds. If you don’t want a user to access files in the workspace (e.g. source code checked out from SCM or intermediate build results) through the workspace browser, you can revoke this permission.
This permission allows users to manually delete specific builds from the build history.
This permission allows users to update description and other properties of a build, for example to leave notes about the cause of a build failure.
This permission allows users to change the configuration of views.
This permission allows users to create new views.
This permission allows users to delete existing views.
This permission allows users to see views (implied by generic read access).
Following permissions are only enabled if the Credentials Plugin is installed
The create permission is necessary to add credentials to a credentials provider.
The delete permission is necessary to remove credentials stored in a credentials provider.
The manage domains permission is necessary to add/remove/configure the credential domains of a credentials provider (where the credentials provider supports multiple credential domains).
The update permission is necessary to modify credentials in a credentials provider.
The view permission is necessary to view the credentials stored in a credentials provider.
Ability to perform a new Pipeline build with an edited script. This permission is implied by Job/Configure. This permission is enabled by Pipeline: Groovy.
These permissions are not enabled by default.
This permission grants read-only access to the Jenkins global configuration. Its primarily intended to be used when the Jenkins configuration is managed externally, e.g. using the Configuration as Code plugin. It works best when combined with the ExtendedRead permission that allows read-only access to agents and items.
This permission can be enabled by setting the system property jenkins.security.SystemReadPermission to true or installing the Extended Read Permission plugin.
Learn more in JEP-224.
| This permission was added in Jenkins 2.222. Some features, especially those provided by plugins, may not yet support this permission. |
Overall/Administer (described below) is a very high level of permission: Between administrative tools like the script console and the ability to install plugins, there are no limits to what administrators can do.
Overall/Manage grants permission to access and modify a subset of administrative options. Users with this permission are able to perform some administrative tasks. Options generally considered critical to the security of Jenkins are not available to these users.
This permission can be enabled by setting the system property jenkins.security.ManagePermission to true or installing the Overall/Manage permission enabler plugin.
Learn more in JEP-223.
| This permission was added in Jenkins 2.222. Some features, especially those provided by plugins, may not yet support this permission. |
The following three permissions are obsolete since Jenkins 2.222:
Overall/RunScripts
Overall/UploadPlugins
Overall/ManageUpdateSites
These permissions were intended for use in an externally managed, hosted Jenkins environment. They would allow a user to directly (through the script console) or indirectly (through plugin installation) execute code they control. By default, these permissions were implied by the Overall/Administer permission by default to not impact more common Jenkins environments, while allowing a hosted environment to have administrators with Overall/Administer permission but not these more sensitive permissions.
This model has been retired. While these permissions still exist, they’re no longer used by Jenkins core and related features have been removed, e.g., uploading plugins or using the script console just requires Overall/Administer permission now.
For more fine-grained access to the global configuration, the permissions Overall/Manage and Overall/SystemRead can optionally be enabled.