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 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 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.
Please submit your feedback about this page through this quick form.
Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?
See existing feedback here.