How to configure Access Control for Builds?

Issue

When an upstream job is triggering a downstream job it displays a warning about access control for builds like:

Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered

Warning: `Access Control for Builds` in global security configuration is empty, so falling back to legacy behavior of permitting any downstream builds to be triggered

Warning: this build has no associated authentication, so build permissions may be lacking, and downstream projects which cannot even be seen by an anonymous user will be silently skipped

Environment

Jenkins >= 1.560
Jenkins LTS >= 1.565.1
CloudBees Jenkins Enterprise >= 1.565.3.1

Context

These messages are related to a new security feature introduced in Jenkins 1.560 (2014/04/20) and described as:

Enforcing build trigger authentication at runtime by checking authentication associated with a build, rather than at configuration time. For compatibility, enforcement is skipped by default; you must install the Authorize Project plugin or similar for this to take effect. The “upstream pseudo trigger” was also removed in favor of a true trigger configured on the downstream project; you may use either the post-build action or the trigger according to where you want this configuration stored, and who is authorized to change it. (issue 16956)

As described in this article various warnings are informing you about this security risk in Jenkins > 1.560. Even if it recommended to study this new feature your instance won’t be less secured with Jenkins 1.560 and it isn’t mandatory to configure it. This feature being recent you have to be warned that documentations and features may be incomplete.

Before Jenkins 1.560

In Jenkins all builds run in SYSTEM, i.e. having all permissions, and it is up to each build step to do its own security checks. There is no clear authentication to associate with the build. If it was started manually by a particular user, you could use that authentication, but other causes do not lead to a clear user name.

Since Jenkins 1.560

When an upstream job triggers another job,

if you didn’t installed a plugin providing access control for builds the following warning is displayed:

  Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered

if you installed a plugin providing access control for builds but you didn’t define at least one build authorizations strategy the following warning is displayed:

  Warning: ‘Access Control for Builds’ in global security configuration is empty, so falling back to legacy behavior of permitting any downstream builds to be triggered

if you installed a plugin providing access control for builds, defined at least one build authorizations strategy, but didn’t configured a strategy in the upstream job configuration the following warning is displayed:
```
  Warning: this build has no associated authentication, so build permissions may be lacking, and downstream projects which cannot even be seen by an anonymous user will be silently skipped
```

Resolution

To remove these warnings you have to install the Authorize Project plugin (or similar but for now it is the only one) and configure the Build Authorizations strategies.

1/ In Global Jenkins security settings you need to activate which strategies you want to allow on your instance (Manage Jenkins-> Configure Global Security -> Access Control for Builds -> Configure Build Authorizations in Project Configuration -> Select Run as ...) 2/ In each upstream (or downstream - see the special case of the reverse triggering) job configuration you need to select a strategy and configure it.

Build Authorizations Strategies provided by the Authorize Project plugin

Run as Specific User

Run a build as a specified user. You are required to one of following condition to successfully save the configuration.

You are an administrator.
You yourself are the specified user.
The specified user is not changed from the last configuration, and 'No need for re-authentication' was checked in the last configuration.
You enter the password for the specified user.

Run as User who Triggered Build

Run a build as a user who triggered it. If the build was triggered as a downstream build, the build runs as a user who triggered the upstream build. This does not work when the build is triggered by SCM polling or scheduled triggering. The build runs as SYSTEM authorization in those cases.

Run as anonymous

Run a build as an anonymous user.

The special case of the Reverse Triggering

The reverse triggering is when the downstream job is configured to be triggered after the upstream job.

When the build authorisations are configured triggers are executed by default as anonymous.

If the upstream job visibility is limited, the downstream job won’t see the upstream and thus it won’t be triggered. To make such triggering working, you will have to configure the downstream job to run as a user having the permission to see the upstream job.