Access Control for Builds
Similar to access control for users, builds in Jenkins run with an associated user authorization. By default, builds run as the internal SYSTEM user that has full permissions to run on any node, create or delete jobs, start and cancel other builds, etc.
| The permission Agent/Build requires access control for builds to be set up, as the build’s authentication is checked, and not the user starting the build. |
In a Jenkins setup with fine-grained permissions control, this is undesirable. For example, having builds run as SYSTEM could allow users with access to configure and start one job to start builds of any other jobs using plugin:pipeline-build-step[Pipeline Build Step Plugin].
| Some plugins implement their own access control beyond build authorization. Not using build authorization, or having builds run as SYSTEM, is an indicator that problems like the one described above can occur. |
One solution to this is to configure access control for builds. This is implemented by plugin:authorize-project[Authorize Project Plugin], which allows flexible configuration of global and per-project build authorization. That plugin is however not actively maintained, and there are known limitations to this approach.